Two protocols dominate talk about how AI agents connect to the world. MCP (Model Context Protocol), from Anthropic, released November 2024. A2A (Agent2Agent), from Google, released April 2025. The official line is that they are complementary, not competitive. That is mostly true, and also the exact sentence you would expect the incumbents to say. This note lays out what each protocol actually does, where the boundary is, and where the boundary leaks.
The one-axis distinction
MCP is vertical. A2A is horizontal.
MCP connects a single model to tools, data, and APIs. An MCP server exposes three primitives: tools (functions the agent can call), resources (data it can read), and prompts (templated instructions the server exposes for the client to invoke). It is a client-server protocol over JSON-RPC 2.0. One agent, many capabilities. This is the “give the model hands” problem.
A2A connects one agent to another agent. The unit of work is a Task: a client agent submits work to a remote agent and receives progress as the task moves through states, with streaming via Server-Sent Events for long-running jobs. Discovery happens through an Agent Card, a JSON document published at /.well-known/agent-card.json that advertises what an agent can do, what it accepts, and how to authenticate. This is the “let agents delegate to each other” problem. See Agent Card.
The A2A spec’s own analogy is an auto repair shop. A customer talks to the shop manager agent conversationally over A2A. Each mechanic agent uses MCP to drive its own tools: diagnostic scanner, repair manual, lift. Mechanics use A2A to coordinate with a parts supplier agent. The spec compresses it to: A2A is agents partnering on tasks, MCP is agents using capabilities.
Where the clean story holds
The division of labor is real at the design level. MCP has no concept of a peer agent, task lifecycle, or agent-to-agent authentication. A2A has no concept of a tool call, a resource, or a prompt template. You cannot substitute one for the other; they operate at different layers, the way HTTP and gRPC coexist rather than compete.
Adoption reinforces the split rather than collapsing it. MCP got a large head start through direct Claude integration and low onboarding cost, and became the default answer to tool access. A2A launched with 50+ enterprise partners and passed 150 organizations by early 2026 including AWS, Microsoft, Salesforce, SAP, and ServiceNow. Google donated A2A to the Linux Foundation on June 23, 2025, under Apache 2.0, removing the single-vendor control that would have made it a harder sell to competitors.
Where the boundary leaks
The clean two-box diagram gets muddy on contact.
The primitives overlap conceptually. An A2A Agent Card exposing a skill and an MCP server exposing a tool are both “here is a capability, here is how to call it, here is the auth.” The A2A docs concede an Agent Card could expose an agent’s skills as MCP-compatible resources. Whether you model a downstream capability as a tool (MCP) or a peer agent (A2A) is often a judgment call, not a fact about the system. A remote service wrapped as an MCP tool and the same service exposed as an A2A agent can be functionally interchangeable for many tasks.
They share transport. Both ride JSON-RPC 2.0 over HTTP. A2A adds SSE and optional gRPC bindings, MCP added its own remote transports. This is convergence at the plumbing layer, which is good, but it also means the protocols are close enough to invite “why not just extend one to do both.”
The field was more crowded than two. IBM shipped its own Agent Communication Protocol (ACP). There is a community Agent Network Protocol (ANP) aimed at decentralized agent marketplaces. Cisco pushed AGNTCY for identity and discovery. A May 2025 survey catalogs MCP, ACP, A2A, and ANP as four distinct interoperability protocols with overlapping scope. That is the xkcd-927 setup exactly: competing standards, each promising to unify the space.
The xkcd-927 question
xkcd 927: there are 14 competing standards, someone proposes a universal one to unify them, now there are 15. The agent-protocol space had the ingredients: multiple big vendors, overlapping scope, each shipping a spec with its own name.
So far it has not played out that way, and the reason is the counter-move to the comic. In August 2025, IBM and Google announced that ACP would merge into A2A under the Linux Foundation. ACP development is winding down; its assets and expertise are being folded into A2A. That is 15 standards collapsing back to 14, the consolidation xkcd’s joke says almost never happens. Two forces drove it. ACP had not won independent adoption, so it had little to lose. And once A2A was a foundation project rather than a Google project, absorbing a competitor’s spec became a contribution instead of a capitulation. Neutral governance turned a merger that would have looked like surrender into a donation.
The consolidation went further in December 2025. The Linux Foundation formed the Agentic AI Foundation (AAIF), and Anthropic donated MCP into it. A2A already lived under the Linux Foundation, so the two protocols that started as competing-vendor projects now sit under one neutral governance body, with Anthropic, Google, Microsoft, AWS, and OpenAI all platinum members. This matters for the xkcd worry: the strongest force pulling standards toward proliferation is vendor rivalry, and putting the rivals’ specs under a shared foundation removes the incentive to fork. Notably, OpenAI donated AGENTS.md to the same foundation rather than shipping a competing agent standard of its own. The comic’s premise is many vendors each defending a spec; AAIF is those vendors agreeing to stop.
The honest read as of mid-2026: the core split (MCP for tools, A2A for agent-to-agent) is stable and genuinely complementary, and the industry has consolidated toward it rather than fragmenting further. The edges are still muddled. There is real overlap at the discovery and capability-advertising layer, no settled answer on when a capability should be a tool versus an agent, and a live debate about whether A2A solved a problem enterprises have at scale or over-engineered for scenarios that stayed rare. MCP’s adoption is harder to quantify than A2A’s org counts, but the working impression across the ecosystem is that its pragmatic simplicity won the day-to-day tool-access case decisively, while A2A’s win is still mostly on paper and partner logos. The space is not a standards pileup. It is two protocols with a clean center and a fuzzy seam, plus a governance body actively pruning the alternatives.
See also
- Multi-LLM Coordinator — Idea — a CLI agent harness; the layer where you would decide whether a subtask is an MCP tool call or an A2A delegation.
- Async Coding Agents — agents that run long-horizon work, exactly the case A2A’s streaming Task lifecycle targets.
- The Death of SaaS — if agents transact with each other over A2A, the per-seat SaaS interface stops being where value is captured.
Try it
Wrap one capability both ways (2-3 hours, Python). Take a trivial service (a weather lookup, a calculator). Expose it once as an MCP server using the official mcp SDK with a single tool, and once as an A2A agent by serving a /.well-known/agent-card.json and a JSON-RPC message/send endpoint. Point a client at each. What you are looking for: how much of the “same” capability the two specs force you to model differently — auth, streaming, state — and where you feel the seam. If the clean-separation story holds, the MCP version is a few lines and stateless; the A2A version drags in task IDs and lifecycle you did not need. That asymmetry is the boundary made concrete.
Sources
- A2A and MCP — A2A Protocol docs — the official complementary framing and the auto-repair-shop analogy.
- Agent2Agent (A2A) Protocol Specification — Agent Card, Task lifecycle, JSON-RPC/SSE/gRPC bindings.
- A Survey of Agent Interoperability Protocols (arXiv, May 2025) — MCP, ACP, A2A, ANP compared side by side.
- Linux Foundation launches the A2A project — donation, Apache 2.0, founding members.
- What happened to Google’s A2A? (fka.dev) — the skeptical retrospective on A2A traction vs MCP.