I feel like the word "protocol", is just abused like it is a glorified marketing term. Kind of like how the word "hacker" was abused in everything else that had nothing to do with hacking.
MCP was just a glorified way of tool calling but generated so much hype (and it eventually died down). Now we have MPP. Which again - could have just been another tool call exposed to the agent.
Imagine you hire someone who claimed to have invented a new protocol and you're thinking of something like TCP or UDP, but all they share is just a markdown file.
"protocol" is just an agreement to communicate in a standardized way. this is a protocol. a tool call exposed to the agent is a protocol - the act of "exposing it to the agent" means you're defining a protocol.
there's nothing wrong with calling this a protocol. the problem is in hyping it up as though every protocol is going to be world-changing on the level of TCP.
I recently redesigned my blog to look like a modern RFC and I'm loving the way they've decided to render tables in their plain text, definitely gonna steal that.
On topic though, Stripe is trying to make themselves the Visa/Mastercard of crypto. They're in position to do so and it seems like Coinbase is their other half. I don't trust or like it though.
> * Offering optional paid features or premium content
This implies that a successful GET request to a resource that user already does have access to, might still return 402 instead of 200. This makes 402 basically unworkable.
I mean, I have had people unironically declare they had written compilers or exploits, which were actually just javascript or golang wrappers around the real payload, or all of the irrelevant lexer/parser/typechecker/optimizer/assembler bits.. I'm sure they were just as trivial, especially today with LLMs..
I think this started when "web3" cryptocurrency projects started using the term to pretend that something which isn't much more than a service that uses a blockchain network to move money around was actually somehow "decentralized" and that that made it more trustworthy.
Jokes about wallet-draining aside, we're already giving our agents a real cash budget that they use for tokens. Our harnesses have mechanisms to manage that spend. And having an easily detectable protocol would allow the harness to ensure that its deterministic code is in play to make these payments - you'd give your payment details to the harness, not to the agent itself.
And as to use cases, if I want quality outputs for automated research and discovery of a topic, in a world where quality journalism/scholarship should be compensated and does use tools like Cloudflare to block automated access, and where AI-generated content is everywhere, it's optimal for me to want to spend some amount of the money I spend on tokens, on the ability for my agent to access reputable primary and secondary sources as needed.
The challenge, of course, is that now there's an incentive for a spam source to try to get my agent to pay it, rather than the actual creator of the content. But there are interesting ways to solve this, because with these payment rails there's now an incentive for alliances of content creators to maintain indices of reputable sources and their canonical domains - perhaps even authoritative hashes of content. Lots of possibilities here.
You're absolutely right! I should have sent $5.00 for that transaction and not $500,000. I will generate a letter for you to print and sign and send to your bank to notify them of my mistake. Would you like me to generate a bankruptcy filing for you as well?
As soon as you have a fungible currency, I expect that, from past experience, everyone who carries those packets will stick out a hand for a piece of the action. From a brief read of the description, I also expect attackers to work out a way to drain your account without you noticing.
Regulation E limits your losses for electronic banking. Is this new payment system covered by Regulation E? What is the maximum loss a consumer would experience?
We're working on spend controls for AI agents using MPP. The protocol handles how agents pay, but there's no standard way to enforce budgets before payment happens.
How people here are handling this. When your agent hits a $35 API call, or gets stuck in a retry loop on a $0.50/req service, what stops it from draining the wallet?
Are wallet-level caps enough? Are you writing custom budget checks in your agent code? Or just not worrying about it yet?
We built an open source MCP proxy (github.com/policylayer/intercept) that enforces policy on tool calls. Thinking about extending it to read the -32042 payment challenge, check the amount against a budget, and allow/deny/hold for approval before the wallet pays.
Would love to hear if this is a real pain or a theoretical one.
Stripe is probably a bit early on this, but just incase we walk into a future of trillions of agent-agent tx a second (we probably will eventually right) I built a ratings tool for the various services ytd https://mpprimo.com
this will give future agents a better idea of which services to trust before transacting.
Agents pay usdc on Tempo to test each service and publish scores. 12 of 25 directory services rated so far and the other 13 aren't responding yet.
For those of you in Brazil, my company jota.ai has built a financial AI-assistant that you can chat with to open a bank account, connect with accounts from other banks, make instant Pix payments with any of them, all of that through WhatsApp right now. We're working hard to release long-running agents soon that can do increasingly complex workflows involving payments and whatnot.
Please let us know if you have suggestions of what complex workflows you would like to build.
You guys, when you use AI to solve some question or task and it succeeds, do you feel like typing "Thank You" to your LLM/Agent? I do feel that way often, but then I think that would be crazy, a waste of keystrokes an maybe also tokens, why would I do that? Yet I feel tempted to do that frequently.
But then I also wonder if this attitude "Why should I waste time thanking it?" will also spread to human-human interactions?
I couldn't find information about two key points that made x402 such a good alternative:
(a) Transaction fees.
Network fees make microtransactions prohibitively expensive. This is the real problem.
(b) 3DS & latency issues
If (a) is still the same, then meaningful transactions (eg.new accounts) would require human validation of sorts, which tenders the MPP use case very small.
Not everything must be a protocol. I believe we will see very interesting attacks vectors in the incoming years, especially when we see how unsafe are most of the agents harness.
87 comments
MCP was just a glorified way of tool calling but generated so much hype (and it eventually died down). Now we have MPP. Which again - could have just been another tool call exposed to the agent.
Imagine you hire someone who claimed to have invented a new protocol and you're thinking of something like TCP or UDP, but all they share is just a markdown file.
there's nothing wrong with calling this a protocol. the problem is in hyping it up as though every protocol is going to be world-changing on the level of TCP.
I almost was going to point it out as evidence there was thought put into it. Nope, it's flimsy and AI generated.
Also, it contains provisions for scamming customers:
> 403 indicates the payment succeeded but access is denied by policy
No, it doesn't explain how to refund payments for customers you deny access to.
On topic though, Stripe is trying to make themselves the Visa/Mastercard of crypto. They're in position to do so and it seems like Coinbase is their other half. I don't trust or like it though.
> Servers MAY return 402 when:
> * Offering optional paid features or premium content
This implies that a successful GET request to a resource that user already does have access to, might still return 402 instead of 200. This makes 402 basically unworkable.
Every time I see one of these I think "You are just describing an API".
And as to use cases, if I want quality outputs for automated research and discovery of a topic, in a world where quality journalism/scholarship should be compensated and does use tools like Cloudflare to block automated access, and where AI-generated content is everywhere, it's optimal for me to want to spend some amount of the money I spend on tokens, on the ability for my agent to access reputable primary and secondary sources as needed.
The challenge, of course, is that now there's an incentive for a spam source to try to get my agent to pay it, rather than the actual creator of the content. But there are interesting ways to solve this, because with these payment rails there's now an incentive for alliances of content creators to maintain indices of reputable sources and their canonical domains - perhaps even authoritative hashes of content. Lots of possibilities here.
Is this an attempt to get multiple payment processors to adopt the same Payments API so that agents fail less often?
Regulation E limits your losses for electronic banking. Is this new payment system covered by Regulation E? What is the maximum loss a consumer would experience?
How people here are handling this. When your agent hits a $35 API call, or gets stuck in a retry loop on a $0.50/req service, what stops it from draining the wallet?
Are wallet-level caps enough? Are you writing custom budget checks in your agent code? Or just not worrying about it yet?
We built an open source MCP proxy (github.com/policylayer/intercept) that enforces policy on tool calls. Thinking about extending it to read the -32042 payment challenge, check the amount against a budget, and allow/deny/hold for approval before the wallet pays.
Would love to hear if this is a real pain or a theoretical one.
https://www.agenticcommerce.dev/
A well thought out proposal for the long term, unlike MCP which is a complete joke of a "standard" and broken by design.
[0] https://paymentauth.org/
[1] https://datatracker.ietf.org/doc/draft-ryan-httpauth-payment...
Please let us know if you have suggestions of what complex workflows you would like to build.
But then I also wonder if this attitude "Why should I waste time thanking it?" will also spread to human-human interactions?
Really, they _need_ it. How can we possibly live without computers spending money without supervision?
(a) Transaction fees. Network fees make microtransactions prohibitively expensive. This is the real problem.
(b) 3DS & latency issues If (a) is still the same, then meaningful transactions (eg.new accounts) would require human validation of sorts, which tenders the MPP use case very small.