Zcash MCP server

zcash-mcp

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.

Why ZAP1

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:

agent.

1. attest: create a typed event leaf.
2. anchor: commit leaves into a Merkle root anchored to Zcash.
3. prove: return a receipt packet for a leaf.
4. verify: let another party check the receipt without trusting the original

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.

Capability Boundary

The zcashcapabilitymanifest tool gives agents a machine-readable scope map:

state, memo decoding, and public chain context

• covered here: ZAP1 receipts, lifecycle attestations, proof verification, anchor

shielded spend construction, and wallet-server synchronization

• excluded here: custody, seed handling, balance scanning, PCZT signing,

create, query, and verify receipts

• composition rule: use this server before or after wallet-layer actions to

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:

Shortened. The full README is on GitHub.