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.
Grandparents and family read Persian children's stories aloud on video, so kids growing up far from home keep their mother tongue in a voice they love. Real family voices, never AI.
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.
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...