zshield-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| AUDIT_DIR | No | JSONL audit directory | ./audits |
| CHAIN_MODE | No | Chain mode: 'mock' only for now ('live' exits) | mock |
| ALLOWLIST_PATH | No | Path to JSON allow-list | ./allowlists/recipients.example.json |
| SPENDING_CAP_ZEC | No | Hard max ZEC per tool call | 0.1 |
| VIEW_KEY_FINGERPRINT_SALT | No | Salt for view-key fingerprints |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| zcash_payA | Pay shielded ZEC to an allow-listed recipient under a hard per-call spending cap. Mock chain by default; writes a viewing-key-fingerprinted audit log entry. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| policy |
TDQS
Scored across 1 tool
With only one tool, there is no possibility of overlap or misselection between tools. The single tool's purpose—paying shielded ZEC under a spending cap—is singular and unambiguous.
zcash_pay follows a clear snake_case resource_action pattern. There are no competing conventions to create inconsistency, so the naming is fully predictable for this server.
A single tool is very thin for a server named zshield-mcp, which implies broader policy, allow-list, and audit functionality. The pay tool itself is well-scoped, but the overall surface feels under-provisioned.
The description implies allow-listed recipients, spending caps, and audit logging, yet only the payment action is exposed. There are no tools to inspect the audit log, manage the allow-list, check balances, or query transaction status, leaving significant operational gaps.