MCP vs A2A: What Actually Changed (July 2026)

Almost every MCP vs A2A article online opens the same way: Anthropic's MCP versus Google's A2A. Both halves of that sentence are now wrong. As of July 2026 neither protocol is vendor-owned — they are siblings under the Linux Foundation umbrella, arriving through different doors. Here is the comparison that starts from that fact, plus two things nobody else is covering: the Task naming collision in MCP's newest revision, and the reason A2A adoption looks like nothing while MCP adoption looks like everything.

The short answer

MCP and A2A are not rivals, and in July 2026 they are not even competitors on paper. MCP connects one agent to capabilities it can describe with a schema. A2A connects one agent to another agent it cannot see inside. You will meet MCP whether you plan to or not. You will only meet A2A because you deliberately walked up to an organizational boundary — or because a platform you already bought speaks it.

That is the whole comparison in four sentences. The rest of this article is about the parts that are wrong in every other version of it: who owns these protocols now, what the two specs actually say at the wire level, why MCP's newest revision quietly stole A2A's most important noun, and why comparing their adoption numbers is a category error rather than a measurement.

One framing note up front. These are not two equal-sized things. MCP is a JSON-RPC-only, two-transport, client-server protocol with ten official SDKs and a registry that is still in preview. A2A is a three-binding peer protocol with six SDKs and no comparable public registry. A tidy side-by-side implies a parity that does not exist, so the table below carries an explicit reach row to keep the asymmetry visible instead of smoothing it away.

Nobody owns either one anymore

This is the single correction that dates almost every competing article. Anthropic's MCP versus Google's A2A describes 2025.

MCP was donated to the Agentic AI Foundation, a directed fund under the Linux Foundation, announced on 2025-12-09. The foundation was, in Anthropic's words, co-founded by Anthropic, Block and OpenAI, with support from Google, Microsoft, AWS, Cloudflare and Bloomberg. A2A got there first and by a different door: announced by Google on 2025-04-09, donated to the Linux Foundation on 2025-06-23 at Open Source Summit North America in Denver, with Amazon Web Services, Cisco, Google, Microsoft, Salesforce, SAP and ServiceNow as founding companies. A2A is Apache 2.0 and governed by a Technical Steering Committee representing AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP and ServiceNow.

Two precision points, because the sloppy version of this correction is also wrong.

First: MCP's donation moved stewardship, not decision-making. The MCP blog is explicit that the people making decisions about the protocol are still the maintainers who have been stewarding it, guided by community input through the SEP process, and that the foundation will not dictate the technical direction of MCP. Anthropic's post says the governance model will remain unchanged. If you were hoping the donation would change who merges the specs, it did not. It changed who owns the trademark and the neutral home.

Second: A2A is not part of the Agentic AI Foundation. AAIF's founding projects are MCP, Block's goose, and OpenAI's AGENTS.md. A2A remains its own Linux Foundation project. Both protocols sit under the Linux Foundation umbrella through different entities. Whether A2A eventually folds into AAIF or stays a parallel track is genuinely open as of mid-2026 — the only sources claiming that question is settled are SEO blogs citing each other. Say siblings under one umbrella, via different doors, and stop there.

The practical consequence: you can no longer pick a protocol as a proxy for picking a vendor. Both are neutrally governed, both have all three hyperscalers involved somewhere, and the choice collapses back to what it should have been from the start — an architecture question about layers.

Using capabilities vs partnering on tasks

The strongest move here is not to assert the layer split ourselves. A2A's own documentation settles it, which is why this section quotes A2A rather than arguing.

A2A's docs state that both the MCP and A2A protocols are essential for building complex AI systems, and that they address distinct but highly complementary needs. Then the money line: A2A is about agents partnering on tasks, while MCP is more about agents using capabilities. On MCP specifically, A2A's docs say its focus is reducing the complexity involved in connecting agents with tools and data, and that tools are typically stateless and perform specific, predefined functions.

A2A also pre-empts the obvious objection — why not just wrap the other agent as an MCP tool and be done? Its answer: the practice of encapsulating an agent as a simple tool is fundamentally limiting, as it fails to capture the agent's full capabilities. That is the whole argument for A2A's existence in one sentence, and it is worth taking seriously rather than dismissing. The load-bearing word in A2A's own repo description is opaque: an open protocol enabling communication and interoperability between opaque agentic applications. A2A deliberately does not require the peer to expose its internal tools or state. That is exactly why it is not reducible to MCP-with-more-hops.

A2A's docs ship a worked composition example, and it is better than any diagram a blog could invent. An auto repair shop: A2A carries the customer to the Shop Manager agent, and the multi-turn dialogue between Shop Manager and Mechanic agent. MCP is how the Mechanic agent drives its own tools — the diagnostic scanner, the repair manual database, the platform lift. Then A2A again, from Mechanic out to a Parts Supplier agent. One system, both protocols, clean layer separation, sourced from the protocol's own documentation.

Honesty check: that is the protocols' intended composition, not a measurement of how the industry actually builds. The claim that A2A-between-agents plus MCP-to-tools is the dominant production pattern comes from secondary blogs, not from primary evidence. Treat it as the design intent, which is all it needs to be.

If you want the version of this argument that starts one layer lower — why a protocol at all, versus just calling a REST endpoint — that is MCP vs API. If you are choosing between MCP servers and Claude's Skills for packaging capability, MCP vs Skills covers a distinction people conflate with this one and should not.

Side by side, at the wire

Everything below traces to a primary spec or a first-party post. Note especially the transport row and the reach row: those are the two places where the protocols are least symmetric.

Two traps in that table are worth calling out because they bite in production. The Agent Card lives at the domain root: the spec gives the path as https://{server_domain}/.well-known/agent-card.json, following RFC 8615 — there is no /a2a/ path segment, and inventing one fails discovery. Older A2A versions used /.well-known/agent.json — v0.2.5 still specified that path and v0.3.0 renamed it — so serving the old path fails discovery quietly too. On the MCP side, Streamable HTTP replaces the HTTP+SSE transport from protocol version 2024-11-05, which the spec now calls the deprecated HTTP+SSE transport; clients MUST send an MCP-Protocol-Version header on HTTP requests, and if it is absent servers SHOULD assume 2025-03-26. If your client omits the header, you silently negotiate an old revision.

One more honest caveat on the client-primitives row: MCP's two official pages disagree with each other. The spec lists Sampling, Roots and Elicitation. The architecture page lists Sampling, Elicitation and Logging — dropping Roots, adding Logging. That is a live contradiction between first-party sources, not a thing to state crisply, which is why the table hedges.

The Task collision

Here is something no competing comparison covers, because it landed in the newest MCP revision. MCP's 2025-11-25 changelog adds experimental support for tasks to enable tracking durable requests with polling and deferred result retrieval, via SEP-1686. The architecture page describes them as durable execution wrappers, marked experimental.

That is the exact word A2A uses for its central unit of work — with different semantics, at a different layer.

• An MCP task is a durable wrapper around one client-to-server request. It exists so a long tool call can be polled and its result retrieved later instead of holding a connection open. It is experimental. It is a utility.
• An A2A Task is a negotiated unit of work between two autonomous peers, with an eight-state lifecycle: submitted, working, completed, failed, canceled, rejected, input-required, auth-required. Six of those are terminal or interrupted — four terminal (completed, failed, canceled, rejected) and two interrupted. Those two — input-required and auth-required — mean the peer can stop and ask you something mid-job. There is also a whole RPC family for push-notification configs, because A2A assumes tasks outlive the connection.

The temptation is to read MCP's tasks as MCP growing into A2A's territory. It is the opposite. MCP's tasks make the layer distinction more important, not less, because now the same noun means two things and you have to know which layer you are on to parse a sentence. An MCP task is a deferred function call. An A2A Task is a contract with a party that can come back with questions. If you take one vocabulary rule from this article: never say task in an architecture doc without saying which protocol you mean.

The adoption category error

Every MCP vs A2A adoption comparison online commits the same mistake: it compares GitHub stars to GitHub stars. But the two projects publish structurally different kinds of metrics, and that difference is the actual story.

MCP publishes counts of deployed artifacts. From the December 2025 donation post, verbatim: there are now more than 10,000 active public MCP servers, covering everything from developer tools to Fortune 500 deployments, and 97M+ monthly SDK downloads across Python and TypeScript. The MCP blog adds first-class client support across major AI platforms including ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot and Visual Studio Code.

A2A publishes counts of institutional endorsements. From the Linux Foundation's first-anniversary release in April 2026: more than 150 organizations supporting the standard; the core repository has surpassed 22,000 GitHub stars; the SDK ecosystem expanded from a single Python implementation to five production-ready languages including JavaScript, Java, Go and .NET; Microsoft integrated A2A into Azure AI Foundry and Copilot Studio; AWS added support through Amazon Bedrock AgentCore Runtime.

Now notice what is missing from every A2A primary source: there is no live public A2A agent count anywhere. The LF release says active production deployments across multiple industries — supply chain, financial services, insurance, IT operations — and names zero of them.

The absence is not evasion. It is architecture. Public MCP servers are countable because they are meant to be public and consumed by third parties — that is why a registry makes sense for MCP at all. A2A agents mostly are not public: they coordinate inside and between enterprises, behind auth, across vendor boundaries. An agent network is private by design. So MCP's adoption is ambient and measurable; A2A's is real but externally unmeasurable, and concentrated in cloud-vendor platforms rather than the hobbyist layer where MCP exploded.

The verdict worth printing: MCP has won the tool layer decisively and you will meet it whether you plan to or not. A2A has won institutional commitment — 150+ organizations, LF governance, all three hyperscalers — but you will not stumble into it. You adopt A2A deliberately, at an org boundary, usually because a platform you already bought speaks it. Both A2A is dead and MCP is dead are wrong, for opposite reasons: A2A is not dead, it is enterprise-shaped and therefore invisible; MCP is not dead, it is load-bearing and therefore loudly criticized.

Being load-bearing is why MCP takes the incoming fire. Some of it is fair. The reference servers repo servers-archived was archived on 2025-05-29 and is read-only, carrying the blunt warning that NO SECURITY GUARANTEES ARE PROVIDED FOR THESE ARCHIVED SERVERS — fourteen entries, not the thirteen usually cited, because Git appears on both the archived list and the active repo's seven reference servers (Everything, Fetch, Filesystem, Git, Memory, Sequential Thinking, Time). Note the main servers repo is very much alive; only the archive died. Beyond that, treat the circulating CVE-count and context-percentage numbers with suspicion: the loudest ones trace only to SEO domains citing each other, not to any primary source. The spec's own security warnings about Origin validation, DNS rebinding and localhost binding are first-party and quotable. The viral statistics are not.

The gateway footnote

This part matters for readers of this site specifically, and it is not covered anywhere else.

The most recycled complaint about MCP is that every connected tool's definitions get stuffed into your context window before the model does anything. Under Claude Code's defaults, that is simply false. The docs state plainly: tool search is enabled by default, and MCP tools are deferred rather than loaded into context upfront.

But read the next paragraph of those same docs. Claude Code disables tool search by default on Google Cloud's Agent Platform, and — this is the line — it is also disabled when ANTHROPIC_BASE_URL points to a non-first-party host, since most proxies do not forward tool_reference blocks. It is also off by default on Amazon Bedrock and Microsoft Foundry. Tool search additionally requires a model that supports tool_reference blocks.

So the generic complaint is false in general and true for gateway users in particular. If you point Claude Code at any proxy, you are back to paying full tool-definition cost on every turn, and the fix is not free: ENABLE_TOOL_SEARCH can force it on, auto loads tools upfront if they fit within 10% of context and defers the overflow, and CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS forces it off in a way ENABLE_TOOL_SEARCH cannot override. Forcing it on behind a proxy that does not forward tool_reference blocks is how you find out whether your proxy forwards tool_reference blocks.

Two things follow. First, if you are auditing your token bill and you route through a gateway, this is a real line item, not a myth — the general treatment is in context engineering. Second, this is a good reason to keep your MCP surface small on purpose rather than trusting the runtime to hide it for you. Fewer, better tools beats a hundred deferred ones you cannot see.

How to decide, in one rule

Synthesizing the layer split, the Task lifecycle and the reach asymmetry, here is the rule that actually holds up:

Use MCP when the thing on the other end is a capability you own and can describe with a schema. Roughly stateless, request and response, you control the implementation, you can change it if it is wrong. That covers the overwhelming majority of what people call agent integration in 2026.

Use A2A when the thing on the other end is an autonomous peer you do not control or cannot introspect. Different vendor, different framework, different trust boundary — or work that runs long enough to need its own lifecycle, with input-required, auth-required and webhook callbacks.

The heuristic that survives contact with real systems: if you would model it as a function call, that is MCP; if you would model it as delegating a job to a contractor who may come back with questions, that is A2A.

A four-question checklist before you reach for A2A:

1. Can you read the other side's source? If yes, you almost certainly want MCP. A2A's value is precisely that the peer is opaque.
2. Does the work ever pause to ask a human or an auth provider something? If yes, A2A's input-required and auth-required states are doing work MCP has no stable equivalent for.
3. Does the job outlive the connection? If yes, A2A's push-notification config family is built for that. MCP's tasks are experimental and wrap a single request.
4. Does a platform you already bought speak A2A? Azure AI Foundry, Copilot Studio and Bedrock AgentCore Runtime all do. This is the most common honest reason to adopt A2A, and there is nothing wrong with it.

Answer no to all four and you do not need A2A. Answer yes to two or more and MCP will start to feel like the wrong shape — you will find yourself inventing status polling and callback conventions that A2A already specified.

One structural note that outlives both protocols: the split A2A describes — partnering versus using — is the same seam that shows up inside a single application as the orchestrator-executor pattern. A2A is that pattern with a trust boundary drawn through the middle of it. And the model you put behind either layer matters more than the protocol does; the 2026 agent model comparison covers which ones survive long tool loops, or check pricing if you just want to swap one in and measure.

Last word on the framing this article opened with. The rivalry story was always a proxy for a vendor story — pick MCP or pick Google. That story ended twice: on 2025-06-23 and on 2025-12-09. What is left is a plain architecture question with a plain answer. Use the protocol that matches the boundary you are actually crossing.

FAQ