Loading ToolBench
A zero-knowledge proof integrity layer for blockchain verification, supporting Poseidon, Keccak, and Hybrid circuits with proof generation, verification, batch processing, and on-chain storage
The MCP ZK Integrity Layer exhibits significant gaps in definition quality. While 11 tools are defined with schemas and descriptions, the quality is uneven. Tool names follow action-verb conventions (generateProof, verifyProof, etc.), which is positive. However, descriptions are often generic or lack critical context about when to use each tool versus similar ones. Parameter descriptions are present but frequently vague, e.g., 'Proof generation parameters' without explaining what each parameter controls in practical terms. Input schemas are visible and use JSON Schema with types and enums, but output schemas are completely undocumented, LLMs have no signal for what fields to expect from responses, breaking the tool-chaining pattern critical to agent composition. Error handling is minimal; constants.ts defines ERROR_MESSAGES but the service layer integration is not visible, so we cannot verify that these error guides are actually returned to agents with recovery suggestions. Parameter validation logic exists (validateInputs tool) but is exposed as a separate tool rather than integrated into the tools that generate/verify proofs, forcing multi-step validation calls. The descriptions of complex operations like batchVerifyProofs lack explanation of the 'aggregationType' parameter's practical implications (sequential vs. parallel vs. recursive) and what output shape the agent should expect. Tool composition is problematic: createZkIdentity produces outputs (trapdoor, nullifier, commitment) that generateProof and storeProofOnChain likely consume, but this dependency chain is undocumented. Overall, the definitions are mid-tier for an MCP server, better than minimal, but well short of production readiness for agent-driven workflows.
Verify multiple zero-knowledge proofs in batch with optional aggregation and compression
Check the integrity of proofs within a block range with optional detailed validation results
Create a new zero-knowledge identity with trapdoor, nullifier, and commitment
Generate a Merkle proof for a leaf in a tree of leaves
Generate a zero-knowledge proof for the specified circuit type with public and optional private inputs
Get statistics for a specific ZK circuit type including total proofs, valid proofs, and average proof time
Retrieve the status of a proof stored on-chain
Output schemas completely undocumented. LLMs cannot determine what fields (proof, commitment, timestamp, etc.) to expect from any tool response. This breaks tool chaining and forces agents to guess at response structure.
Descriptions lack recovery guidance and operational context. E.g., 'Generate a zero-knowledge proof for the specified circuit type' does not explain when to use generateProof vs. batchVerifyProofs, what error conditions are recoverable, or what the userId parameter represents in proof lineage.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 39 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 44 | - | v1 |
Store a zero-knowledge proof on-chain with commitment, nullifier, and merkle root
Validate public and private inputs against circuit constraints
Verify a Merkle proof for a leaf against a root
Verify a zero-knowledge proof using the appropriate verifier contract on the specified chain
createZkIdentity has empty input schema (no parameters) but description is vague ('Create a new zero-knowledge identity') and does not explain what the trapdoor, nullifier, and commitment represent or how they are used by downstream tools like generateProof.
Tool dependencies are implicit and undocumented. E.g., storeProofOnChain expects a 'proof' object with 'proof, publicInputs, commitment, nullifier, merkleRoot' fields, but which tools produce these exact fields? Unclear. This forces agents into trial-and-error composition.
validateInputs is exposed as a separate tool instead of being integrated into generateProof. This requires agents to call validateInputs first, then generateProof, wasteful and error-prone. Validation should happen inside generateProof with clear error guidance.
batchVerifyProofs parameter 'aggregationType' (sequential|parallel|recursive) is not explained in its description. What do these modes do? How do they affect output? Agents cannot reason about this parameter without explicit guidance.
Error handling is defined in constants.ts but integration into service layer is not visible. No evidence that tools return structured error responses with recovery hints (e.g., 'Invalid proof format. Did you mean to call generateProof first?'). Agents have no actionable error guidance.
getProofStatus description does not explain what status fields are returned (exists, verified, timestamp, nullifierUsed per the ABI, but this is hidden in constants.ts). LLMs cannot understand response structure without explicit documentation in the tool description.
Mutable operations (generateProof, storeProofOnChain) lack confirmation/dry-run patterns. No indication whether these are idempotent. An agent retrying a failed proof generation could create duplicate on-chain entries.