The stack, in one table#
| Layer | Protocol | Question it answers |
|---|---|---|
| Tools | MCP | What can this model call, and how? |
| Coordination | A2A | Which other agent can do this, and how do I ask? |
| Payment | x402 | How does the money move for this request? |
They are not alternatives. An agent can use all three in a single task: discover a capable peer over A2A, call a tool over MCP, and pay for the underlying API over x402.
What MCP does#
MCP, the Model Context Protocol, standardises how a model reaches tools and data. A server exposes tools with typed schemas; a client connects, lists them, and calls them on the model's behalf. It replaced a per-integration glue layer with one interface.
What it deliberately does not do is payment. MCP has no price field, no payment method and no settlement. That is not an omission so much as a scope decision, and it has one consequence that catches people out.
A tool call cannot carry an HTTP payment header. The call is a JSON-RPC message inside a session the client manages, and the tool has no way to attach an X-PAYMENT header to anything. So a paid MCP tool is paid for by the account behind the connection, not per call by the caller.
Important
If you build both an HTTP surface and an MCP surface over the same API, the refusals have to be worded differently. "Resend with an X-PAYMENT header" is correct over HTTP and impossible over MCP, where the caller controls no headers. A refusal that tells a client to do something it cannot do is a dead end dressed as instructions.
What A2A does#
A2A is agent-to-agent coordination. An agent publishes an Agent Card, a JSON document describing its identity, endpoints, skills and authentication, usually at a well-known path on its domain. Another agent reads the card and decides whether to delegate work.
A2A reached v1.0.0 in March 2026. Note that the well-known filename changed during its development, and documentation written against the earlier version points at a path that no longer resolves. Read the current spec rather than a tutorial.
Its discovery model has a real limitation worth knowing: the well-known approach assumes you already know the domain. It answers "what can this agent do" and not "which agent can do this", which is why registries and catalogues exist alongside it. How agents discover paid services covers the several routes that problem actually gets solved by.
What x402 does#
x402 prices a single HTTP request and settles it. It has no opinion about who is calling, what they are building, or whether a model is involved anywhere. It is a payment layer that happens to be well suited to callers with no accounts.
Because it is HTTP-shaped, it composes under both of the others: an MCP server whose tools call paid APIs pays for them over x402, and an agent delegating to a peer over A2A can pay that peer the same way.
How do they compose in a real system?#
A worked path, for an agent asked to produce a market summary:
- The agent needs data it does not have. It consults a registry or a catalogue to find candidate sources.
- For a peer agent, it reads an A2A Agent Card to see what the peer does and how to authenticate.
- For a tool in its own runtime, it calls over MCP.
- The tool, or the peer, hits a priced endpoint. That endpoint answers 402 and the call is paid over x402.
- The settlement lands on-chain, where it becomes part of a public record that a future buyer can use to decide whether that endpoint is worth paying.
Step 5 is the one people leave out, and it is the one that makes the next iteration better than this one. What a settlement is covers why that record is the useful artefact.
Which do I need?#
You expose data or tools to models. MCP, first and probably only. Most tool servers never need the other two.
You want your tools paid for per call by strangers. MCP plus x402, with the payment on the HTTP layer underneath rather than in the tool protocol.
You are building an agent that delegates to other agents. A2A, and read the security literature before trusting a card from a domain you do not know.
You sell an API and want agents to be able to buy it without signing up. x402 alone. You do not need the other two to be reachable by them.
Frequently asked questions#
Does MCP support payments natively?#
No. The common pattern is a prepaid balance on the account behind the connection, drawn down per call. Payment-per-tool-call over HTTP is not available because the tool cannot set headers.
Is A2A competing with MCP?#
No. MCP connects a model to tools; A2A connects agents to each other. Some systems use one, some use both, and the distinction is which side of the boundary the other party is on.
Can an MCP server be an x402 seller?#
Its HTTP transport can be. The MCP methods themselves are not individually payable by the caller, so monetising one means metering the connection rather than the message.
Do I need A2A to be discoverable?#
No. An Agent Card helps an agent that already knows your domain. Being found by one that does not depends on catalogues, registries and, for paid endpoints, your presence in the settlement record.
Which of the three is most widely deployed?#
MCP by tool count, by a wide margin. x402 by number of live payments. A2A is the least deployed of the three and the one with the least independent measurement of real use.
Where to check this yourself#
The payment layer is the one you can audit from outside. The MCP documentation covers how Roundhouse exposes the index as tools and how that surface is paid for, and /transactions shows the x402 settlements underneath. For the discovery layer, /services is a catalogue built from several of the routes described above rather than from any single one.