Cronozen Decision Proof MCP Server - AI Decision Provenance via Streamable HTTP
Critical gaps across all dimensions. Tool definitions lack visible input schemas in source code, cannot verify parameter types, constraints, or descriptions. Tool descriptions are present but generic (10-50 chars), providing minimal LLM guidance. No evidence of output schema documentation. Error handling patterns absent. Naming follows verb_noun convention (proof_*) but lacks clarity on distinctions between verify/chain_verify/public_verify. Cannot assess composition or idempotency without schema visibility.
Verify the integrity of a decision chain
Export a decision proof as JSON-LD evidence
Retrieve a recorded decision proof
Publicly verify a decision proof without authentication
Record an AI decision with cryptographic proof
Verify the cryptographic integrity of a recorded decision
No input schemas visible in source code. Cannot verify parameter types, constraints, enums, or descriptions.
Tool descriptions are generic and under 50 characters. E.g. 'Record an AI decision with cryptographic proof' lacks WHEN to use, WHAT it returns, and prerequisites. LLMs cannot distinguish proof_verify from proof_chain_verify from descriptions alone.
No output schema documentation visible. LLMs cannot plan downstream tool calls or extract required fields (e.g., proof_id, chain_hash, verification_status). Breaks tool composition.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 38 | <=2025-11-25 | v2 |
No error handling guidance visible. Tools lack recovery hints (e.g., 'Proof not found. Try proof_get() with a valid proof_id'). Agents cannot self-correct on failures.
Naming ambiguity: proof_verify, proof_chain_verify, and proof_public_verify are similar. Descriptions do not clarify when to use each. LLMs will conflate them.