Public assessment

Frontier-Compute/zcash-mcp (@frontiercompute/zcash-mcp)

frontiercompute-zcash-mcp · v1.4.0 · scanned Aug 2, 2026

What changed in the harness

Selection accuracy 98→98, token cost up 6%, unconfirmed writes 0%→0%.

Category breakdown

Where the score comes from.

Earned points across the four signals Gradable measures. Safety and Legibility are scored out of 30; Economics and Discoverability are scored out of 20.

01Safety

0.0 / 30

0.0 out of 30

02Legibility

20.8 / 30

20.8 out of 30

03Economics

17.4 / 20

17.4 out of 20

04Discoverability

18.2 / 20

18.2 out of 20

Highest-impact fix

Estimated gain +30 points

Add explicit identity and permission preflight tools

Expose machine-readable principal/tenant confirmation and a non-mutating permission check so agents can verify both before destructive actions.

Description evidence

Defects and rewrites.

16 defects found across the exposed tool descriptions. Suggested rewrites make purpose, inputs, boundaries, and returns easier for an agent to understand.

Tool	Defect types	Suggested rewrite
`decode_memo`	no_return_description	Decode a Zcash shielded memo field. Handles ZAP1 typed memos, ZIP 302, plain text, and raw binary. Returns the decoded memo content along with the detected memo format/type.
`get_stats`	no_return_description	Get ZAP1 protocol stats. Returns an object with total leaves, total anchors, event type distribution, and current Merkle tree height.
`get_block_height`	no_return_description	Get the current Zcash chain height from Zebra. Returns the current block height as an integer.
`lookup_transaction`	no_return_description	Get raw transaction data by txid from Zebra. Returns the transaction as decoded JSON by default, or raw hex if verbose is set to false.
`get_anchor_history`	no_return_description	Get all ZAP1 Merkle root anchors. Returns a list of anchor records, each including the Merkle root, the Zcash txid that anchored it, and the block height.
`get_anchor_status`	no_return_description	Get current ZAP1 Merkle tree state. Returns the current root hash, the count of unanchored leaves, and a recommendation on whether to anchor now.
`get_agent_status`	params_unexplained no_return_description	Get attestation summary for a ZAP1 agent. Takes agent_id, the identifier of the agent to look up. Returns the agent's registration status, active policies, recorded actions, and event history.
`zcash_reputation_score`	no_return_description	Fetch an agent's reputation from ZAP1. Returns a single object combining bond data and policy compliance: attestation count, violation count, bond amounts, and a compliant boolean flag.
`zap1_verify_evm`	no_return_description	Verify a ZAP1 Merkle proof on-chain via the EVM ZAP1Verifier contract on Sepolia, Base, or Arbitrum. Returns whether the leaf hash is included under the expected root, along with the on-chain verification result/transaction details.
`zap1_attest_external_action`	params_unexplained no_return_description	Build a ZAP1 receipt request for an action executed by an external rail (e.g. a bridge, router, or settlement layer); ZAP1 does not route, swap, sign, custody, broadcast, or settle the action itself. Optional hash fields (intent_hash, quote_hash, route_hash) and txid fields (origin_txid, settlement_txid, destination_txid) identify the external transaction stages without exposing raw details; counterparty_digest and operator_digest are hashed identifiers for the counterparty and operator; subject_hash, claim_hash, and evidence_hash are precomputed hashes of the subject, claim, and supporting evidence. Returns the constructed ZAP1 receipt request object for this external action.
`zap1_verify_external_receipt`	params_unexplained no_return_description	Validate an external-action ZAP1 receipt packet as a stateless receipt-contract check; it does not trust or call the external rail. expected_event_type optionally asserts the receipt's event type matches; expected_profile optionally asserts the receipt's disclosure profile matches. Returns a validation result indicating whether the receipt is well-formed and matches the expected event type/profile if provided.
`zap1_extract_proof_artifact`	name_restates_behavior no_return_description	Pull the portable Merkle proof material out of a ZAP1 receipt so it can be shared or verified independently of the full receipt packet. Returns an object containing the leaf hash, Merkle path, root, anchor context, and a verification URL.
`zap1_check_anchor_freshness_at_height`	params_unexplained no_return_description	Check anchor age and confirmation depth given a receipt's anchor_height and a supplied current_height for the Zcash chain; stateless, does not call a node. min_confirmations (default 10) sets the confirmation depth required to consider the anchor sufficiently confirmed. Returns the computed anchor age in blocks and whether it meets the min_confirmations threshold.
`zap1_verify_receipt_chain`	no_return_description	Validate a sequence of ZAP1 receipt packets. Returns a summary indicating whether all packets are well-formed and anchored, including any per-packet failures.
`zap1_compare_receipt_claims`	name_restates_behavior no_return_description	Diff two ZAP1 receipts field by field to check for tampering or divergence between claimed events. Returns a report of whether subject, claim, evidence, event type, and anchor context match, flagging any mismatched fields.
`zap1_audit_event_log`	params_unexplained no_return_description	Replay a small receipt sequence (receipts) against an expected event-type policy (allowed_event_types) as a stateless audit helper for agents and reviewers; require_anchored, if true, additionally requires every receipt to be anchored to pass. Returns an audit result listing any receipts that violate the allowed event types or anchoring requirement.

Selection evidence

Confusable tool pairs.

10 pairs where similar names or overlapping descriptions may send an agent toward the wrong tool.

Tool A	Tool B	Confidence	Why they collide
`zap1_verify_evm`	`zap1_verify_receipt_chain`	high	Both tools respond to a request like 'verify this on the chain' — 'chain' is polysemous here, meaning either the EVM blockchain (zap1_verify_evm) or a sequence of receipt packets (zap1_verify_receipt_chain), and their inputs (siblings/root vs receipts array) don't disambiguate until the agent reads deeply.
`attest_event`	`zap1_attest_external_action`	high	A task like 'attest that this agent action happened' is ambiguous between the generic internal attest_event (event_type AGENT_ACTION) and zap1_attest_external_action, which is specifically for actions executed by an external rail — the agent must infer whether the action originated internally or externally, which isn't always stated.
`verify_proof`	`zap1_verify_evm`	medium	Both verify a Merkle proof for a leaf hash; a request like 'verify this proof' doesn't specify whether the check should happen off-chain against the ZAP1 tree (verify_proof) or on-chain via the EVM contract (zap1_verify_evm), and both take leaf_hash-like inputs.
`zap1_verify_external_receipt`	`zap1_verify_receipt_chain`	medium	Both validate receipt packets against the contract; a task like 'verify these receipts are valid' is ambiguous between validating a single external-action receipt versus validating an ordered sequence, especially since a one-item chain call could satisfy either intent.
`zap1_verify_evm`	`zap1_verify_external_receipt`	medium	Both combine 'verify' with 'external' concepts (an external EVM chain vs an external-rail receipt); a vague instruction like 'verify this external transaction' could plausibly route to either tool before the agent notices one needs Merkle proof siblings and the other a receipt object.
`get_anchor_status`	`get_agent_status`	medium	The tool names differ by a single word (anchor vs agent) that is easy to mis-type or mis-hear, and a terse request like 'get status' with an ambiguous subject noun could be misrouted, though get_agent_status requires an agent_id which should ultimately disambiguate.
`get_anchor_history`	`get_anchor_status`	medium	Both describe the ZAP1 anchor/Merkle tree state; a request like 'what's the anchor situation' is ambiguous between wanting the historical list of anchors with txids (get_anchor_history) versus the current unanchored/root state (get_anchor_status).
`get_events`	`get_agent_status`	medium	get_agent_status includes 'event history' for a specific agent while get_events returns recent events generally; a request like 'show me this agent's recent activity' could plausibly be served by either tool.
`get_stats`	`get_anchor_status`	medium	Both report tree-related metrics (get_stats has tree height/leaf counts, get_anchor_status has unanchored leaves/root); a question like 'what's the current tree state' could be routed to either.
`zap1_wallet_receipt_request`	`zap1_attest_external_action`	medium	Both build a receipt request from an action result with nearly identical parameter shapes (action_type/status/hashes); the distinguishing factor is whether the actor is a 'wallet provider' or an 'external rail', which a task description may not clearly indicate.

Compare the field

One score is useful.
The evidence makes it actionable.

Back to the leaderboard