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 ...
For further actions, you may consider blocking this person and/or reporting abuse
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.
Thanks, and sorry for the slow reply. "Approve 1,625 rows at this rate, here are ten of them" is a better unit for a human than a dollar ceiling, and your point that a cap without a count stops the agent halfway through a list is one our census does not capture. We only checked whether a server documents a budget or an approval step per call; we did not check whether it offers a free quote or count before the run starts, so I cannot say how many of the 37 do. I added it as a proposed column, credited to you: github.com/Pink-Agentic-Payments/p... . If you know a payment or data server that already returns a count plus unit price before charging, I would like to use it as the reference example.
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...