MCP 2026-07-28 adapter for the VKLP (Verifiable Knowledge Ledger Profile) decentralized RAG research prototype. Provides tools for searching finalized knowledge records, retrieving claims with consensus metadata, proposing new claims, verifying cryptographic ledger integrity, and discovering service capabilities.
VKLP MCP server has 5 tools with clear verb-noun naming (search_knowledge, get_claim, propose_claim, verify_ledger, service_info). All tools have descriptions (10 - 200 chars, within baseline). Input schemas are present and typed for all tools. However, parameter descriptions are minimal or missing context about constraints, formats, and error recovery. Output schemas are not documented, callers must infer structure from code. Error handling is absent: no guidance on retryability, user-fixable vs fatal errors, or recovery paths. The propose_claim tool accepts JSON-encoded evidence as a string rather than structured input, forcing LLM serialization and increasing error surface. No tool declares permissions or security implications. Overall: functional but below production baseline for agent-facing tools.
Get a complete claim, evidence, consensus votes and ledger reference.
Propose a claim. It is validated by at least the configured quorum before becoming accepted knowledge.
Search finalized knowledge records and return status/provenance metadata.
Discover VKLP version, compatibility level, capabilities and stable routes.
Cryptographically verify the local append-only ledger copy.
Output schemas not documented. Callers cannot predict response structure (e.g., does search_knowledge return 'hits' or 'results'? Is each hit a flat dict or nested object?). LLMs must infer from code, risking wrong field access.
propose_claim accepts evidence_json as a string requiring manual JSON serialization. This forces LLMs to construct JSON, increasing error surface. Should accept structured array of evidence objects.
Parameter descriptions lack constraint details. 'top_k' has no min/max bounds (baseline: 1 - 100). 'language' and 'domain' have no enum values or format guidance. LLMs may pass invalid values.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 56 | 2026-07-28+ | v2 |
No error handling guidance. Tools return dicts but do not document failure modes, retryability, or recovery steps. E.g., what if claim_id is not found? What if consensus fails?
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Agents cannot determine which tools are safe to retry or have side effects. propose_claim is destructive but unmarked.