Skip to main content
Glama
Frontier-Compute

Frontier-Compute/zcash-mcp

zap1_wallet_receipt_request

Generate a ZAP1 receipt request from a wallet action result, attesting to the action with bounded hashes while keeping sensitive data private.

Instructions

Build a ZAP1 receipt request from a wallet-layer action result. The wallet keeps custody, signing, scanning, and broadcast; ZAP1 receives only bounded hashes.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
txidNoOptional public Zcash transaction id when the wallet action produced one.
amount_zatNoOptional amount in zatoshis. Omit when amount should stay private.
asset_codeNoAsset code or application asset label. Keep generic if the asset label is sensitive.ZEC
claim_hashNoOptional precomputed hash of the wallet action claim.
action_typeYesWallet-layer action type, for example shielded_send, invoice_paid, pczt_created, policy_approved, or sync_checkpoint.
observed_atNoOptional ISO timestamp or block reference for the wallet observation.
result_hashNoOptional hash of the wallet result object, log packet, or receipt returned by the wallet layer.
subject_hashNoOptional precomputed hash of the wallet, user, or account subject. Use this to avoid sharing identifiers.
action_statusNoWallet-layer action state being attested.completed
evidence_hashNoOptional precomputed hash of the supporting evidence packet.
wallet_providerYesWallet, service, or product producing the action result, for example a wallet MCP, mobile wallet, service wallet, or custom product.
action_referenceNoWallet-local action, operation, invoice, quote, or policy reference. Hash first if sensitive.
Behavior3/5

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.

Conciseness5/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

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