One connects an agent to its tools. The other connects agents to each other. Confusing them is the fastest way to build an architecture that fights you.
MCP (Model Context Protocol) connects a single AI agent to tools, data, and context. It answers: how does my agent use a resource — read a file, query a database, call an API?
A2A (Agent2Agent) connects agents to other agents. It answers: how does my agent delegate work to another agent, and get results back?
MCP is vertical — an agent reaching down to its capabilities. A2A is horizontal — an agent reaching across to its peers. They are complementary, not competing. Both are open standards governed by the Linux Foundation, and most production systems run both.
Why this question keeps coming up
Ask around and you'll hear A2A and MCP discussed as if they were rivals — as though picking one is a strategic decision with a winner. It isn't. The two protocols do not overlap, and the reason people think they might is that both showed up around the same time, both are about connecting agents to something, and both are open standards with big names behind them.
But once you know what sits on the other end of each connection, the confusion dissolves permanently. That's what this piece is for.
What is MCP?
MCP — the Model Context Protocol — is an open standard for connecting an AI agent to tools, data sources, and context. When an agent needs to read a file, query a database, hit an API, or pull in a document, MCP is the layer that makes that possible in a standardized way rather than through bespoke integration.
Before MCP, every agent framework had its own notion of a "tool," and wiring an agent to a data source meant writing an adapter specific to both. MCP made that connection a protocol, so a tool exposed once works with any agent that speaks it.
MCP is what gives an individual agent its capabilities. An agent without MCP (or something like it) can think, but it cannot reach anything.
What is A2A?
A2A — Agent2Agent — is an open protocol for agent-to-agent communication. It lets independent agents discover each other, delegate tasks, and exchange results securely, regardless of which framework or vendor built them.
A2A was introduced by Google in April 2025 and contributed to the Linux Foundation, which now governs it as a vendor-neutral standard. It has since reached a stable 1.0 release with core data models frozen. Official SDKs ship for Python, JavaScript, Java, Go, and .NET, and the protocol is supported inside Microsoft Copilot Studio, Azure AI Foundry, Amazon Bedrock AgentCore, and Google ADK.
Under the hood it is deliberately unglamorous: HTTP for transport, JSON-RPC 2.0 for structured requests, Server-Sent Events for streaming updates, and OAuth 2.0 with JWTs for authentication. Nothing exotic — which is exactly why adoption moved fast.
The five things A2A is made of
-
Agent Card — a JSON document describing an agent's identity, endpoint, authentication, and skills, published at
/.well-known/agent-card.jsonso others can discover it. - Task — the central, stateful unit of work, with a lifecycle you can track from submission to completion.
- Message — a single turn of communication between two agents.
- Parts — typed content inside a Message: text, file, or structured data.
- Artifact — the durable output a completed Task produces.
A client discovers an agent via its card, sends a Message to open a Task, follows that Task through its states, and collects Artifacts when it completes. Five nouns, one flow — that's most of the protocol.
A2A vs MCP: the comparison
| MCP | A2A | |
|---|---|---|
| Scope | Agent to tool and context | Agent to agent collaboration |
| Question it answers | How does my agent use this resource? | How does my agent work with that agent? |
| Other end of the wire | A tool, server, or data source | An independent agent with its own skills |
| Unit of interaction | A tool call or resource read | A Task with a lifecycle |
| Direction | Vertical — reaching down | Horizontal — reaching across |
| Governance | Open standard, Linux Foundation | Open standard, Linux Foundation |
MCP gives an agent hands.*A2A gives it colleagues.*
How they layer in a real system
Picture a market-report system in two planes.
Horizontally, over A2A: a user asks an orchestrator agent for a report. The orchestrator delegates data-gathering to a research agent and chart-making to a visualization agent — discovering each by its Agent Card, authenticating with a scoped token, and streaming each Task to completion.
Vertically, over MCP: the research agent queries live data sources; the visualization agent calls a rendering tool. Each is reaching down to the capabilities it needs.
Results flow back up as Artifacts, and the orchestrator assembles the report. Two planes, each doing one job, combining into something neither could do alone. A2A moved the work between agents; MCP fed each agent the context it needed.
When do you need both?
- Use MCP alone if your agent uses tools but never delegates to another agent. A single capable assistant with database access needs no A2A.
- Use A2A alone for a pure router that forwards tasks between agents and holds no tools of its own. Rare, but real.
- Use both when an agent needs to act on resources and collaborate with peers — which describes essentially every multi-agent system of any ambition.
The goal is a system as simple as the problem allows. Don't reach for A2A because multi-agent sounds impressive: every delegation adds a network hop and usually another model call. Reach for it when specialization or scale genuinely earns that overhead.
Why the pairing is the durable bet
Standards win when they compose. HTTP did not have to also be HTML — each did one job, and together they carried the web. A2A and MCP follow the same logic, which is why betting on the pair is safer than betting on any single framework.
Here's the part worth internalizing: an agent that speaks A2A exposes only its card and its skills. Everything behind that surface is private — which model it calls, which framework it runs on, which tools it reaches through MCP, how its logic is written. Replace any of those and every caller is unaffected, because none of them ever depended on it.
Models will improve. Frameworks will be replaced. A catalog of well-described agents that speak an open protocol stays callable through all of it. The protocol is the stable interface; everything underneath can evolve freely.
Common mistakes
- Using A2A to reach a database. If the other end is a resource, it's MCP. Ask what's on the other end — that answers it every time.
- Using MCP to connect two agents. Wrapping an agent as a "tool" works until that agent needs to ask a clarifying question, run for ten minutes, or report progress. Tasks exist for a reason.
- Treating A2A like a function call. It's a protocol for stateful, long-running, cross-trust collaboration. Design for that and most problems disappear.
- Trusting peers by default. An agent that speaks A2A is not automatically safe. Authenticate every request, authorize narrowly, validate all input, rate-limit.
Frequently asked questions
What is the difference between A2A and MCP?
MCP connects a single agent to tools, data, and context — it answers how an agent uses a resource. A2A connects agents to other agents — it answers how one agent delegates work to another. MCP is vertical; A2A is horizontal. They are complementary, and most production systems use both.
Is A2A a replacement for MCP?
No. They solve different problems and are designed to coexist. They never overlap, because they meet at the agent — which speaks A2A outward to peers and MCP downward to its tools. Both are governed under the Linux Foundation.
Is A2A production ready?
Yes. A2A reached a stable 1.0 release with core data models frozen, is governed by the Linux Foundation as a vendor-neutral standard, ships official SDKs for five languages, and is supported inside Microsoft Copilot Studio, Azure AI Foundry, Amazon Bedrock AgentCore, and Google ADK.
Do I have to rewrite my agents to adopt A2A?
No. A2A is not a framework — it's a messaging layer between agents. You keep your existing stack. Adoption means giving an agent an Agent Card and an A2A endpoint; its internals stay exactly as they are.
Which should I learn first?
MCP, if you're starting from a single agent — give it hands before you give it colleagues. A2A, if you already have capable agents that can't talk to each other, because that's the wall you're hitting.
More in this series
- What Is A2A? — What Is the Agent2Agent Protocol? A Complete Introduction to A2A
- The Agent Card — The Agent Card: How AI Agents Discover Each Other
- The Task Lifecycle — Understanding the A2A Task Lifecycle (and the Bug That Hangs Every Client)
Want to go deeper?
I wrote two guides on this.
A2A Quick-Start — free, 6 pages. The Agent2Agent protocol in 15 minutes: what it is, the five building blocks, the task lifecycle, and where MCP fits.
A2A: The Complete Guide — 42 pages. 15 chapters, 5 appendices. Discovery, security, building your first agent with the SDK, orchestration patterns, extensions and AP2, production and scaling — plus a full worked example of two agents talking and a 30-day adoption path.
Independent educational content. Not affiliated with, endorsed by, or sponsored by Google, the Linux Foundation, Anthropic, or any vendor named. A2A and MCP are evolving specifications — confirm details against the official specification for your target version.
Top comments (0)