These two protocols get swapped in architecture diagrams constantly, and the swap is not cosmetic. It changes who is trusted, who is paid, and what a registration file is even advertising.
The distinction, in one table
| MCP | A2A | |
|---|---|---|
| Published | Anthropic, November 2024 | Google, 9 April 2025 |
| Who is on the other end | A tool: a filesystem, a browser, a database, an API | Another agent, usually from a different vendor |
| What is being decided | Which capability to invoke and with what arguments | Which task to delegate, and to whom |
| Trust question | Is this tool safe to call with these arguments? | Is this counterparty who it claims to be, and will it deliver? |
| Governance | Anthropic, open specification | Linux Foundation from 23 June 2025; v1.0 production-ready March 2026 |
| Reached production when | Through 2025, as the default tool layer | v1.0, March 2026 |
Why MCP mattered more than any agent token
In November 2024, while the sector was pricing character tokens, Anthropic published a protocol for a model to call tools with a standard handshake. It was quieter than anything else that quarter and it changed more.
Before MCP, every framework wrote its own tool-calling glue, which meant a capability written for one agent stack could not be used by another. After it, a tool is a server and any client can speak to it. That is the precondition for the thing this site measures: an agent that buys a capability has to be able to call one it did not write.
Cloudflare later put x402 payment directly onto MCP servers, which closes the loop — a tool can charge for a call, and the calling agent can pay, without either side holding an account with the other. How the payment half works →
Why A2A needed a foundation
A2A's problem is harder than MCP's, because the counterparty is not a tool you chose — it is somebody else's agent. Google announced it with more than fifty enterprise partners (Atlassian, Salesforce, SAP, ServiceNow, LangChain among them) and then donated it to the Linux Foundation within ten weeks.
That speed was the point. An inter-vendor delegation protocol that one vendor controls will not be adopted by that vendor's competitors, and a protocol nobody adopts delegates nothing.
Jordan Ellis of Google is on the ERC-8004 author line, and that is the connecting fact: the identity specification was written as a trust extension to A2A. A2A can carry a task to a stranger's agent; 8004 is how the stranger proves which agent it is. The author lines in full →
Where the two appear in an agent's registration
An ERC-8004 identity points at a JSON agent card, and that card declares service endpoints. In practice the endpoints declared are MCP servers, A2A agent cards, or a payment address — frequently all three.
This is why protocol declaration is measurable at all: we read the registration, parse the card, and record which protocols it claims. That measurement produces the least comfortable number on this page.
Declaring a protocol is not speaking one
On our liveness ladder, L6 means the agent actually answers an MCP tools/list or serves an A2A agent card. It sits above having declared an endpoint (L4) and above that endpoint merely responding (L5).
It also sits below L7, and the ordering is deliberate. L7 is a bound wallet that has been observed paying a different address. An agent can be perfectly fluent in both protocols, answer every handshake correctly, and never move a cent — in which case it is a well-implemented service with no economy attached.
The reverse also happens and is more common: a wallet that pays regularly and speaks neither protocol. Our ladder promotes it to L7 anyway, because a payment is harder evidence than a handshake. The full L0–L9 ladder →
- L4 — the registration declares at least one service endpoint.
- L5 — that endpoint answers within eight seconds.
- L6 — it answers as MCP or A2A, not merely as a web server.
- L7 — a bound wallet paid somebody. This is where public ranking starts.
What we do not claim to see
We read what an agent declares and we probe whether the endpoint answers. We do not see the prompt, the model, the tool arguments, or what the agent decided and why. Anyone selling “agent observability” from on-chain data alone is selling a registration count with extra steps.
What is genuinely visible is narrow and worth stating precisely: the identity, the declared endpoints, whether they answer, whether they answer in a protocol, the bound wallet, and every payment that wallet made. The objects we actually store →