TL;DR
MCP standardizes how a single agent discovers and calls tools. A2A standardizes how separate agents hand work to each other. They operate at different layers of the same system, not two competing ways to do the same job. A planner agent that delegates a subtask to a specialist agent needs A2A for that handoff; the specialist agent then likely uses MCP internally to call the tools it needs to actually do the work. Most production multi-agent systems end up using both, one for orchestration between agents, one for each agent's own tool access.
This post draws the line precisely: what each protocol actually does, how A2A's task lifecycle works, and an honest answer to when a single-agent system never needs A2A at all. It's the interoperability spoke of the context engineering series: every other post in that series assumes a single agent's context, this one is about what changes once a second agent enters the picture. If you need ACP in the picture too, the three-way protocol comparison routes between all of them; this post is the deep dive on the MCP and A2A pair specifically.
Building a system where more than one agent needs to hand off work? We design the orchestration boundary between agents before picking a protocol, since most teams reach for A2A a step before they actually need it.
Key Takeaways
- MCP is agent-to-tool: one agent, a client-server connection, discovering what a server can do. A2A is agent-to-agent: two or more independent agents, a peer-to-peer relationship, each capable of acting as both client and server.
- A2A organizes work as Tasks with a defined lifecycle (submitted, working, completed, failed, canceled), not a single request-response call, which is why it supports long-running, multi-turn, asynchronous handoffs that a plain API call does not.
- Discovery in A2A happens through an Agent Card, a JSON document a server publishes describing its identity, skills, and how to authenticate to it, the A2A equivalent of what an MCP server's tool list does for a single agent.
- A completed A2A Task returns one or more Artifacts, built from the same Message-and-Part structure used to send the request in the first place, structured output an agent boundary can hand back, not just a text reply.
- The two protocols are not in competition. Google's own documentation frames them as complementary: MCP handles what happens inside one agent's reach for tools, A2A handles what happens between agents that do not share that reach.
- If your system is one agent calling its own tools, you do not need A2A at all, no matter how many tools it has. A2A earns its complexity only once a second, independently-built agent enters the picture.
What does each protocol actually connect?
MCP connects an agent to the tools, data, and APIs it needs to act. It is a client-server relationship: the agent is the client, an MCP server exposes a list of tools with names, descriptions, and schemas, and the client discovers what is available at connection time rather than a developer hardcoding it in advance. One agent, potentially many tools, one direction of discovery.
A2A connects agents to each other. It is a peer-to-peer relationship: an A2A agent can act as both client and server, initiating work with one agent while accepting delegated work from another. Where MCP answers "what can this agent reach," A2A answers "which other agent should handle this, and how do I hand it the work."
How does A2A actually structure a handoff?
A2A treats work as a Task, a stateful unit with a unique ID that progresses through a defined lifecycle: submitted, working, completed, failed, or canceled. That matters because agent work is rarely a single request-response exchange the way an API call is. A task can run long, require multiple turns, or need a status check an hour later, and the lifecycle gives both sides a shared vocabulary for where things stand.
The two sides of a Task have names in the spec: the A2A Client is the agent initiating the request, the A2A Server, usually called the Remote Agent, is the one exposing the endpoint that accepts it. What passes between them is a Message, built from one or more Parts, each carrying either text, raw bytes, a URL reference, or structured data. A completed Task hands back one or more Artifacts, the client's actual output, themselves just another array of Parts. It's the same idea as an MCP tool result, sized for handing a full document or dataset back across an agent boundary instead of one JSON return value.
Discovery works through an Agent Card, a JSON document a Remote Agent publishes describing its identity, the skills it offers, its endpoint, and which authentication schemes it accepts. A client reads the card before it ever sends work, the same role an MCP server's tool list plays for a single agent, just one layer up, describing an entire agent instead of an individual tool.
Underneath, both protocols speak the same base wire format, JSON-RPC 2.0 over HTTP, so an agent that already implements one has most of the plumbing for the other. A2A adds Server-Sent Events for streaming real-time progress on a task still in flight, and push notifications, an agent posting to a client-provided webhook, for work that outlives the connection. Security is not protocol-specific invention: A2A mandates HTTPS and delegates authentication to standard mechanisms, OAuth 2.0, OpenID Connect, API keys, or mTLS, declared per-agent in that same Agent Card.
Do they compete, or does one sit on top of the other?
Neither, exactly, they sit side by side. Google's own framing is direct: MCP standardizes how an agent reaches tools and data; A2A standardizes how agents collaborate with each other. A common real architecture makes the split concrete: a planner agent receives a request, decides which specialist agent should handle each piece, and hands off work over A2A. Each specialist then does its actual job by calling its own tools over MCP. The planner never touches those tools directly, and the specialists never need to know about each other, only about the task they were handed.
A concrete version of that: a support inbox agent reads an incoming ticket, recognizes a refund request, and opens an A2A Task with a separate billing agent, one built and deployed by a different team, running on its own infrastructure. The billing agent receives the ticket details as a Message, checks refund eligibility by calling its payments database and policy engine over MCP, tools the support agent never sees or touches, and returns its decision as an Artifact. The support agent relays that back to the customer without ever needing to know how eligibility was determined, only that it was.
| MCP | A2A | |
|---|---|---|
| What it connects | An agent to its tools and data | An agent to another, independent agent |
| Relationship | Client-server, one direction of discovery | Peer-to-peer, either side can initiate |
| Unit of work | A tool call, request in, result out | A Task with a lifecycle, can span turns and time |
| Discovery mechanism | Server publishes a list of tools with schemas | Server publishes an Agent Card describing itself |
| Typical scope | Inside one agent's boundary | Across a boundary, often a different team or vendor |
When do you actually need A2A?
If you are building one agent that calls its own tools, however many, you do not need A2A. That is an MCP problem, fully, and adding an agent-to-agent protocol to a system with only one agent is complexity with nothing on the other end of it.
A2A earns its place once a second, genuinely independent agent enters the system, one your planner does not control the internals of, possibly built by a different team or running on a different vendor's infrastructure entirely. The test is not "does my system have multiple steps," most agentic workflows do. The test is whether those steps are handled by one agent using several tools, which stays inside MCP, or by separate agents that need a standard way to hand each other work without either one knowing how the other is built.
In practice, that tends to show up as one of a few shapes:
- Cross-team or cross-vendor handoffs. A support agent calling a billing agent owned by a different team, or a partner's agent entirely, where neither side wants to expose its internals to the other.
- Agent marketplaces. A client agent discovering and calling a remote agent it has never integrated with before, using the Agent Card the way a browser uses a page's metadata, sight unseen until the moment it is needed.
- Long-running, resumable work. A task that runs for hours and has to survive a dropped connection, where the Task lifecycle and push notifications carry weight a single response cannot.
If none of those describe your system, the tool count doesn't matter, stay on MCP.
Frequently asked questions
Is A2A a replacement for MCP?
No. They solve different problems at different layers. MCP connects an agent to the tools it uses; A2A connects that agent to other agents. A system can use both at once without redundancy, since one governs tool access and the other governs delegation between agents.
Can I use A2A without MCP, or MCP without A2A?
Yes, both directions are common. A single agent calling only its own tools needs MCP and never touches A2A. A coordination layer that only routes tasks between agents that happen to have no external tools of their own could use A2A without MCP, though in practice most specialist agents on the receiving end of an A2A handoff do use MCP internally.
Where does RAG fit, is it part of A2A or MCP?
Neither, directly. Retrieval-augmented generation is a technique a single agent uses to pull relevant context before it generates a response, most often built today as an agentic retrieval loop rather than a one-shot lookup. That loop is typically exposed to the agent as an MCP tool, a search or vector-store call the agent invokes like any other tool. It only becomes an A2A concern if retrieval itself is delegated to a separate, independently-run retrieval agent instead of staying a tool the main agent calls directly.
What is an Agent Card in A2A?
A JSON document an A2A server publishes describing its identity, the skills it offers, its service endpoint, and the authentication schemes it accepts. A client reads it before sending any work, the A2A equivalent of an MCP server's tool list, scoped to a whole agent instead of an individual tool.
Why does A2A use a Task lifecycle instead of a simple request-response call?
Because agent-to-agent work is often long-running, multi-turn, or disconnected from the original request, unlike a typical API call. States like submitted, working, completed, failed, and canceled give both agents a shared way to track a handoff that might take an hour and involve several exchanges, not just an instant reply.
Who created A2A, and is it tied to one vendor?
Google introduced A2A as an open protocol for agent interoperability across vendors and frameworks, the same open-standard approach Anthropic took with MCP. Neither protocol is scoped to its creator's own products.
