This server connects AI agents to Zcash blockchain operations, ZAP1 attestation services, and advanced shielded features.
Blockchain Data
Query current Zcash chain height from a Zebra node.
Look up raw/decoded transaction data by txid.
Wallet & Payments
Generate zcash: payment URIs (ZIP 321) with address, amount, and optional memo.
Decode shielded memos: ZAP1 typed, ZIP 302, plain text, or binary.
Create payment invoices and monitor them until paid, returning txid, block height, and amount.
ZAP1 Attestation
Get attestation history and anchor status for a wallet hash.
Write typed attestation events (e.g., DEPLOYMENT, AGENT_ACTION, GOVERNANCE_PROPOSAL) to the Zcash blockchain Merkle tree.
Verify Merkle proofs to confirm a leaf hash exists in the attestation tree.
Fetch the full Merkle proof bundle for a given leaf hash.
Query protocol stats: total leaves, anchors, type distribution, tree height.
Retrieve full anchor history (txids and block heights) and current Merkle tree state.
Fetch recent attestation events (configurable limit up to 200).
Get a full agent attestation summary: registration, policies, actions, and event history.
Agent & Advanced Features
Register agent identities via AGENT_REGISTER attestation.
Fetch agent reputation scores (bond data and policy compliance).
Initiate cross-chain swap intents from ZEC transparent funds to BTC, USDC, or USDT via Ika or NEAR.
Create split-key wallets via Ika 2PC-MPC for signing ZEC, BTC, and ETH.
Perform MPC signing where neither party holds the full key.
Shield transparent ZEC funds to the Orchard pool.
Verify ZAP1 Merkle proofs on-chain via EVM contracts (Sepolia, Base, Arbitrum).
Provides tools for interacting with the Zcash blockchain, enabling AI agents to perform shielded operations including checking balances, generating payment URIs, decoding shielded memos, writing attestations, verifying Merkle proofs, and querying chain data like block height and transaction details.
ZAP1 receipts for Zcash agents: verify workflows without trusting the server.
ZAP1 is an attestation and proof rail for Zcash workflows. Frontier Compute maintains the reference ZAP1 implementation.
A wrapper makes you trust the server. ZAP1 makes the server unnecessary to trust.
Core rule: observe state, bound the claim, hash evidence, issue a receipt, verify later.
MCP is the standard way for AI agents to call external tools. zcash-mcp
exposes the ZAP1 attestation layer for agents that need verifiable receipts
around Zcash workflows: create ZAP1 attestation leaves, query anchor state,
and verify proof receipts.
This is not a full wallet MCP. Balance scanning, private key custody, seed handling, PCZT signing, shielded spend construction, and lightwalletd or Zaino wallet synchronization are complementary wallet-layer work, not this server's scope.
Wallet MCPs can move value. ZAP1 proves the workflow around the value, and the counterparty can verify the proof without trusting Frontier.
Tool servers expose what a backend says right now. ZAP1 produces a receipt that another party can verify later from the schema, proof material, and Zcash anchor.
ZAP1 is the proof rail for Zcash agent workflows:
attest: create a typed event leaf.
anchor: commit leaves into a Merkle root anchored to Zcash.
prove: return a receipt packet for a leaf.
verify: let another party check the receipt without trusting the original
agent.
Agent systems need more than a payment or a transaction lookup. They need a receipt that another agent, user, auditor, or service can verify later:
what event was asserted
which agent or workflow asserted it
which ZAP1 leaf records it
which Merkle root includes it
which Zcash transaction anchored that root
how to verify the proof without trusting the original agent
That is the lane for this server. It gives Zcash agents a receipt layer that can sit beside any wallet, signer, custody system, lightwalletd stack, Zaino stack, or application-specific payment flow.
See ZAP1 Proof Rail for the category boundary, receipt model, integration pattern, and red-team rejects. See ZAP1 Conformance for the receipt contract agents and integrations should satisfy. See Wallet Receipt Integration for the wallet-action handoff pattern. See External Rail Receipts for generic external-action receipt requests, and Receipt Disclosure Profiles for public, counterparty, auditor, grant, compliance, and internal packet shapes.
Related MCP server: Zcash MCP Server
The zcash_capability_manifest tool gives agents a machine-readable scope map:
covered here: ZAP1 receipts, lifecycle attestations, proof verification, anchor state, memo decoding, and public chain context
excluded here: custody, seed handling, balance scanning, PCZT signing, shielded spend construction, and wallet-server synchronization
composition rule: use this server before or after wallet-layer actions to create, query, and verify receipts
Good fits:
agent action receipts
payment and invoice proof packets
wallet action receipts
external action receipts
operator lifecycle events
grant proof packets
compliance audit packets
policy and reputation attestations
public anchor verification for private workflows
cross-agent handoffs where the receiver needs proof, not custody
Poor fits:
holding keys
scanning wallet balances
signing PCZTs
broadcasting shielded spends
replacing a wallet SDK
Use zcash_receipt_template first when you are wiring ZAP1 into a product. It
returns a customer-ready workflow for the receipt type you want:
agent_action: prove an agent performed a named action with specific input
and output hashes
payment_receipt: bind invoice or payment metadata to a ZAP1 leaf and later
prove inclusion under an anchored root
operator_lifecycle: record deployment, upgrade, incident, recovery, or
policy state as a verifiable lifecycle event
policy_attestation: record an agent, service, or workflow policy decision
as a verifiable event
Expected flow:
Call zcash_capability_manifest to confirm the attestation boundary.
Call zcash_receipt_template for the use case.
For wallet actions, call zap1_wallet_receipt_request to convert the wallet
result into hash-only attest_event arguments.
Call attest_event to create the typed ZAP1 leaf.
Call get_anchor_status to check whether the leaf is anchored or waiting.
Call verify_proof to verify tree inclusion.
Call zap1_prove_receipt to fetch a handoff proof bundle.
Acceptance checks:
the receipt has a leaf hash
the leaf verifies under a returned Merkle root
v2 receipts retain every sibling position and the committed leaf_count
anchor finality comes from a separately verified root-opening artifact, not txid, height, or status metadata alone
another verifier can repeat verification without trusting the original agent
no private keys, seeds, PCZTs, or wallet scan state were sent to this server
Red-team rejects:
treating a payment URI as proof of payment
treating an unanchored leaf as final settlement evidence
treating a quote, route, or intent hash as settlement evidence by itself
asking this server to sign, scan balances, recover seeds, or hold keys
mixing custody claims into ZAP1 receipt claims
hiding the distinction between wallet action and receipt verification
ZAP1 verifies ZAP1 receipts. It does not audit or guarantee any external wallet, route, payment, bridge, exchange, or settlement system referenced by a receipt.
Tool | What it does |
| Machine-readable scope map for agent use: covered surfaces, excluded wallet functions, and composition rules |
| Validate only the shape of a frozen v1 receipt packet; v1 cannot prove inclusion or anchor confirmation |
| Customer-ready receipt workflow for agent actions, payment receipts, operator lifecycle events, and policy attestations |
| Convert a wallet-layer action result into hash-only ZAP1 receipt request fields |
| Map bounded external verification evidence into the supported ZAP1 |
| Validate legacy v1 external-receipt shape without claiming cryptographic inclusion or anchor confirmation |
| Verify the official proof-bundle-v2 plus retained |
| Extract the portable proof artifact from a ZAP1 receipt |
| Compute depth arithmetic from supplied heights without claiming chain confirmation |
| Validate legacy v1 receipt-sequence shape without claiming proof or anchor validity |
| Compare two ZAP1 receipts for claim, evidence, event, and anchor divergence |
| Replay a receipt sequence against a caller-supplied event-type policy |
| Create a typed ZAP1 attestation leaf for later anchoring |
| Verify a ZAP1 Merkle proof |
| Fetch the full Merkle proof bundle for a leaf hash |
| All ZAP1 Merkle root anchors with txids and block heights |
| Current Merkle tree state: root, unanchored leaves, recommendation |
| ZAP1 protocol stats: leaves, anchors, types |
| Recent ZAP1 attestation events with type, wallet hash, leaf hash |
| Attestation summary for a ZAP1 agent ID |
| Register an agent identity via AGENT_REGISTER attestation |
| Fetch agent bond data and policy compliance as a reputation object |
| Decode Zcash memo payloads: ZAP1 typed, ZIP 302, text, binary |
| Create ZAP1 receipt metadata for an external payment workflow |
| Poll receipt-invoice status until paid or timeout |
| Current chain height from Zebra |
| Raw transaction data by txid |
| Verify a ZAP1 Merkle proof on-chain via EVM contract |
npx @frontiercompute/zcash-mcpOr install globally:
npm install -g @frontiercompute/zcash-mcpAdd this to your MCP config:
{
"mcpServers": {
"zcash": {
"command": "npx",
"args": ["@frontiercompute/zcash-mcp"]
}
}
}Restart your client and ask for the current Zcash block height. Read-only tools do not need an API key.
Get a trial key for write operations:
curl -s -X POST https://api.frontiercompute.cash/trial-keyEnvironment variables:
Variable | Default | Description |
|
| Zebra node JSON-RPC endpoint |
|
| ZAP1 attestation API |
| none | API key for write operations |
Add to ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"zcash": {
"command": "npx",
"args": ["@frontiercompute/zcash-mcp"],
"env": {
"ZEBRA_RPC_URL": "http://127.0.0.1:8232",
"ZAP1_API_KEY": "your-key-here"
}
}
}
}The server communicates over stdio using JSON-RPC. Point your MCP client at the
zcash-mcp binary.
git clone https://github.com/Frontier-Compute/zcash-mcp.git
cd zcash-mcp
npm ci
npm run build
node dist/index.jsOffline verification covers the built stdio server and a clean-room install from the packed npm tarball:
npm run test:offlineLive verification hits a real Zebra RPC and ZAP1 API:
ZEBRA_RPC_URL=http://127.0.0.1:8232 \
ZAP1_API_URL=http://127.0.0.1:3080 \
ZAP1_API_KEY=your-key-here \
npm run test:livetest:live drives the MCP server over stdio and exercises the live tool surface,
not just the underlying HTTP endpoints. Set ZAP1_AGENT_ID if you want the
get_agent_status check to target a specific deployed agent.
GitHub Actions mirrors that split:
.github/workflows/offline-ci.yml runs deterministic packaging and MCP
handshake checks on every push and pull request.
.github/workflows/live-e2e.yml runs secret-backed live checks on main, on
a schedule, and by manual dispatch.
A running Zebra node for chain queries
The ZAP1 API for attestation, proof, anchor, event, and receipt tools
Memo decoding works locally with no external dependencies
Package | What it does |
Zcash and Bitcoin signing via Ika 2PC-MPC | |
OpenClaw skill for ZAP1 attestation | |
ZAP1 attestation client | |
Silo agent attestation via ZAP1 |
MIT
Create a typed ZAP1 attestation event leaf for later anchoring. Returns a leaf hash for verification.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | ZAP1 API key (or set ZAP1_API_KEY env var) | |
| event_type | Yes | Event type: DEPLOYMENT, CONTRACT_ANCHOR, AGENT_ACTION, GOVERNANCE_PROPOSAL, etc. | |
| input_hash | No | SHA-256 of action input | |
| action_type | No | Action type for AGENT_ACTION events | |
| output_hash | No | SHA-256 of action output | |
| proposal_id | No | Proposal ID for governance events | |
| wallet_hash | Yes | Wallet hash or agent identifier | |
| serial_number | No | Serial number or version tag |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It indicates a write operation ('Create') and returns a hash, but lacks details on auth requirements, side effects, rate limits, or the meaning of 'typed ZAP1 attestation event leaf'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. Front-loads the main action and return value. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, no output schema, and no annotations, the description is underspecified. It omits details about event types, anchoring process, verification usage, and required authentication (api_key noted in schema but not in description).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are fully described in the schema. The description adds no additional parameter meaning, resulting in baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a typed ZAP1 attestation event leaf for later anchoring and returns a leaf hash for verification. The verb 'Create' and resource are specific, and it distinguishes from sibling tools like decode_memo or get_agent_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as zap1_create_receipt_invoice or other anchoring tools. The description implies its purpose but does not provide usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Decode a Zcash shielded memo field. Handles ZAP1 typed memos, ZIP 302, plain text, and raw binary.
| Name | Required | Description | Default |
|---|---|---|---|
| memo | Yes | Memo data as hex string or base64 (max 1024 bytes decoded) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses supported input formats and encoding, but does not describe the output format or error behavior. For a decode tool, it could mention that it is read-only and what the return value looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence of about 20 words. It starts with the main purpose, then lists supported formats. No redundant or extra information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description could clarify the return format (e.g., decoded text or structured data). It also lacks mention of error handling. However, it adequately covers the core functionality and input variants for a simple decode tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the 'memo' parameter as hex/base64 with a max size. The description adds value by specifying the types of memos handled (ZAP1, ZIP 302, plain text, raw binary), which enriches the understanding of what the decode operation covers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Decode') and the resource ('Zcash shielded memo field'). It lists specific formats (ZAP1, ZIP 302, plain text, raw binary), distinguishing it from sibling tools which cover different functionalities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for decoding various memo formats but does not explicitly state when to use it or when not to. No alternatives are mentioned, though sibling tools don't include another memo decoder.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get attestation summary for a ZAP1 agent: registration, policies, actions, event history.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes | Agent identifier |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It indicates a read operation but does not disclose specifics like required permissions, error handling, or rate limits. Adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, straightforward sentence that conveys the tool's purpose and what it returns. No extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with one well-documented parameter and no output schema, the description sufficiently explains the tool's purpose and return content. Lacks explanation of response format but is adequate given complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (agent_id) with schema description 'Agent identifier' and 100% coverage. Description adds context about the summary content but not additional parameter semantics beyond what schema provides. Baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it gets an attestation summary for a ZAP1 agent and lists included components (registration, policies, actions, event history). This distinguishes it from sibling tools like get_anchor_status or get_events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as get_anchor_status or get_events. The description does not mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all ZAP1 Merkle root anchors with Zcash txids and block heights.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear the full burden. It reveals that the tool returns data but does not mention any side effects, performance characteristics, or limitations. The description is adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It efficiently conveys the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter list tool without an output schema, the description adequately explains what is returned. However, it does not mention ordering, limits, or whether it includes pending anchors. Slightly incomplete but sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so baseline is 4. The description adds no param info because none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the specific resource 'all ZAP1 Merkle root anchors', including the returned data fields (txids and block heights). It distinguishes from siblings like get_anchor_status or get_block_height.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool or when alternatives are better. The description does not mention sibling tools or provide context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current ZAP1 Merkle tree state: root hash, unanchored leaves, anchor recommendation.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It discloses that the tool returns current state components but does not mention side effects or permissions. For a simple read-only query, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys purpose and return content with no extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description should compensate by explaining return values. It lists three items but lacks details on their types or format. For a zero-parameter tool, it is mostly complete but could be more precise.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and schema coverage is 100%. The description adds value by specifying exactly what state information is returned, beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action ('Get') and the resource ('current ZAP1 Merkle tree state'), listing three specific components: root hash, unanchored leaves, anchor recommendation. This distinguishes it from sibling tools like get_anchor_history or verify_proof.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no context about typical use cases, prerequisites, or scenarios where it should be avoided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current Zcash chain height from Zebra.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. It indicates a read operation ('Get') but does not explicitly state it is non-destructive, fail-safe, or clarify authorization needs. For a simple getter, this is adequate but not exemplary.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the main action. No extraneous words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no inputs, no output schema), the description is sufficiently complete. It specifies the data source ('Zebra') and the output ('current chain height'). However, it does not mention the return format or error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the schema description coverage is 100% (empty schema). The description adds no parameter information, which is acceptable since none exist. A baseline of 4 is appropriate for zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get the current Zcash chain height from Zebra.' It uses a specific verb ('Get') and a specific resource ('current Zcash chain height'), and distinguishes from sibling tools which are primarily about proofs, receipts, and attestations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. However, the purpose is straightforward and no siblings serve the same function. A score of 3 reflects the lack of explicit context despite the simplicity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recent ZAP1 attestation events. Returns event type, wallet hash, leaf hash, and timestamps.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of events (default 20) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full burden but discloses minimal behavioral traits. It mentions 'recent' without defining recency and does not describe ordering, pagination, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence that efficiently states purpose and return fields. It is front-loaded and contains no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should provide more context about default behavior (e.g., default limit is 20, ordering, empty result handling). It only partially covers the tool's semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter 'limit', which already includes a description and constraints. The tool description adds no additional semantic value beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves recent ZAP1 attestation events and specifies the returned fields: event type, wallet hash, leaf hash, and timestamps. However, it does not differentiate from sibling tools like attest_event or get_anchor_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any context about its suitability. The description only states what it does, not when it should be chosen.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get ZAP1 protocol stats: total leaves, anchors, type distribution, and tree height.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose whether the tool is read-only, its safety profile, or any side effects. For a stats retrieval tool, a read indication would be helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence that efficiently communicates the tool's purpose and output without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description adequately lists the returned metrics. Could be slightly more explicit about the 'stats' scope, but sufficient for low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the description cannot add meaning beyond the schema. Following the baseline guideline for zero parameters, a score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves ZAP1 protocol stats and enumerates specific metrics (total leaves, anchors, type distribution, tree height). It distinguishes itself from sibling tools that focus on individual entities or operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The single sentence provides no context about appropriate usage scenarios or when to avoid it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get raw transaction data by txid from Zebra.
| Name | Required | Description | Default |
|---|---|---|---|
| txid | Yes | Transaction ID (64-char hex) | |
| verbose | No | Return decoded JSON instead of raw hex (default true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states 'raw transaction data' but default behavior returns decoded JSON (verbose=true), creating slight ambiguity. Basic read nature is clear, but lacks details on rate limits or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with key verb and resource. Concise and no wasted words, though could clarify default output format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple lookup tool with two parameters and no output schema, but lacks information about return values, error handling, or performance implications.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are fully documented in schema. Description adds no additional meaning beyond what schema provides; it only mentions 'by txid' which is already evident.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Get', the resource 'raw transaction data', and the source 'Zebra'. It distinguishes from sibling tools like 'decode_memo' or 'verify_proof' as no other tool specifically retrieves transaction data by txid.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage when you have a txid and need transaction data, but does not provide explicit guidance on when to use this tool versus alternatives, nor any when-not scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify a ZAP1 Merkle proof. Checks whether a leaf hash exists in the ZAP1 attestation tree and returns the proof path.
| Name | Required | Description | Default |
|---|---|---|---|
| leaf_hash | Yes | Hex-encoded leaf hash to verify (64 chars) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries full burden. States core behavior (verification, returns proof path) but omits side effects, permissions, error conditions, or success/failure details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise (21 words over two sentences), front-loaded with main action, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple 1-param tool with no output schema, but lacks output format details and error handling. Could be more explicit about return value structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with description and pattern. Tool description adds no extra meaning beyond schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb (verify), resource (ZAP1 Merkle proof), and specific action (checks leaf hash existence, returns proof path). Distinguishes from siblings like zap1_prove_receipt and zap1_verify_evm.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. No prerequisites, exclusions, or context provided despite 18 sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create ZAP1 receipt metadata for an external payment workflow. Returns invoice metadata for later receipt verification; this server does not sign, scan, or broadcast.
| Name | Required | Description | Default |
|---|---|---|---|
| memo | Yes | Memo text attached to the invoice (max 512 bytes) | |
| amount_zat | Yes | Payment amount in zatoshis (1 ZEC = 100_000_000 zatoshis) | |
| wallet_hash | Yes | Wallet identifier or hash for routing the payment |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present; description discloses that it only creates metadata and does not sign/scan/broadcast, providing adequate behavioral context for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, return value, and limitations; lacks detail on return format or error handling, but sufficient given simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and description adds no additional meaning beyond the schema's own parameter descriptions; baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Create ZAP1 receipt metadata' and distinguishes from siblings like zap1_prove_receipt by specifying what it does not do (sign, scan, broadcast).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Indicates use case 'for an external payment workflow' and clarifies limitations, but does not explicitly name alternative tools for signing or broadcasting.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a ZAP1 Merkle proof bundle for a leaf hash. Returns the full proof: leaf, path, root, and anchor.
| Name | Required | Description | Default |
|---|---|---|---|
| leaf_hash | Yes | Hex-encoded leaf hash (64 chars) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It implies a read-only fetch operation and lists return components (leaf, path, root, anchor), but does not disclose potential side effects, authentication needs, or error conditions. Adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no extraneous words. Efficiently conveys the action and return value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter fetch tool, the description adequately covers input and output. However, without an output schema, more detail on the return structure or error handling would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a description for 'leaf_hash' already provided. The tool description adds no new semantic information beyond restating the parameter's purpose, so no value added beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Fetch' and the resource 'ZAP1 Merkle proof bundle' for a 'leaf hash'. It distinguishes from siblings by being specific to proving receipts, while siblings like 'verify_proof' and 'zap1_create_receipt_invoice' serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as 'verify_proof' or 'zap1_create_receipt_invoice'. The description only states what it does, not the context or prerequisites for its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify a ZAP1 Merkle proof on-chain via the EVM ZAP1Verifier contract. Checks that a leaf hash is included in a registered Zcash anchor root. Supports Sepolia (testnet), Base, and Arbitrum.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | Yes | EVM chain to verify on | |
| siblings | Yes | Ordered hex sibling hashes for the Merkle proof | |
| leaf_hash | Yes | 64-char hex leaf hash (no 0x prefix) | |
| positions | Yes | Bit-packed position flags (0 = left, 1 = right per level) | |
| expected_root | Yes | 64-char hex expected Merkle root |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must fully convey behavior. It states verification via contract but does not clarify whether it's a read or write operation, gas implications, error handling, or side effects. Insufficient for an on-chain interaction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, highly concise, front-loaded with the primary action and supported chains. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so description should explain return values or success/failure indicators. It does not mention what the tool returns (e.g., boolean or transaction hash) or behavior on verification failure. Missing contract addresses or references.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 5 parameters have schema descriptions (100% coverage). Description adds context about Zcash anchor roots and chains but does not add significant meaning beyond schema for individual params. Adequate but not exceptional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description specifies the tool verifies a ZAP1 Merkle proof on-chain, checks leaf hash inclusion in a Zcash anchor root, and lists supported chains (Sepolia, Base, Arbitrum). Clearly distinguishes from siblings like verify_proof and zap1_prove_receipt.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives, such as off-chain verification or other chain-specific tools. Missing when-not-to-use or contextual prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build a ZAP1 receipt request from a wallet-layer action result. The wallet keeps custody, signing, scanning, and broadcast; ZAP1 receives only bounded hashes.
| Name | Required | Description | Default |
|---|---|---|---|
| txid | No | Optional public Zcash transaction id when the wallet action produced one. | |
| amount_zat | No | Optional amount in zatoshis. Omit when amount should stay private. | |
| asset_code | No | Asset code or application asset label. Keep generic if the asset label is sensitive. | ZEC |
| claim_hash | No | Optional precomputed hash of the wallet action claim. | |
| action_type | Yes | Wallet-layer action type, for example shielded_send, invoice_paid, pczt_created, policy_approved, or sync_checkpoint. | |
| observed_at | No | Optional ISO timestamp or block reference for the wallet observation. | |
| result_hash | No | Optional hash of the wallet result object, log packet, or receipt returned by the wallet layer. | |
| subject_hash | No | Optional precomputed hash of the wallet, user, or account subject. Use this to avoid sharing identifiers. | |
| action_status | No | Wallet-layer action state being attested. | completed |
| evidence_hash | No | Optional precomputed hash of the supporting evidence packet. | |
| wallet_provider | Yes | Wallet, service, or product producing the action result, for example a wallet MCP, mobile wallet, service wallet, or custom product. | |
| action_reference | No | Wallet-local action, operation, invoice, quote, or policy reference. Hash first if sensitive. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes that ZAP1 receives only bounded hashes and wallet retains sensitive operations, providing useful privacy context. No annotations exist, so description partially compensates for missing behavioral cues like auth needs or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundancy. First states purpose, second adds key behavioral context. Efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
12 parameters, many optional with patterns, yet no guidance on usage patterns or composition. No output schema, so description doesn't explain what the tool returns. More context needed for complex parameter set.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 12 parameters with descriptions, so description adds minimal extra meaning. The phrase 'bounded hashes' hints at hash parameters but schema already details them. Baseline 3 due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it builds a ZAP1 receipt request from a wallet action result, distinguishing it from siblings like zap1_create_receipt_invoice. However, could more explicitly contrast with other ZAP1 tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like zap1_create_receipt_invoice or verify_proof. Implies use after a wallet action, but no exclusions or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Poll ZAP1 receipt-invoice status until paid or timeout. Returns public receipt status only; this server does not scan wallet state.
| Name | Required | Description | Default |
|---|---|---|---|
| invoice_id | Yes | Invoice ID returned by zap1_create_receipt_invoice | |
| timeout_seconds | No | Maximum seconds to wait for payment (default 300) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses polling behavior (until paid or timeout), that it returns only public receipt status, and that it does not scan wallet state. However, it does not clarify timeout behavior (e.g., error vs. status on timeout).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. The first sentence states the core action, and the second adds a crucial limitation. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description could specify return value structure. It mentions 'public receipt status' but is vague. However, it covers the essential context for a polling tool with timeout. Sibling tools provide some complementary context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, providing baseline 3. The description adds no specific parameter semantics beyond hinting at timeout usage. It does not detail format or constraints beyond schema defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool polls receipt-invoice status until paid or timeout, with a specific verb and resource. It also distinguishes itself from siblings by noting it returns only public receipt status and does not scan wallet state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use after invoice creation but does not explicitly state when to use it versus alternatives like zap1_wallet_receipt_request. It mentions server limitations but lacks explicit when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the ZAP1 capability manifest: what this MCP covers, what it deliberately excludes, and how agents should compose it with wallet-layer tools.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must cover behavior; it adds context about content and composition but does not disclose side effects, auth needs, or rate limits. Acceptable for a simple manifest tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, efficient, front-loaded with key information, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description fully explains what the tool returns and how to use it, leaving no gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, schema coverage 100% trivially. Description adds meaning beyond schema by explaining the manifest's purpose and usage, earning baseline 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Return' and the resource 'ZAP1 capability manifest', distinguishing it from sibling tools by specifying coverage, exclusions, and composition guidance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context on when to use (to obtain the manifest for composition with wallet-layer tools) but lacks explicit when-not-to-use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate a ZAP1 receipt packet against the frozen v1 receipt contract. Returns malformed, pending, or anchored.
| Name | Required | Description | Default |
|---|---|---|---|
| receipt | Yes | ZAP1 receipt packet to validate. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden. It mentions return states but does not disclose side effects (likely read-only), permissions needed, error behavior, or any other behavioral traits. For a validation tool, this is minimal but not absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action and result. It is efficient with no wasted words, though some structure (e.g., separating return states) could improve readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema or annotations, the description provides the key return states and purpose. However, it lacks usage context, behavioral details, and prerequisites. It is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (one parameter 'receipt' described as 'ZAP1 receipt packet to validate'). The tool description adds no additional meaning beyond the schema. Baseline of 3 is appropriate as the schema already documents the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Validate', the resource 'ZAP1 receipt packet', and specifies the contract ('frozen v1 receipt contract') and return states ('malformed, pending, or anchored'). It unambiguously distinguishes from sibling tools like 'zap1_prove_receipt' or 'zap1_verify_evm'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., when to use 'zap1_prove_receipt' instead). The description only states what it does, not when or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Register an agent identity on ZAP1 via an AGENT_REGISTER attestation. Returns the leaf hash and verification URLs for the registration event.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes | Unique agent identifier to register | |
| pubkey_hash | Yes | SHA-256 of the agent's public key (64-char hex) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that registration occurs via an attestation and returns a leaf hash and URLs, but does not mention side effects, permissions required, idempotency, error conditions, or what happens if the agent_id is already registered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core action ('Register an agent identity on ZAP1') and efficiently adds the mechanism and return values. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 required parameters, no output schema, and no annotations, the description adequately covers what the tool does and what it returns. It mentions the return types (leaf hash and verification URLs), which provides useful context. However, it could mention potential limitations or error conditions, but overall it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already defines both parameters with clear descriptions. The tool description does not add additional meaning beyond what is in the schema; it merely states the overall purpose. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Register an agent identity on ZAP1 via an AGENT_REGISTER attestation.' It also specifies the return values (leaf hash and verification URLs), making the purpose precise and distinguishable from sibling tools like get_agent_status or lookup_transaction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention preconditions, when not to use it, or suggest alternative tools for different tasks (e.g., checking status or verifying proofs).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a customer-ready ZAP1 receipt workflow for agent actions, payment receipts, operator lifecycle events, or policy attestations.
| Name | Required | Description | Default |
|---|---|---|---|
| use_case | No | Receipt workflow to generate. | agent_action |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only says it 'returns' a workflow, offering no information about side effects, permissions, or whether it is a read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundancy, efficiently conveying the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple one-parameter tool, but the absence of an output schema leaves ambiguity about the format of the returned workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter description is clear; the tool description merely paraphrases the enum values without adding new meaning, so baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns a customer-ready ZAP1 receipt workflow for specific use cases (agent actions, payment receipts, etc.), distinguishing it from general receipt tools by implying it produces a pre-formatted template.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists use cases but provides no guidance on when to use this tool versus alternatives like zap1_create_receipt_invoice, nor does it specify prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch an agent's reputation from ZAP1. Combines bond data and policy compliance into a single object: attestation count, violations, bonds, and compliant flag.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes | Agent identifier to look up |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It mentions fetching reputation and returning data, but does not disclose any behavioral traits such as authentication requirements, rate limits, data freshness, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, directly front-loaded with the action and purpose. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description adequately explains the returned object's fields. It could optionally specify types, but the current level suffices.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear parameter description. The description adds no additional meaning beyond what the schema already provides, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Fetch', the resource 'agent's reputation', and the source 'ZAP1'. It lists the specific fields returned (attestation count, violations, bonds, compliant flag), which distinguishes it from sibling tools like zcash_conformance_check or get_agent_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The sibling list includes many other tools, but no differentiation or contextual advice is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.3.0get_balancesend_shieldedzap1_create_receipt_invoicezap1_prove_receiptzap1_verify_evmzap1_wallet_receipt_requestzap1_watch_receipt_invoicezcash_capability_manifestzcash_conformance_checkzcash_create_invoicezcash_create_walletzcash_crosschain_swapzcash_prove_paymentzcash_receipt_templatezcash_shieldzcash_sign_mpczcash_verify_evmzcash_watch_paymentzcash_create_invoicezcash_create_walletzcash_crosschain_swapzcash_identity_registerzcash_prove_paymentzcash_reputation_scorezcash_shieldzcash_sign_mpczcash_verify_evmzcash_watch_paymentv0.2.2attest_eventdecode_memoget_agent_statusget_anchor_historyget_anchor_statusget_balanceget_block_heightget_eventsget_statslookup_transactionsend_shieldedverify_proofEach tool targets a specific aspect of the ZAP1 protocol with clear, non-overlapping purposes. Even similar-sounding getters (e.g., get_agent_status vs get_anchor_status) return distinct data, and verification tools differ by off-chain vs on-chain context.
Tools use mixed conventions: most use snake_case with verbs (attest_event, decode_memo), while a subset uses the 'zap1_' prefix (zap1_create_receipt_invoice). There is no uniform pattern, making it harder for an agent to predict tool names.
20 tools is well-scoped for the ZAP1 attestation and receipt system. Each tool serves a distinct function, and the number aligns with the complexity of the protocol without being overwhelming.
The surface covers the core ZAP1 workflow: creating attestations, receipts, proofs, verification (off-chain and on-chain), identity registration, and reputation. The server explicitly excludes wallet scanning, which is a deliberate boundary, but otherwise no major gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Hosted MCP server connecting AI assistants to 9,000+ apps and 40,000+ actions via Zapier.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Tenzro Network MCP server: wallet, identity, payments, inference, staking, bridges, verification.
MCP server connecting AI agents to non-custodial staking data across 130+ networks.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Frontier-Compute/zcash-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
