zshield-mcp
Related Servers
Alternatives to zshield-mcp
No user-submitted related servers found.
Related Servers
- AlicenseAqualityBmaintenancePolicy-gated agent spend with signed receipts and rail-extract audit: a fail-closed gate issues a COSE receipt for every allowed payment, and the audit reconciles those receipts against a rail extract so a settlement with no receipt is named rather than assumed. It settles on a mock rail, holding no wallet and signing no transaction.51Apache 2.0
- AlicenseNot gradedqualityCmaintenanceEnables agents to inspect pot balances, deposits, deposit addresses, and spend approvals, and to pay for PaidResources on spark/USDB or send to allowlisted Spark addresses within a per-spend cap. Transactions above the cap become human approval tickets, and the pot key remains in the OS keychain so nothing is signed until approval.MIT
- FlicenseNot gradedqualityCmaintenanceEnables AI agents to propose wallet payments while a local, human-authored policy decides whether each transaction is approved, requires human confirmation, or is refused, and records every decision in a signed, append-only ledger.-
- AlicenseBqualityBmaintenanceEnables AI agents to make policy-scoped payments with spending caps, recipient allowlists, approval thresholds, instant revocation, and an append-only audit trail in a sandbox wallet.10MIT
- AlicenseNot gradedqualityCmaintenanceEnables an AI agent to manage a Bitcoin wallet and request payments through MCP, while every spend requires a per-payment human approval code and defaults to signet.MIT

send21-budgetofficial
AlicenseNot gradedqualityBmaintenanceLets an AI agent propose crypto payments under enforced per-period caps, per-payment limits, and allowed recipients and coins, while holding only a guard token so that a human reviews and signs every draft in their own wallet.MIT
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.