Loading ToolBench
ZAP1 receipts for Zcash agents: verify workflows without trusting the server. Attestation layer, not a wallet.
This MCP server exhibits severe definition quality issues across nearly all 28 tools. While the server addresses a specialized and complex domain (Zcash ZAP1 attestation), the tool definitions lack the rigor required for LLM-safe composition. No visible input schemas in source code for most tools, only names and descriptions in .well-known/mcp.json. Descriptions are present but extremely terse (many under 100 chars), providing minimal context for LLM tool selection. Parameters are either absent from visible sources or completely undocumented. Tool naming is inconsistent (mix of verb-noun and compound names like 'zap1_verify_receipt_chain'). No visible output schemas documented. Error handling guidance is absent. The server appears to be a wrapper around ZAP1 API and Zebra RPC, but the MCP layer does not expose the underlying schemas, making composition risky.
Create a typed ZAP1 attestation event leaf for later anchoring. Returns a leaf hash for verification.
Decode Zcash memo payloads that carry ZAP1 or receipt data
Get attestation summary for a ZAP1 agent: registration, policies, actions, event history.
Get all ZAP1 Merkle root anchors with Zcash txids and block heights.
Get current ZAP1 Merkle tree state: root hash, unanchored leaves, anchor recommendation.
Get the current Zcash chain height from Zebra.
Get recent ZAP1 attestation events. Returns event type, wallet hash, leaf hash, and timestamps.
Input schemas are absent for 24 of 28 tools. Only 4 tools (attest_event, lookup_transaction, get_events, get_agent_status, zcash_conformance_check) have visible input schema in .well-known/mcp.json; the rest show 'WRITE' or 'READ_ONLY' risk labels without parameter definitions. Tools like zap1_create_receipt_invoice, zcash_identity_register, zap1_prove_receipt, etc. have no documented input parameters, making them un-callable by LLMs without further introspection.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 35 | 2026-07-28+ | v2 |
Get ZAP1 server statistics
Get raw transaction data by txid from Zebra.
Verify a ZAP1 proof receipt
Attest an external action with ZAP1
Audit ZAP1 event log for compliance
Check anchor freshness at a specific block height
Compare claims across multiple ZAP1 receipts
Create a ZAP1 receipt invoice
Extract proof artifacts from ZAP1 receipt
Prove a ZAP1 receipt
Verify ZAP1 proofs using EVM semantics
Verify an external receipt with ZAP1
Verify a chain of ZAP1 receipts
Verify a ZAP1 receipt v2
Create a wallet receipt request for ZAP1
Watch a ZAP1 receipt invoice for updates
Return the ZAP1 capability manifest: what this MCP covers, what it deliberately excludes, and how agents should compose it with wallet-layer tools.
Validate only the shape of a frozen v1 receipt packet. V1 cannot prove Merkle inclusion or anchor confirmation.
Register a Zcash identity with ZAP1
Generate a ZAP1 receipt template
Get reputation score for a Zcash identity
Tool descriptions are uniformly terse (15 - 80 chars) and lack strategic context. Examples: 'Decode Zcash memo payloads that carry ZAP1 or receipt data' (55 chars), 'Get ZAP1 server statistics' (26 chars), 'Get reputation score for a Zcash identity' (41 chars). These descriptions do not explain WHEN to call the tool vs. similar ones, WHAT happens (state-changing?), or WHAT structure is returned. Rubric baseline is 194 chars avg; this server averages ~45 chars.
No output schemas documented anywhere. The .well-known/mcp.json file lists tools and input parameters for 5 tools only; it does not declare what fields any tool returns. For example, get_anchor_history() presumably returns a list of anchors with txids and block heights (per the description), but the exact JSON structure is unknown to LLMs. Without output schemas, LLMs cannot chain tools safely.
Inconsistent and unclear tool naming. Mix of generic prefixes (get_, zap1_*) with compound names that obscure intent. Tools like 'zap1_verify_receipt_chain', 'zap1_compare_receipt_claims', 'zap1_audit_event_log' read more like internal API routes than clear LLM actions. No clear distinction between similar tools (verify_proof vs. zap1_prove_receipt vs. zap1_verify_receipt_v2 vs. zap1_verify_external_receipt vs. zap1_verify_receipt_chain). LLMs will struggle to choose the right one.
Parameter descriptions are absent or minimal for most tools. attest_event is the only tool with reasonably detailed param docs (wallet_hash, agent_id, input_hash all have context). lookup_transaction has brief docs. Other tools with visible params (get_events, get_agent_status, zcash_conformance_check) have minimal descriptions. Per the rubric, 100% of A+ tools have descriptions for every parameter.
No error handling guidance. Tool descriptions do not explain what errors can occur, how to recover, or whether operations are idempotent. For example, attest_event creates a 'typed ZAP1 attestation event leaf', but what if the ZAP1 service is unreachable? What if the API key is invalid? No guidance. Rubric requires 'Error responses must tell the LLM what to do next.'
State-changing tools lack safety mechanisms. attest_event, zcash_identity_register, zap1_create_receipt_invoice, zap1_wallet_receipt_request, zap1_attest_external_action are marked as WRITE but have no dry-run, confirmation, or idempotency guarantees documented. An agent could accidentally create duplicate events or registrations. Rubric: 'Irreversible operations should support a dry-run or confirmation step.'
Minimal to no composition guidance. The server does not indicate which tools should be called in sequence, what IDs are needed, or whether outputs chain to other tools. For example, after calling zcash_identity_register, what ID should be passed to get_agent_status? Is it the same identity? Tools should include 'what to call next' hints.