The search query "a2a vs mcp" has a hidden premise, and the premise is wrong. The "vs" assumes a contest — two standards, one survivor, a bet you can lose by choosing badly. That is not the situation. Anthropic's Model Context Protocol and Google's Agent2Agent protocol do not occupy the same square on the board. They run on different axes. You will, in most real systems, use both, and the more interesting question is not which one wins but why each one was designed to refuse the other's job.
Two axes, not two armies
Start with the geometry, because it dissolves most of the confusion.
MCP is vertical. It connects one agent down to the things it needs to act: tools it can call, resources it can read, prompt templates it can reuse. Anthropic introduced MCP in November 2024 as a client-server standard built on JSON-RPC 2.0. An MCP client (your IDE, your chatbot, your agent runtime) connects to MCP servers — small programs that expose a database, a filesystem, a Slack workspace — through three primitives: tools (actions the model can invoke), resources (read-only data), and prompts (reusable templated instructions). The metaphor everyone reaches for is USB-C, and for once the cliche is accurate: MCP is the port into which capabilities plug.
A2A is horizontal. Google announced it on April 9, 2025 with more than 50 launch partners, and it connects one agent across to another agent. Not to a tool — to a peer. The vocabulary is different on purpose. An A2A client discovers a remote agent by reading its Agent Card, a JSON document advertising the agent's identity, skills, endpoint, and auth requirements. It then opens a Task — the stateful unit of work, with a defined lifecycle — and exchanges Messages (turns, each carrying Parts) until the remote agent returns Artifacts: the documents, structured data, or images that are the task's output. Transport is HTTP, Server-Sent Events, and JSON-RPC.
So the answer to "A2A vs MCP" is the answer to "screwdriver vs hammer." An agentic application uses A2A to talk to other agents; each of those agents internally uses MCP to reach its own tools. The A2A spec says this in nearly those words: the protocols address "distinct but highly complementary needs."
The non-obvious part: A2A is built to hide things
Here is where the architecture stops being a tidy diagram and starts being a confession.
MCP exposes. The whole point of an MCP server is to make a tool legible — well-defined inputs, well-defined outputs, a schema the model can read and call. A2A does the opposite. In A2A, a remote agent is, by design, an opaque system. The spec is blunt: interactions "do not require sharing thoughts, plans, or tools." You see the Agent Card and the Artifacts. You do not see the agent's memory, its reasoning, or — critically — its tools. The black box is not an accident or an unfinished feature. It is the feature.
A2A's opacity is the protocol encoding a commercial reality: agents from different vendors will cooperate only if they never have to show each other how they work.
Think about why that matters. If Salesforce's agent and SAP's agent have to collaborate on a procurement task, neither company wants the other to enumerate its internal tools, inspect its prompts, or learn its data sources. Those are the IP. MCP-style transparency between competing vendors would be commercial suicide. A2A solves the political problem first and the technical one second: it lets agents partner on tasks while preserving the boundary between organizations. The opacity is a peace treaty written in JSON.
This is why "vertical vs horizontal" undersells it. The real distinction is trust posture. MCP assumes an agent owns and trusts its tools — you wire your own server to your own model. A2A assumes the agents on either side are strangers, possibly rivals, who will share state and instructions but never internals. One protocol is for the inside of your house; the other is for the property line.
The "standards war" is already over
If you came looking for a winner, the governance story should retire the question entirely. Both protocols have left their corporate parents.
Google donated A2A to the Linux Foundation, announced June 23, 2025 at the Open Source Summit North America. The Agent2Agent Protocol Project launched with a roster that reads like a truce — Amazon Web Services, Cisco, Google, Microsoft, Salesforce, SAP, and ServiceNow — seeded with Google's transfer of the specification, SDKs, and tooling, under explicitly vendor-neutral governance.
Anthropic followed. In December 2025 it donated MCP to the Agentic AI Foundation, a new directed fund under the Linux Foundation co-founded with Block and OpenAI. Same logic: the Linux Foundation provides a neutral home, the maintainers keep technical autonomy, and no single vendor dictates direction.
So as of mid-2026 both protocols sit under the same umbrella foundation. They were never competing for the same slot, and now they are not even competing for the same custodian. The thing developers feared — backing the loser in a format war — cannot happen, because there is no war and there is no single format to lose.
What to actually do
- Building an agent that needs tools, files, or data? That is MCP. Stand up servers, expose tools and resources, connect your client.
- Building a system where agents from different teams or vendors hand work to each other? That is A2A. Publish Agent Cards, model the work as Tasks, accept that you will not — and should not — see inside the other agent.
- Building something ambitious? You will do both, and the seam between them is the design, not a problem to be solved away.
The query was "a2a vs mcp." The honest reframing is "a2a and mcp, on perpendicular axes, by design." The "vs" was never a technical claim. It was a market anxiety. The protocols already settled it.
