Agentpay Mcp

AgentPay MCP

[](https://www.npmjs.com/package/agentpay-mcp) [](https://glama.ai/mcp/servers/up2itnow0822/claw-pay-mcp) [](LICENSE) [](tests/) [](https://uspto.gov)

Compatible with x402 V1/V2 + Stripe MPP — protocol-agnostic spend controls.

agentpay-mcp is the human-first trust and policy layer above commodity execution rails (x402, ACP, UCP). OWS-compatible trust layer -- works on top of MoonPay Open Wallet Standard. Protocol-agnostic trust layer -- works with x402 AND Stripe MPP. While x402 settles $600M annualized — with AI agents driving 40% of protocol activity (March 2026) — the missing piece isn't payment execution. It's governance: who approved it, how much can be spent, and what happens when the agent tries to exceed its budget. That's what agentpay-mcp provides.

> ACP handles what agents SELL. agentpay-mcp handles what agents BUY. ACP (Agent Commerce Protocol) enables agents to list services, negotiate, and receive payments. agentpay-mcp is the complementary layer — controlling what agents spend when consuming paid APIs, tools, and services. Different problems, compatible solutions.

When your agent hits HTTP 402 Payment Required, it needs to pay and retry — with your approval, within limits you set. AgentPay MCP is a Model Context Protocol server that gives Claude, Cursor, and any MCP-compatible agent a payment wallet with hard spend caps, human-approval mode, and a full on-chain audit trail.

The MCP ecosystem now has 97M+ monthly downloads and 10,000+ active servers — agentpay-mcp is the only MCP-native full payment execution layer.

✅ Integrated into NVIDIA/NeMo-Agent-Toolkit-Examples (PR #17 merged) — payment infrastructure for NVIDIA's official agent toolkit.

📌 AgentIndex flagship offer and sandbox payment demo: How agents buy API calls safely and AgentPay MCP trust result.

📌 x402 ecosystem listing context is tracked in [docs/x402-ecosystem-submission.md](docs/x402-ecosystem-submission.md).

Who Uses agentpay-mcp?

agentpay-mcp is built for three buyer personas who all share the same problem: autonomous agents spending money without controls.

| Persona | Problem | What They Use agentpay-mcp For | |---------|---------|--------------------------------| | FinOps Practitioners (Fortune 500 AI spend owners) | 98% of FinOps teams now manage AI spend (FinOps Foundation 2026) — but no governance layer exists for autonomous agents | Cost center attribution, per-agent budget caps, CFO-ready spend dashboards, policy-as-code enforcement | | Platform Engineers (MCP / agent framework builders) | Agents call paid APIs at runtime with no native spend controls in x402, Stripe MPP, or MCP protocol | Drop-in spend governance middleware: daily caps, kill switches, per-task limits, audit trails | | Enterprise Compliance Teams (EU AI Act, SOC 2, internal audit) | EU AI Act Article 14 (enforced Aug 2, 2026) requires runtime human oversight and decision-time enforcement for autonomous agents | Human-approval queues, runtime kill switches, full on-chain audit trail for compliance evidence |

> FinOps teams: agentpay-mcp is the first governance layer designed for your workflows — not just for developers. Budget caps, approval thresholds, and cost attribution that slot into your existing FinOps tooling.

---

Why Trust Matters

McKinsey's 2026 AI Trust Maturity Survey quantifies what builders already feel: agent capability has outpaced agent governance.

| Finding | Stat | |---------|------| | Enterprises that formally approve agents before deployment | 14.4% | | Enterprises reporting at least one agent security incident | 88% | | Enterprises confident in agent IAM for payments | 18% |

The trust gap is the deployment gap. Enterprises aren't saying agents don't work — they're saying the oversight infrastructure (approval workflows, spending guardrails, identity verification, audit trails) hasn't kept pace.

AgentPay MCP addresses this directly:

• Human-approval mode — transactions above your threshold require explicit human confirmation before executing
• On-chain spend caps — enforced by smart contract, not application code. The agent cannot override them.
• Full audit trail — every payment attempt logged with merchant, amount, timestamp, approval status
• Fail-closed — any policy engine error produces rejection, never approval
• Non-custodial — private keys never leave the local machine

When 88% of enterprises have had an agent security incident, "trust by default" is not a viable architecture. AgentPay MCP is built for "verify, then trust" — which is the only model that scales.

---

Why Cost Governance Matters for MCP Agents

The Model Context Protocol gives agents access to powerful tools — but the protocol itself has no built-in mechanism for controlling what those tools cost. This isn't a theoretical gap. WorkOS's 2026 guide to MCP security explicitly identifies rate limiting, cost attribution, and per-call spend caps as unsolved problems at the MCP protocol level. Every MCP server can charge. No MCP client enforces budgets.

The result: an agent with access to 10 MCP servers can accumulate unbounded costs across sessions, with no standard way to attribute spend per tool, cap exposure per call, or halt runaway loops before they drain a wallet.

AgentPay MCP closes this gap at the infrastructure layer:

| MCP Cost Governance Gap | AgentPay MCP Solution | |---|---| | No per-call spend caps in the MCP spec | On-chain per-transaction caps — enforced by smart contract, not application logic | | No cost attribution across MCP servers | Full transaction history with merchant, amount, timestamp, and tool context per call | | No rate limiting for paid tool invocations | Daily aggregate spend limits — hard ceiling regardless of how many tools or sessions run | | No human oversight mechanism in the protocol | Human-in-the-loop approval — transactions above threshold queue for explicit human review | | No simulation/dry-run for cost estimation | Simulation mode — preview transaction cost and recipient before committing funds |

If you're building agents that interact with paid APIs, MCP spend limits and MCP cost governance aren't optional — they're the difference between a demo and a production deployment. AgentPay MCP is the open-source reference implementation for solving this at the protocol's edge.

---

Security & Dependencies

AgentPay MCP is built for enterprise MCP deployments where supply chain security matters.

• Zero LiteLLM dependency. No direct or transitive dependency on LiteLLM or any heavyweight LLM routing layer. When LiteLLM versions 1.82.7-1.82.8 were compromised on PyPI (March 2026), AgentPay MCP users were unaffected.
• Auditable, minimal dependency tree. The server runs on viem, @modelcontextprotocol/sdk, and a small set of auditable npm packages. No PyPI. No Python runtime required.
• Enterprise trust signal. Integrated into NVIDIA's official NeMo Agent Toolkit Examples (PR #17, merged). NVIDIA's review process validated the security posture before merge.
• Non-custodial architecture. Private keys never leave the local machine. On-chain spend caps enforce limits even if the agent or its key is compromised.
• Vercel deployment hardening. If you deploy AI agents on Vercel, review the [Vercel deployment hardening checklist](docs/vercel-deployment-hardening.md) before reconnecting paid tools after any OAuth, dashboard, CI, or environment-variable exposure.
• x402 scanner readiness. For paid API demos that need scanner-readable x402 support, use the [x402 scanner-readiness recipe](docs/x402-scanner-readiness.md).
• x402 Bazaar observability. For paid MCP tools entering searchable Bazaar catalogs, use the [x402 Bazaar observability recipe](docs/x402-bazaar-observability.md) to cover WithBazaar search metadata, unified auth, and EXTENSION-RESPONSES readback.
• x402 batch-settlement channels. For repeat paid MCP calls that use deposit, voucher, refund, and claim flows, use the [x402 batch-settlement channel recipe](docs/x402-batch-settlement-channels.md) to keep channel storage, voucher caps, recovery, and off-chain settlement audit trails production-safe.
• x402 multi-SDK batch-settlement parity. For providers testing x402 TypeScript and Go batch-settlement clients, use the [multi-SDK batch-settlement parity recipe](docs/x402-multi-sdk-batch-settlement-parity.md) to prove shared channel state, phased e2e results, signer separation, refund/recovery visibility, and proof bundle shape.
• x402 TVM readiness. For TVM/TON exact-payment offers from emerging x402 examples, use the [x402 TVM readiness note](docs/x402-tvm-readiness.md) to confirm unsupported TVM requirements fail closed until deliberate signing, gas, jetton, and settlement support exists.
• x402 MCP funding UX. For hosted fund-link and managed-wallet comparisons, use the [x402 MCP funding UX benchmark](docs/x402-mcp-funding-ux-benchmark.md) to keep onboarding speed separate from approval gates, daily caps, auditability, and non-custodial controls.
• Directory introspection readiness. For Glama, Smithery, and other MCP catalogs, use the [directory introspection readiness note](docs/directory-introspection-readiness.md) for verified npx, Docker, MCP name, and non-custodial metadata paths.
• x402 v2.11 paid MCP compatibility. Use the [compatibility proof](docs/x402-v211-paid-mcp-compatibility.md) for Payment-Signature, payment-response, mcp-session-id, CORS exposed headers, Streamable HTTP initialize order, receipt links, and Base Sepolia to Base mainnet cutover.
• Directory-grade metadata proof. Use the [registry/listing proof](docs/mcp-registry-listing-proof.md), docs/mcp-registry-listing.json, glama.json, smithery.yaml, and llms.txt for catalog crawlers and buyer agents.
• Chain-neutral x402 gateway profile. Use the [chain-neutral gateway profile proof](docs/x402-chain-neutral-gateway-profile.md), schema, and fixture to document supported networks, facilitator/settlement metadata, trial/refund policies, and directory manifests without leaking Base-only assumptions into non-EVM discovery.
• Multi-ledger x402 receipt normalization. Use the [multi-ledger receipt normalization proof](docs/x402-multi-ledger-receipt-normalization.md), schema, and XRPL fixture to normalize ledger labels, assets, settlement targets, Payment-Signature, payment-response, verification status, non-custodial boundaries, and unsupported-ledger refusals before signing.
• Wallet-action preflight profile. Use the [wallet-action preflight profile](docs/wallet-action-preflight-profile.md) and TRON fixture to require simulation, chain/resource caps, allowlists, recipient and amount confirmation, nonce guidance, and approval copy before irreversible sends, swaps, or resource purchases.
• Machine-payment directory listing pack. Use the [directory listing pack](docs/agentpay-machine-payment-directory-listing-pack.md) and [listing JSON](docs/agentpay-machine-payment-directory-listing.json) for MPP and paid-MCP directories without claiming unsupported non-EVM signing.
• Five-tool x402 parity proof. Use the [five-tool parity proof](docs/agentpay-five-tool-parity-proof.md) and [machine-readable map](docs/agentpay-five-tool-parity-proof.json) to map search, check, fetch, wallet, and pay flows to AgentPay's local-signer, approval-gated controls.
• Escrow and reputation boundary. Use the [escrow/reputation boundary proof](docs/agentpay-escrow-reputation-boundary.md) to keep x402 payment authorization separate from task escrow, identity, reputation, and work proof.
• Paid MCP proxy and discovery readiness. Use the [paid-proxy and discovery readiness pack](docs/paid-mcp-proxy-discovery-readiness.md) plus [listing JSON](docs/agentpay-paid-proxy-discovery-listing.json) for Toolstem/Cinderwright-style proxy and directory submissions.
• Dynamic paid MCP manifest drift. Use the [dynamic manifest drift proof](docs/x402-dynamic-paid-mcp-manifest-drift.md), schema, and Rug Munch fixtures to validate fresh .well-known/x402 snapshots, stale-metadata warnings, no-trial/pricing clarity, supported networks, and directory endpoint freshness before buyer agents sign.
• Smithery paid MCP installation. Use the [Smithery install proof](docs/smithery-paid-mcp-installation.md) and [examples/smithery-paid-mcp-installation](examples/smithery-paid-mcp-installation/) for Smithery CLI, Vercel AI SDK MCP, @smithery/api, approval gates, spend-limit defaults, and fresh x402 manifest checks. Do not claim live Smithery verification until the listing is verified.
• x402-native vs Stripe-proxy MCP. For builders comparing AgentPay MCP with emerging Stripe-proxy MCP repos, use the [x402-native vs Stripe-proxy note](docs/x402-native-vs-stripe-proxy.md) to keep approval gates, spend caps, audit rows, and non-custodial signing separate from proxy billing claims.
• Hosted x402 proxy verification. Before an agent pays a hosted x402 MCP gateway, use the [hosted x402 proxy buyer checklist](docs/hosted-x402-proxy-verification.md) to verify payment-required headers, non-zero payTo, network and asset allowlists, approval state, spend cap, audit correlation, and pooled-token lock-in.
• Paid MCP discovery and budget response. For SettleGrid-style discovery, metering, and budget-platform comparisons, use the [paid MCP discovery and budget response](docs/settlegrid-paid-mcp-discovery-response.md) to separate directory discovery from x402 buyer authorization.
• Buyer-flow parity for one-command x402 tools. For AgentScore Pay-style buyer CLI comparisons, use the [AgentPay buyer-flow parity checklist](docs/agentpay-buyer-flow-parity.md) to prove discover, check, dry-run, pay, spend caps, typed payment errors, quota envelopes, no-charge failures, idempotency, MCP exposure, and audit before signing.
• Paid MCP gateway hardening. For create-mcpay-style Worker scaffolds, use the [paid MCP gateway hardening checklist](docs/paid-mcp-gateway-hardening.md) to test signup, challenge parsing, key minting, atomic billing, scope defaults, no-charge validation failures, and buyer audit rows.
• Paid-provider health proof. For Voidly-style public provider health feeds, use the [paid-provider health proof checklist](docs/paid-provider-health-proof.md) to verify provider success rate, stale streaks, receipt state, x402 network, asset, payTo, and fail-closed routing before signing.
• Paid-tool quality thresholds. For Strale-style scored catalogs, use the [paid-tool quality thresholds proof](docs/paid-tool-quality-thresholds.md) to verify fresh score fields, stale-score warnings, provider-health snapshots, minimum-quality rejection, and approval gates before x402 signing.
• Authorized cybersecurity scans. For AgentAegis-style paid security tools, use the [authorized cybersecurity-scan payment profile](docs/authorized-cybersecurity-scan-profile.md) to require target authorization, allowed-domain binding, per-target spend caps, scan-rate policy, approval prompts, and audit receipt language.
• Post-quantum spend-envelope compatibility. For PQSafe-style buyer questions, use the [post-quantum spend-envelope assessment](docs/post-quantum-spend-envelope-compatibility.md) to map spend limits, allowlists, x402 receipts, approval gates, and audit metadata without claiming ML-DSA implementation.
• Payment-critical dependency pins. For x402 verifier and signing paths, Age

…

Source & license

This open-source MCP server is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: up2itnow0822
• Source: up2itnow0822/agentpay-mcp
• License: MIT
• Homepage: https://www.npmjs.com/package/agentpay-mcp

Install and usage instructions live in the source repository linked above.