Disclosure: I work on Pink Agentic AI Payments at PinkWallet, which is one of the 49 servers in this census. Pink was scored from its public docs by the same criteria as every other row, and it currently runs as a public sandbox with test money only. The full dataset is open so you can check every number: github.com/Pink-Agentic-Payments/payment-mcp-census.
Short answer: most payment MCP servers can move real money, but very few tell you how to stop an agent from spending too much. Of 37 servers that can create a payment, transfer, payout, charge or card, only 4 (11%) document a configurable spending budget, only 6 (16%) document a human-approval step, and only 1 (3%) documents a velocity limit.
If you are about to give an AI agent a payment tool over MCP, that gap is the thing to check first.
What we counted
We catalogued 49 payment-adjacent MCP servers (24 official vendor servers, 25 community ones) between 2026-10-08 and 2026-10-09, and read each one's own docs or README. For every server we recorded whether it can move money and whether it documents six spending controls:
- a per-agent or aggregate budget
- a per-payment limit
- a payee / merchant allowlist or block
- a human approval step
- a rate / velocity limit
- a sandbox / test mode
"Documents" means the control is described in the server's public docs. A server may have a control it does not document; for an agent builder, an undocumented control is hard to rely on.
The numbers
| Finding | Count |
|---|---|
| Servers that can move money | 37 of 49 (76%) |
| …that document a spending budget | 4 of 37 (11%) |
| …that document a per-payment limit | 5 of 37 (14%) |
| …that document a payee allowlist / block | 3 of 37 (8%) |
| …that document human approval | 6 of 37 (16%) |
| …that document a velocity / rate limit | 1 of 37 (3%) |
| …that document a sandbox / test mode | 8 of 37 (22%) |
| Listed servers whose GitHub repo returned 404 | 5 of 49 (10%) |
Community servers move money slightly more often than official ones: 20 of 25 community rows versus 17 of 24 official rows.
Who documents what
These are the money-moving servers that document at least one spending control (from the census table, generated straight from census.csv):
- Budget: Marqeta ("spending caps"), Gatewards ("per-agent spend caps"), MCPay ("a hard budget"), Pink (per-agent monthly budget).
-
Per-payment limit: Coinbase AgentKit / CDP (value-based policy rules), Crossmint Checkout (
maxCost), MCPay, x402search-mcp, Pink. - Payee allowlist: Coinbase AgentKit / CDP, Marqeta, Pink.
-
Human approval: Stripe (confirmation for refunds and outbound payments), Crossmint (
awaiting_input), Ramp ("managing approvals"), GoCardless ("with user confirmation"), SpendNod, Pink (pending_human). - Velocity limit: Marqeta only.
No single control is common. The most-documented one, human approval, still appears in fewer than 1 in 6 money-moving servers.
Why this matters if you build agents
Prompts are not a spending limit. An instruction like "never spend more than $50" lives in the model's context, and the model can misread it, forget it, or be talked out of it by a prompt injection in a web page or an email. A control that actually holds has to sit outside the model, in the system that holds the money, and has to be checked before the payment executes.
A companion survey of 12 popular agent frameworks (LangChain/LangGraph, CrewAI, OpenAI Agents SDK, Vercel AI SDK, Google ADK, AutoGen, Semantic Kernel, LlamaIndex, Pydantic AI, Mastra, Claude Agent SDK, smolagents) found that 0 of 12 document a spending budget in currency for tool calls, while 10 of 12 offer some form of human approval and 9 of 12 a max-steps limit (agent-framework-spend-guardrails). The frameworks can pause an agent; they do not know what a tool call costs.
So in practice the spending controls have to come from the payment layer. When you evaluate a payment MCP server, ask five questions:
- Can I set a budget per agent, not just per account?
- Is there a per-payment cap, enforced server-side?
- Can I restrict who the agent may pay?
- Can a payment above a threshold go to a human and wait, with a default of "no" if nobody answers?
- Is there a sandbox so I can test the rules with fake money first?
How Pink approaches it (one data point, not the only answer)
Pink's MCP server gives the agent a pink.request_payment tool instead of a card. Every request is checked on the server against circuit breakers (agent registered and active, monthly budget, company daily ceiling) and then against the company's rules, top to bottom. The answer is one of three: allowed (the agent gets a single-use credential locked to one payee and one amount, expiring in about 15 minutes), pending_human (a person approves or rejects; silence means no), or blocked. Unmatched requests default to blocked. The public sandbox at agentic-sandbox.pinkwallet.com uses test credentials only; production is not yet available.
If you want to try to break it, there is an open challenge: can you make an AI agent overspend?
Get the data
- Dataset, method and every source URL: payment-mcp-census (CC BY 4.0)
- Framework survey: agent-framework-spend-guardrails
- A longer comparison with notes per server: Payment MCP servers compared
If your server is in the census and we got a row wrong, open an issue on the repo with a link to your docs and we will correct it.
Top comments (10)
A budget written in the docs or the prompt doesn't stop a tool call, so I'd check where the cap is enforced. In our setup it sits in the buyer's wallet client, and the server only accepts a payment that matches the quote it issued.
That is the right question to ask of any setup: where is the cap enforced? Putting it in the buyer's wallet client plus a server that only accepts a payment matching its own quote closes both ends, the agent cannot overspend and the merchant cannot overcharge. Out of interest, how do you handle a cap shared across several agents using different wallet clients?
We don't solve that one yet. Each payment is checked against its own quote, so the server never sees what the other agents spent. A shared cap needs one place that sees every spend, and the simplest version I know is one funding wallet that hands each agent a capped allowance. Are you running into this with a real setup?
Good to see the disclosure up front and the dataset open. One thing on reading the percentages: with 37 money-moving servers, the intervals are wide. 4 of 37 budgets is 11% with a 95% Wilson interval of roughly 4% to 25%; 6 of 37 approvals is 16% (about 8% to 31%); the single velocity-limit server is 3% (about 0.5% to 14%). So "very few" holds, but "human approval is more common than a budget" does not separate at this sample size, and neither does the 20/25 community versus 17/24 official gap (80% vs 71%, intervals overlapping heavily).
The criterion is also one-sided in a useful way: "documents" can only undercount, so these are floors. I'd add one column that is checkable the same way and matters more to an agent builder: whether the money-moving tools are separable from the read-only ones (an allowlist of tool names, or a read-only mode), since that is the control you can apply from the client side even when the server has no budget. How many of the 37 expose a read-only flag?
You are right, and thank you for doing the intervals. At n=37, "approval is more common than a budget" does not separate, and neither does the community vs. official gap; I should not have implied either. "Very few document a budget" holds, and since "documents" can only undercount, these are floors.
The read-only / tool-allowlist column is a good one because it is the control a client can apply even when the server has none. I do not have that count yet, so I have proposed it on the repo together with showing the intervals in the README: github.com/Pink-Agentic-Payments/p...
The 37-of-49 number is the one worth sitting with: moving money is the easy part, stopping it is the hard part. Your point that prompts are not spending limits is the right frame, and the framework survey backs it up: 0 of 12 frameworks know what a tool call costs, so the guardrail has to live in the payment layer.
The strongest structural fix in your census is the single-use credential, and it goes further than a budget field. If the agent never holds a standing key, replay stops being a risk: there is no durable credential to replay, and a prompt injection can propose a payment but nothing executes until a separate context authorizes it against an amount, a payee and a deadline. That turns human approval from a checklist item into a real gate.
That propose, confirm, execute split is the pattern we build around at CAI: the agent proposes, the user confirms, a short-lived authorization executes. No standing key for the model to lose.
Agreed: no standing key means nothing durable to replay or leak, and a prompt injection can at most propose. Propose, confirm, execute with a short-lived authorization is the cleanest way I know to make human approval a real gate rather than a checkbox.
The one addition I would make is that most payments should never reach the confirm step at all: rules decide the routine ones, and only the exceptions go to a person, otherwise people start approving without reading.
The same gap sits one layer up, in metered data tools, where an agent spends per row rather than per payment. What made the budget enforceable in my setup was a free count before the run: the tool returns how many rows match and the price per row, so a human approves "1,625 rows at this rate, here are ten of them", not a dollar ceiling in a prompt. The cap still sits on the run, server-side, but a cap without a count stops the agent mid-list, which is worse than not starting. Your question 4, a human who waits and defaults to no, pairs well with that count.
The budget gap is the part that worries me most, but I would add one failure mode the census rows will not show: a timeout after the charge already landed.
If the agent retries under a new attempt id because the first call looked dead, the budget check runs again against a fresh request. You can burn the same payment twice while the documented ceiling still looks fine on paper. A per payment limit does not fix that either unless the server keys the debit and returns the original result on a same key retry.
Human approval has the same hole. Approving once, then retrying after a timeout without looking up the prior outcome, is how you get a second debit under a still valid approval.
So when I read a payment MCP README now I look for three things, not one: a spend ceiling, an approval step, and what the server does on a same key retry versus an unknown outcome that needs a status lookup first.
This is the failure mode I would most like to add to the census, thank you. A timeout after the charge landed, retried under a new attempt id, passes every documented control: the ceiling, the per-payment limit and even a still-valid approval. Your three-question read of a README (ceiling, approval, and same-key retry vs. unknown outcome that needs a status lookup) is a better checklist than the one in the post.
I have proposed it as a new column on the dataset, credited to you: github.com/Pink-Agentic-Payments/p...