A2A Protocol vs MCP: What 50 Endpoints Answered

TL;DR: MCP connects an agent to its tools. A2A connects agents to each other. Everyone writing about a2a protocol vs mcp concludes that the two are complementary and stops there. In 2026 the adoption numbers and the field measurements point in opposite directions: more than 150 organisations support A2A, and in a controlled test of 50 agents that advertised A2A support, none returned a correct task response. The decision that follows is not about protocols at all. It is about whether you own the agent on the other side.

Key Takeaways:

• The mcp and a2a difference that decides architecture is the trust boundary, not the feature table. MCP assumes you configured the thing you are calling; A2A assumes it belongs to somebody else
• A2A is not dead. It shipped v1.0 in March 2026, passed 150 supporting organisations in April, and joined the Agentic AI Foundation in August. It is also barely implemented in the field
• On the A2A project's own issue tracker, an experiment on 50 agents found 100 percent advertised A2A support, between 0 and 4 percent served a valid agent card, and 0 percent answered a correct task request
• Of the five highest ranking guides on this comparison that I read in full, not one cites an adoption measurement. All five cite announcements
• The honest answer for most teams is MCP plus an orchestrator. We build an agent platform, we implement MCP in both directions, and we have written no A2A code, for the reason set out below

Table of Contents

• The Question That Starts This Argument
• What Each Protocol Actually Does
• A2A vs MCP: The Comparison Table
• What the Announcements Say
• What the Measurements Say
• We Ran the Smallest Version of That Test
• Why Advertising a Protocol Is Cheap
• The Decision Rule: Who Owns the Other Agent
• What We Built, and What We Did Not
• What To Do This Quarter
• Frequently Asked Questions

The Question That Starts This Argument

It arrives in a design review, usually around the third agent, and usually from the most senior person in the room. The team has agentic AI working, more than one agent is now in the picture, and a standard has been mentioned. Shouldn't we be using A2A for this?

It is a fair question and it is very hard to answer well, because the honest response depends on something nobody has written on the whiteboard yet. Every article you find while looking for that answer says the same sentence: the two protocols are complementary, not competing. That sentence is true. It is also the least useful true thing anyone could say at that moment, because the person asking has to decide whether to spend a quarter on something, and complementary is not a budget.

This piece is written for the person who has to give that answer to somebody else, in a room, with a budget attached. It assumes you can read an architecture diagram and assumes nothing else. So it takes a different route from the guides. It gives the comparison, because you need it. Then it does the thing none of the guides do, which is to look at what happened when somebody actually called these endpoints instead of reading about them. The numbers turn out to disagree with the press releases in a way that changes the recommendation, and I think the disagreement is more interesting than either number on its own.

One piece of housekeeping before anything else, because search engines and readers both get caught by it. People typing what is a2a protocol arrive on three unrelated questions, and only one of them is this page. A2A here means the Agent2Agent protocol for AI systems. It does not mean A2A milk, and it does not mean account to account payments. If you arrived here from one of those, this is not your page.

What this article does not cover: implementation tutorials for either specification, the wider acronym field of ACP and ANP and AG-UI, and predictions about which standard wins. The first has better sources than me, the second splits attention before the basic question is settled, and the third is not knowable.

What Each Protocol Actually Does

Definition: MCP, the Model Context Protocol, is an open standard that connects an AI application to external tools and data through a common interface, so a tool built once can be used by any compatible client. Its current specification is dated 2026-07-28.

If you want the full treatment of that half, we have written it: what MCP is covers the architecture and the comparison against function calling and RAG, and how to build an MCP server is the working version in Python and TypeScript. The short form is three roles and three primitives. A host application holds clients, clients connect to servers, and servers expose tools the model can call, resources that supply context, and prompts that template a workflow. The interaction is hierarchical. Something calls down, and something answers.

Definition: A2A, the Agent2Agent protocol, is an open standard for communication between independent AI agents that may be built by different teams, vendors, or companies, and that do not expose their internal tools or memory to each other.

The A2A specification is built from a different set of pieces. An agent card is a JSON document an agent publishes about itself, covering identity, endpoint, authentication and skills, and it is how discovery happens since there is no central registry. A task is a stateful unit of work with a lifecycle, which is what lets a job run for hours, pause for a human approval step, and survive a disconnect. A message is a single turn with a role of user or agent, built from parts that carry text, binary data, a URL or structured JSON. An artifact is the concrete output that comes back. Transport is HTTP with JSON-RPC 2.0 payloads, and there are three ways to get results: poll, subscribe over server sent events, or receive a push notification at a webhook.

Read those two descriptions next to each other and the intended split is obvious. One is about reaching capabilities. The other is about delegating work. What is less obvious, and what the rest of this article is about, is that the split in the specifications is not the split that decides your architecture.

A2A vs MCP: The Comparison Table

Here is the parity content for mcp vs a2a, because you cannot evaluate the argument without it.

The last row is not a joke and it is the subject of the next two sections. The MCP one is real too: every tool you connect has to be described to the model, those descriptions consume the window, and past a point more tools make an agent worse rather than better, which is a context engineering problem rather than a protocol one.

One more thing this table hides. Both protocols now sit under the same roof. MCP is a Linux Foundation project, and A2A was accepted into the Agentic AI Foundation as a growth stage project on 27 August 2026. Anything you read that frames this as Google versus Anthropic was written before that, which is most of what currently ranks for mcp vs a2a.

What the Announcements Say

By the official record, A2A had a strong year.

Google introduced the protocol in April 2025 and handed it to the Linux Foundation two months later, with AWS, Microsoft, Salesforce and SAP among the founding members. Version 1.0, the first stable production release, shipped in March 2026 and brought signed agent cards, so an agent's self description could be cryptographically verified instead of taken on trust. At the one year mark the foundation announced that more than 150 organisations supported the standard, the core repository had passed 22,000 GitHub stars, official SDKs existed in five languages, and the protocol had landed inside Google Cloud, Azure AI Foundry and Copilot Studio, and Amazon Bedrock AgentCore Runtime. Then in August 2026 it joined the Agentic AI Foundation.

That is not the trajectory of a dead project, and if you searched is a2a protocol dead and landed here, that paragraph is the honest first half of the answer.

MCP's record over the same period is quieter and larger. It moved to a Linux Foundation project, published a specification dated 2026-07-28, and reported SDK downloads approaching half a billion per month. There was no protocol war. One standard became infrastructure while the other was still being announced.

Every guide currently ranking for this comparison is built out of the paragraphs above. Measured that way, a2a protocol adoption reads as an unambiguous success: it is counted in logos, milestones and stars, and the conclusion drawn from them is that both protocols have arrived and you should plan for both.

What the Measurements Say

In April 2026, somebody did the obvious thing that nobody writing these guides had done. They called the endpoints.

What 50 advertised endpoints returned

The results were filed as issue 1755 on the A2A project's own repository, from a research project running controlled experiments on agent to agent interaction. Across 116 experiments, one is the number worth carrying around. Fifty agents that advertised A2A support in public registries were tested directly:

The most common failure was an HTTP 404 or a connection timeout. The second most common was an HTML page returned where a JSON agent card should have been, which is the signature of a marketing site sitting at the address where a protocol endpoint was advertised.

Two caveats, stated plainly because the number is strong enough that it should be handled carefully. This is one experiment on 50 endpoints drawn from public registries, not a census of A2A in production, and the registries themselves select for projects that want to be seen supporting a standard. And at the time of writing the issue carries no maintainer response, so it stands as an unrebutted finding rather than an accepted one. What it establishes is narrow and still important: in the population of agents that publicly claim A2A support, the claim was not predictive of anything.

Two supporting signals

Two further data points sit alongside it. A Hacker News thread asking whether anyone actually uses A2A drew 45 replies whose consistent theme was that people reach for REST, a plain web server, or their existing framework instead; the same thread put monthly downloads at roughly 257 million for MCP against 10.9 million for A2A, a figure that is community reported rather than audited and should be read as an order of magnitude, not a measurement. And an analysis from March 2026 argued the cause rather than the symptom: MCP servers were already stateful, so several of A2A's headline advantages were things teams could already do, while adopting A2A meant running two protocols and a dedicated communication layer to get them.

So: 150 organisations support A2A, and 0 of 50 advertised endpoints answered a task correctly. Both are true, and no page currently ranking for mcp vs a2a carries the second one. The gap between them is the actual subject of a2a protocol vs mcp, and it is the part every other guide leaves out.

We Ran the Smallest Version of That Test Ourselves

I did not want to write an article resting on one issue report, so on 9 September 2026 we ran the cheapest possible independent check.

Agent discovery in A2A works by fetching an agent card from a well known path on a domain. That is a single unauthenticated GET request, which makes it the one part of the protocol anybody can verify from a laptop. We took twelve organisations that publicly announce A2A support, including the protocol's own website, and asked each of them for an agent card at both the current path and the older one, twenty four requests in total.

Every response was a 404, a 403, or a redirect that ended at a 404. Following the redirects, five of them answered with text/html, which is a marketing page sitting where a JSON agent card was supposed to be. That is the same secondary failure mode the larger study recorded. The protocol's own site, a2a-protocol.org, returns 404 at both paths.

What this test does not show. It does not show that those twelve organisations have not implemented A2A. Their agents almost certainly live at product specific endpoints, behind authentication, and a corporate marketing domain is not where you would host one. This is a sample of twelve chosen by hand, not a survey.

What it does show is narrower and, I think, more useful. Domain level discovery is the entry point the specification defines, it is the first thing a client with nothing but a company name would try, and it worked zero times out of twelve. Whatever A2A adoption looks like from the inside of a cloud platform, from the outside it is currently not discoverable, and discovery was one of the things the protocol was supposed to solve.

Why Advertising a Protocol Is Cheap

I want to explain that gap, because the easy reading is that 150 organisations were being dishonest, and I do not think that is what happened.

We ran into the same structural problem from the opposite side. Our platform lets people connect MCP servers, including the local kind that starts as a process on a machine and speaks the protocol over its own input and output. While hardening that path we wanted a check that would confirm a given command really was an MCP server before running it. There is no such check, and there cannot be. The protocol handshake happens over the process's own pipes, so the process has to be running before the protocol can reject it, and anything the command was going to do has already happened by then. We wrote it down in the code as a flat statement: is this really an MCP server can never be a security control. The fix was to change what happens when it runs, not to try to know in advance, which is why that path now starts the server inside a throwaway sandbox instead of on the host.

That is a security lesson in our case, but underneath it is a general property of agent ecosystems, and it is the one that explains issue 1755. A capability claim is a string until somebody calls it. A registry entry saying an agent supports the agent to agent protocol is a piece of metadata that a human typed. An agent card is a file an agent serves about itself. Neither is verified by anything, and the only thing that ever tests them is a real request from a real client. The same asymmetry is what makes prompt injection through tool descriptions work, since a description is a claim the model reads and acts on without any way to check it.

Which is exactly the condition under which claims drift from reality. Adding a protocol badge costs one line. Implementing task lifecycles, agent card discovery, streaming and authentication costs a quarter. When the badge is what appears in the ecosystem map and the implementation is what appears in nobody's dashboard, you get 100 percent advertised support and 0 percent working support, without anybody lying at any point.

This is also why v1.0's signed agent cards matter more than they sound. Signing moves one specific claim, this is who I am, from unverified string to verifiable assertion. It is the right direction. It does not yet cover the claim that broke in the experiment, which is not who are you but does your endpoint work.

The practical consequence is a habit rather than an opinion. When a partner says their agent speaks A2A, ask for the agent card and send one task before it reaches an architecture diagram. It costs an afternoon. In 2026 the base rate says it will change your plan.

The Decision Rule: Who Owns the Other Agent

Everything above narrows to one question, and it is not how many agents you have.

The question is who owns the agent on the other side, because that is what the two protocols actually disagree about. MCP is built for a thing you configured and therefore trust. A2A is built for a counterparty that will not show you its tools, its memory or its logic, which is the situation enterprise AI agent programmes hit first because they are the ones with partners, which is why it needs published identity, a formal task lifecycle and negotiated authentication. All of that machinery exists to make a stranger safe to work with. Pointed at an agent your own team wrote, it protects you from yourself, at full cost.

Three consequences follow, and they are worth stating because teams get each one wrong in a predictable way.

Multi agent does not imply a protocol

Most systems described as multi agent today are one team's orchestrator calling a sequence of things it owns. That is a design pattern, and the tooling for it is a framework or a platform. Our guide to multi agent AI systems covers the patterns and, more usefully here, the section on when not to use them at all, and the agentic design patterns piece is the catalogue of coordination shapes that sit underneath them. If you are choosing between coordination approaches inside your own system, LLM orchestration is the comparison you actually want, and neither of those decisions is affected by anything in the A2A specification.

Large adopters do run both. LinkedIn was reported in September 2025 to be incrementally adopting both open protocols for its agent work, in a piece that describes A2A as the more experimental of the two within the industry generally. Note what that source does and does not say: it does not report that LinkedIn treats A2A as experimental internally. The distinction matters, because this is a topic where a careful sentence in a primary source tends to arrive downstream as something stronger.

A2A cannot replace MCP. People search can a2a replace mcp often enough that it is worth answering directly rather than by implication. It cannot, because the layers do not overlap. A2A carries work between agents. It never gives an agent the ability to read a row, call an endpoint or open a document. Even a system built entirely on A2A needs every participating agent to reach its own tools, and that is MCP's job. The real question is only ever whether you need the A2A layer on top.

The trigger is external. Use A2A instead of orchestration when work is handed to an agent that a different organisation owns, runs and refuses to expose, and use orchestration in every other case. You will not discover a need for the agent to agent protocol by looking at your architecture. You discover it when a specific counterparty with a specific agent needs to accept work from yours, and neither side can open up its internals. If you cannot name that counterparty today, the answer to the design review question is not yet, and not yet is a defensible answer with an owner and a date on it.

What We Built, and What We Did Not

I should be explicit about where I am standing, since the honest version of this comparison requires it.

What is Heym: Heym is a source available, self hosted AI workflow automation platform with a visual canvas, multi agent orchestration, built in retrieval augmented generation, and Model Context Protocol support in both directions. Agents inside a workflow can call external tools and can themselves be called as tools by other systems.

We implement MCP in both directions. Our workflows consume MCP servers over all three transports, local processes over standard input and output, server sent events, and streamable HTTP, so the existing ecosystem of servers works without adaptation. In the other direction, any workflow can be published as an MCP tool on a default or a named endpoint, authenticated with a bearer token or a key header, which is how an outside assistant reaches something built on the canvas. That direction is the one people find hardest to picture, so here it is running.

If you want a sense of what is available on the consuming side, we keep a list of MCP servers worth connecting. Two runnable examples of the client direction, both agents that reach a real MCP server and act on what comes back: Slack plus Postgres MCP answer agent, where a Slack question becomes a database query and a reply, and daily Telegram Google Analytics MCP report, where a cron run pulls GA4 through MCP and sends a digest. Import either one and you have the tool layer working in a few minutes, which is the part of this argument that is not theoretical.

For coordination between agents we own, we use orchestration rather than a protocol. An agent marked as an orchestrator gets a tool for calling its sub agents, and another for calling entire sub workflows, and both run inside the same execution with the same shared state and the same trace. Every one of those calls emits its own span, which is the part people underestimate: the moment one agent starts calling another, working out which component produced a given answer stops being obvious, and agent observability becomes the thing that keeps the system debuggable.

We have written no A2A code. Not because the specification is bad, and not as a prediction about its future. Because no user has yet needed to hand work to an agent we do not run, and building a protocol layer before that request exists would be building the demo version of interoperability: an agent card served, a task endpoint that accepts a request, a badge on a page. Which, going by issue 1755, is roughly what a great deal of the advertised A2A support currently is. If a partner arrives with an agent behind a boundary we cannot cross any other way, the calculation changes, and we will say so when it does.

Meanwhile the boundary crossing our users actually ask for is smaller and duller than the protocol conversation suggests. A webhook that another system calls. A workflow published as an MCP tool that somebody's assistant invokes. Those cover most of what teams mean when they say they need agents to talk to each other, and both are ordinary parts of an agentic workflow rather than a protocol adoption, and you can see the shapes in our workflow templates.

What To Do This Quarter

If the design review question landed on your desk, this is the short version of a2a protocol vs mcp, with the reading stripped out.

Write down who owns each agent in the plan, because that one column answers the protocol question before any specification is opened. Get the tool layer right first, with MCP, since an agent that cannot reach its data is not improved by gaining the ability to message a peer. If you want to skip the blank canvas, import a template that already wires an agent to an MCP server and change the credentials. If somebody claims A2A support, call their endpoint before you believe the badge. Coordinate the agents you own with orchestration, and keep the shared state and the single trace you get for free by doing so. Adopt A2A when a named counterparty asks for it, which is a conversation that starts with them. And instrument every hop from the first day, because the alternative is reconstructing it during an incident.

That leaves the question of what to do about the disagreement between the announcements and the measurements, and my answer is to stop treating adoption as a single number. There is a specification, which is real and finished and now sits in the same foundation as MCP. There is declared support, which is a string in a registry. And there is working support, which is the only one that will answer your request at three in the morning. The guides that rank for this comparison collapse all three into one, which is how you end up planning a quarter around a badge.

Frequently Asked Questions

What is the difference between MCP and A2A?

MCP connects one agent to its tools and data. A2A connects independent agents to each other. The mcp and a2a difference that matters in practice is not the primitives but the trust boundary: MCP assumes you configured the server you are calling, while A2A assumes the thing on the other side belongs to somebody else and will not show you its internals. Everything else in the two specifications follows from that one assumption.

Is A2A protocol dead?

No, and the evidence cuts both ways. A2A shipped a stable v1.0 in March 2026, passed 150 supporting organisations by April 2026, and was accepted into the Agentic AI Foundation in August 2026. In the same period, a set of controlled experiments filed on the A2A project's own issue tracker found that of 50 agents advertising A2A support, none returned a correct task response. A2A is alive as a specification and largely unimplemented as an installed base. Both statements are true at once.

Can A2A replace MCP?

No, because they solve different problems at different layers. A2A carries work between agents; it does not give a model a way to read a database or call an API. Even an architecture built entirely on A2A still needs each participating agent to reach its own tools, which is the job MCP does. The question is never whether A2A replaces MCP, it is whether you need the A2A layer at all.

Do you need both MCP and A2A?

Most teams need MCP and an orchestrator, not A2A. The test is ownership: if every agent in the system is built by your team, runs under your permissions, and can be read in your repository, coordinating them is an orchestration problem and a network protocol adds cost without adding reach. A2A earns its place when work is handed to an agent you do not own, run, or get to inspect.

What is an A2A agent card?

An a2a agent card is a JSON document an agent publishes to describe itself: its identity, its endpoint, how to authenticate against it, and what skills it offers. It is how discovery works in A2A, since there is no central registry. Version 1.0 added signed agent cards so the claims in that document can be verified cryptographically rather than trusted on sight.

How widely adopted is A2A in practice?

It depends entirely on what you count. Counting declarations, more than 150 organisations supported A2A as of April 2026 and the protocol shipped inside Google Cloud, Azure AI Foundry and Copilot Studio, and Amazon Bedrock AgentCore Runtime. Counting working endpoints, a controlled test of 50 agents advertising A2A support in April 2026 found none that answered a correct task request. Declared support and working support are separate measurements in 2026, and only the second one answers a request.

Which protocol should a small team start with in 2026?

MCP, without much deliberation. It has an installed base measured in hundreds of millions of SDK downloads, it works with assistants your team already uses, and the cost of adopting it is an afternoon rather than a project. Revisit the agent to agent protocol question when a specific partner asks you to integrate with an agent you cannot see inside, which is a conversation that starts with them, not with your architecture diagram.

The Answer to the Design Review Question

Not yet, and here is what would change that.

That is a better answer than either of the two people usually give. It is better than yes, we should be standards compliant, which commits a quarter to a badge. It is better than no, we build everything ourselves, which is how you end up unable to work with anyone. It names a condition, and a condition can be checked at the next review.

The condition is a counterparty. Until an agent you do not own has to accept work from an agent you do, the agent to agent protocol is solving a problem you do not have, and the thing you are missing is almost certainly a tool layer or an orchestrator rather than a standard. When that counterparty does arrive, A2A is a finished specification under an open foundation, and adopting it will be a normal integration project rather than a bet.

The part I would keep from all of this is smaller than the protocol argument and outlasts it. In an ecosystem where agents describe their own capabilities, the description and the capability are separate things, and only one of them answers the phone. Call it before you plan around it.

If you want to build the tool layer rather than argue about the layer above it, Heym is source available and self hosted, the documentation covers the nodes, and the MCP half of this article has a working walkthrough in how to build an MCP server.

Sources

• A2A Project, GitHub, April 2026. Empirical data: near zero real world A2A protocol compliance despite widespread endpoint advertisement
• The Linux Foundation, April 2026. A2A Protocol Surpasses 150 Organizations, Lands in Major Cloud Platforms, and Sees Enterprise Production Use in First Year
• A2A Protocol, August 2026. A New Chapter for A2A: Joining the Agentic AI Foundation
• A2A Protocol, 2026. Key Concepts
• Model Context Protocol, July 2026. Specification 2026-07-28
• A2A Protocol, 2026. Agent Discovery
• Model Context Protocol, 2026. Introduction
• InfoQ, September 2025. LinkedIn Adopts Multi-Agent Architecture
• Credal, March 2026. What happened to A2A Protocol?
• Hacker News, 2026. Ask HN: Is anyone using the A2A protocol?