01Safety
0.0 / 30
What changed in the harness
Selection accuracy 100→100, token cost up 8%, 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.
02Legibility
22.3 / 30
03Economics
17.6 / 20
04Discoverability
12.5 / 20
Highest-impact fix
Estimated gain +30 pointsAdd 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.
9 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 supplied as a hex or base64 string (max 1024 bytes decoded) and return the decoded contents in a form matching the memo's format: parsed structure for ZAP1 typed memos, decoded text for ZIP 302, plain text for untyped text, and the raw bytes for binary memos. |
get_agent_status |
params_unexplained |
Get the attestation summary for the ZAP1 agent identified by agent_id (a unique identifier for an agent previously registered or attested on ZAP1). Returns the agent's registration state, policy assignments, recorded actions, and event history. |
zap1_verify_evm |
no_return_description |
Verify a ZAP1 Merkle proof on-chain via the EVM ZAP1Verifier contract on the chosen chain (sepolia testnet, base, or arbitrum). Returns the on-chain verification result indicating whether the given leaf_hash, combined with the ordered siblings and bit-packed positions, is included in the expected_root of a registered Zcash anchor root. |
zap1_attest_external_action |
params_unexplained |
Build a ZAP1 receipt request attesting that an action executed by an external rail reached the given status, without routing, swapping, signing, holding custody, broadcasting, or settling the action. rail_id identifies the external rail; action_type describes the action and status its attested state. The optional hash parameters pin evidence as bounded commitments: intent_hash (action intent), quote_hash (quote), route_hash (route), origin_txid, settlement_txid, and destination_txid (result txids), plus counterparty_digest, operator_digest, subject_hash, claim_hash, and evidence_hash (digests of the relevant packets). disclosed_fields and redaction_policy control what the receiver is allowed to see. Returns the constructed ZAP1 receipt request packet. |
zap1_verify_external_receipt |
params_unexplained no_return_description |
Validate an external-action ZAP1 receipt packet against the stateless receipt contract; it does not trust or call the external rail. expected_event_type is the event type the packet must carry, and expected_profile is the disclosure profile it must match (public_hash_only, counterparty_receipt, auditor_packet, operator_internal, grant_proof_packet, or compliance_audit_packet). Returns the validation result indicating whether the packet is well-formed and matches the expected event type and disclosure profile. |
zap1_extract_proof_artifact |
name_restates_behavior |
Extract the portable proof material from a ZAP1 receipt so the proof can be verified or audited off-chain. Returns the leaf hash, Merkle path, root, anchor context, and verification URL contained in the receipt packet. |
zap1_check_anchor_freshness_at_height |
params_unexplained no_return_description |
Given a receipt's anchor_height and a supplied current Zcash block height, compute the anchor's age in blocks and its confirmation depth, and report whether it satisfies min_confirmations (default 10). anchor_height is the block height at which the anchor was recorded, current_height is the caller-provided latest Zcash height, and min_confirmations is the required confirmation margin. Stateless; never calls a node. Returns the computed age, confirmation depth, and a freshness/confirmation verdict. |
zap1_compare_receipt_claims |
name_restates_behavior no_return_description |
Compare two ZAP1 receipt packets and return a per-field match report indicating whether subject, claim, evidence, event type, and anchor context agree, so callers can determine whether both receipts attest to the same underlying fact. The returned report identifies which dimensions match and which differ. |
zap1_audit_event_log |
params_unexplained no_return_description |
Replay a small sequence of 1-50 ZAP1 receipt packets against an expected event-type policy and report violations, as a stateless audit helper for agents and reviewers. receipts: the ZAP1 receipt packets to check; allowed_event_types: the event-type strings the receipts are permitted to emit; require_anchored: whether each receipt must carry an anchor (default false). Returns a list describing any unexpected event-type or missing-anchor violations, or an empty result when the sequence conforms. |
Selection evidence
Confusable tool pairs.
15 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_external_receipt |
zap1_verify_receipt_chain |
high | Both are stateless receipt-contract validation tools; a user asking 'verify this ZAP1 receipt packet' could be routed to the sequence validator (which demands an array) or the single-packet validator based only on phrasing, and both descriptions read as 'validate receipt packets'. |
verify_proof |
zap1_verify_evm |
high | A task like 'verify my ZAP1 Merkle proof' matches both: one checks a leaf in the attestation tree, the other verifies the same kind of proof on an EVM chain. Only an explicit on-chain mention disambiguates, so a generic 'verify the proof' request is genuinely ambiguous. |
zap1_verify_evm |
zap1_verify_external_receipt |
medium | Both are 'verify' tools taking receipt/proof material; a user saying 'verify this receipt/proof' could land on the EVM verifier when they only meant the stateless receipt-contract check, since neither description clearly scopes the other out. |
zap1_verify_evm |
zap1_verify_receipt_chain |
medium | 'Verify the receipts' could select the on-chain EVM verifier or the offline sequence validator; both verify ZAP1 proof/receipt material and the names differ mainly in mechanism rather than goal. |
zap1_prove_receipt |
zap1_verify_external_receipt |
medium | A task such as 'prove/validate my receipt' is ambiguous between fetching a Merkle proof bundle for a leaf hash and validating an external-action receipt packet, since both keywords (prove/verify, receipt) appear in both descriptions. |
zap1_prove_receipt |
zap1_verify_receipt_chain |
medium | 'Prove this receipt' could route to fetching a proof bundle or to validating a chain of receipt packets; both involve receipt verification/proof terminology with no strong discriminator in the descriptions. |
zap1_attest_external_action |
zap1_verify_external_receipt |
medium | Both deal with external-action ZAP1 receipts (one builds the receipt request, the other validates the packet); 'handle this external action receipt' is ambiguous between attest/build and verify. |
zap1_wallet_receipt_request |
zap1_attest_external_action |
medium | Both build ZAP1 receipt requests for an external action; a user describing a wallet-layer action like 'create a receipt for this action' could pick the wrong builder since wallet vs external-rail attribution is easy to miss. |
attest_event |
zap1_attest_external_action |
medium | Both are 'attest' entry points supporting action attestations; 'attest to this external/agent action' could select the generic event-leaf attester instead of the external-rail receipt builder, or vice versa. |
get_anchor_history |
get_anchor_status |
medium | 'Show me the anchors / anchor info' is ambiguous between a historical list of anchored roots with txids and the current Merkle tree state; both are parameterless reads of anchor data. |
get_anchor_status |
get_agent_status |
medium | A bare 'get status' request is ambiguous between the current Merkle anchor/tree status and an agent's attestation summary; only explicit wording ('anchor status' vs 'agent status') separates them. |
get_events |
get_agent_status |
medium | 'Get the events/attestation history for agent X' could route to the recent-events list (no agent filter) instead of the agent summary tool, since get_agent_status describes event history and get_events describes attestation events for wallets/agents. |
get_stats |
get_anchor_status |
medium | Both are parameterless protocol-state reads; 'what is the current ZAP1 tree/anchor state' could select stats (leaves, anchors, height) or anchor status (root, unanchored leaves, anchor recommendation) interchangeably. |
get_stats |
get_agent_status |
medium | A request for 'agent stats' is ambiguous between the protocol-level stats tool and the per-agent attestation summary, especially since get_stats mentions agents only loosely and get_agent_status is the correct target. |
zap1_create_receipt_invoice |
zap1_watch_receipt_invoice |
medium | Tasks like 'set up/track my receipt invoice' could land on either the invoice creator or the status poller, both sharing the 'receipt invoice' phrasing; an agent may create when polling was intended or poll when creation was intended. |
Compare the field