Zcash MCP Server

ZAP1 receipts for Zcash agents: verify workflows without trusting the server. The zcash mcp mcp server wraps that behind the Model Context Protocol, so an assistant can use it through 14 defined tools rather than through you.

What it actually does

• 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

Its toolset

Everything the assistant can do here goes through one of these:

• zcash_capability_manifest — Machine-readable scope map for agent use: covered surfaces, excluded wallet functions, and composition rules
• zcash_conformance_check — Validate a ZAP1 receipt packet against the frozen v1 receipt contract
• zcash_receipt_template — Customer-ready receipt workflow for agent actions, payment receipts, operator lifecycle events, and policy attestations
• zap1_wallet_receipt_request — Convert a wallet-layer action result into hash-only ZAP1 receipt request fields
• zap1_attest_external_action — Build a ZAP1 receipt request for an action executed by an external rail without routing, signing, custody, or settlement
• zap1_verify_external_receipt — Validate an external-action ZAP1 receipt packet without trusting or calling the external rail
• zap1_extract_proof_artifact — Extract the portable proof artifact from a ZAP1 receipt
• zap1_check_anchor_freshness_at_height — Check anchor confirmation depth from supplied Zcash heights
• zap1_verify_receipt_chain — Validate a sequence of ZAP1 receipt packets and summarize anchor state
• zap1_compare_receipt_claims — Compare two ZAP1 receipts for claim, evidence, event, and anchor divergence
• zap1_audit_event_log — Replay a receipt sequence against a caller-supplied event-type policy
• attest_event — Create a typed ZAP1 attestation leaf for later anchoring

Adding it to your client

@frontiercompute/zcash-mcp on npm is all you need. Most clients run it directly, so configuration is a few lines and a restart.

Configuration

You will need 4 environment variables: ZEBRA_RPC_URL, ZAP1_API_KEY, ZAP1_API_URL, ZAP1_AGENT_ID. The server will not start without them, which is usually why the tools fail to appear on a first run. Keep credentials in your client's env block or a secrets manager rather than in a file you might commit.

When to reach for it

This sits in the payments and commerce group, where several servers overlap in what they claim to do but differ sharply once you actually set them up. Zcash MCP's toolset — zcash_capability_manifest, zcash_conformance_check, zcash_receipt_template and 11 more — is a fair guide to whether it matches your workflow. It is maintained by frontier-compute; worth a glance at recent repository activity before you build anything load-bearing on it.

We check each listing at SyncDev against the project's documentation before it goes live — if something here drifts out of date, it is a bug worth reporting.

Caveats

• It runs with your machine's permissions. That is convenient and also the reason to think about what you point it at before you approve a tool call.
• With 14 tools registered it takes up a noticeable share of the context window; turn it off in projects that never touch Zcash MCP.
• Missing credentials fail quietly in some clients — if no tools show up, check the environment block first.
• MCP clients confirm each tool call by default. Leave that on until you have watched what the zcash mcp mcp server does with a few real requests.