Disclosure: I work at PinkWallet, which builds Pink Agentic AI Payments, an approval layer for agent payments (public sandbox, test money only). This post is mostly about our readers' findings, not our product.
Short answer: a documented spending budget is not enough to stop an AI agent from overspending. Readers of our census of 49 payment MCP servers found six gaps that a "does it document a budget?" column cannot see: retries under a new attempt id, parallel agents racing on one budget, budget checks that fail open, cost hidden in an input field, standing credentials the agent can replay, and money-moving tools that cannot be separated from read-only ones. They also showed that our headline percentages have wide error bars. Every point below links to the comment where a reader made it.
Earlier this month we published We checked 49 payment MCP servers. 37 can move money. Only 4 document a spending budget and 0 of 12 AI agent frameworks can cap what an agent spends in dollars. The two posts drew 18 comments (our replies included). Most reader comments did not argue with the data; they pointed at what the data could not show. That is more useful than agreement, so here it is in one place, with credit.
@chrissellers described the failure mode that worried them most: the payment call times out, but the charge already went through. The agent thinks the call died and retries under a new attempt id. The budget check runs again against what looks like a fresh request, so the same payment can be made twice while the documented ceiling "still looks fine on paper".
Their point is that neither a per-payment limit nor human approval fixes this on its own. An approval given once can be reused by a retry that never looks up the outcome of the first call. What fixes it is the server keying the debit, returning the original result on a same-key retry, and telling the client to look up status when the outcome is unknown.
Their reading rule for a payment MCP README is now three checks, not one: a spend ceiling, an approval step, and what the server does on a same-key retry versus an unknown outcome.
What our census measured: not this. We did not score idempotent retries. It is now a proposed column.
@ranareebaal builds multi-agent platforms for clients. Their problem was never a single call; it was not knowing at month end which agent in the tree had burned the budget.
The concrete gap: when several agents share one budget and run in parallel, two calls can each see "$40 left" and both go through. A check-then-spend hook leaks under concurrency. The control layer has to reserve the estimated amount atomically before the call and settle the real cost afterwards.
They also asked a question we could not answer from our survey: do any of the 12 frameworks run the spend hook before parallel tool calls are dispatched, or only per call? We did not test that.
@fable7 agreed that a pre-call hook (our column C2) is the right place for a cap, with two conditions: it must answer without asking the model, and it must fail closed. If the budget service is unreachable when the hook fires and the hook returns "allow", there is no gate at all.
They also suggested splitting our per-run budget column for coding agents, where the expensive thing is rarely a priced tool call and usually a retry loop burning tokens.
What our census measured: whether a control is documented, not what it does when its own dependency is down. Very few READMEs say.
@kevin_hall showed that a framework with no currency support can still enforce a cap when the tool's input carries the number that drives the cost. Metered data APIs charge per row, and the row cap is an argument (maxResults). A per-tool hook that reads the arguments can refuse a call above the approved number before it runs. In their test with Claude Code hooks, the hook alone turned a 25,000-row pull into a 100-row sample.
A second reader, @kevinhall, added the other half: a free count before the run. The tool returns how many rows match and the price per row, so a person approves "1,625 rows at this rate, here are ten of them" instead of a dollar ceiling written in a prompt. As they put it, a cap without a count stops the agent halfway through a list, which can be worse than not starting.
What our census measured: neither. Both are now proposed columns: "does the tool expose the quantity the charge is based on" and "is there a free quote or count before spending".
@cailab argued that the strongest fix in our census is the single-use credential, and that it goes further than a budget field. If the agent never holds a standing key, there is nothing durable to replay. 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: propose, confirm, execute.
@whiteknightonhorse made a related point about where the cap is enforced: in their setup it sits in the buyer's wallet client, and the server only accepts a payment that matches the quote it issued.
@arhancanli proposed a column that an agent builder can act on even when the server has no budget at all: can the money-moving tools be separated from the read-only ones (a tool allowlist or a read-only mode)? That is a control you apply from the client side. They asked how many of the 37 money-moving servers expose one. We do not know yet.
@arhancanli also corrected how our percentages should be read. With only 37 money-moving servers, the 95% Wilson intervals are wide:
| Finding | Share | 95% interval (Wilson) |
|---|---|---|
| Document a spending budget | 4 of 37 (11%) | about 4% to 25% |
| Document a human approval step | 6 of 37 (16%) | about 8% to 31% |
| Document a velocity limit | 1 of 37 (3%) | about 0.5% to 14% |
So "very few servers document a budget" holds, but "approval is more common than a budget" does not separate at this sample size, and neither does the community-versus-official gap. They also noted that our criterion is one-sided: "documents" can only undercount, so these numbers are floors. We agree and will state that in the dataset README.
All of the above is collected in one public issue: payment-mcp-census issue #1. Proposed new columns, each checkable from public docs the same way as the existing ones:
maxResults (
Plus Wilson intervals in the README (@arhancanli). Parallel reservation (@ranareebaal) and fail-closed behavior (@fable7) are harder to check from docs alone; if you know a way to score them from public material, say so in the issue.
If we got your server's row wrong, open an issue on the repo and we will fix it with a link to your docs.
If you are letting an agent spend money this week, the readers' list turns into a short checklist that does not depend on any one vendor:
For context on our side: Pink's sandbox checks each payment request against a per-agent budget and rules server-side and returns allow, ask a human, or block. We have not yet published how it behaves on every failure mode above, and after this thread we should.
Readers found six gaps in two weeks. Here is the one we still cannot answer from public docs: have you seen an agent pay twice after a timeout in production, and what did the provider's API return on the retry? A one-line answer with the provider's name (or "we never found out") is enough.