Your agents already call tools over MCP. A search tool, a database, a file system, maybe a memory server. Then someone on the team reads about A2A and asks whether you should be moving to it, and the conversation turns into which protocol is winning.
It is the wrong race to watch. MCP and A2A answer different questions, and both projects say so in their own words. The question worth asking is narrower: is the thing on the other end of this connection a tool you call, or an agent that runs on its own and hands you back a result?
One line to carry: MCP connects an agent to things it uses, A2A connects an agent to another agent that owns its own process, both can now keep a long piece of work open and pause it for input, and neither protocol carries what was learned into the next piece of work.
What each one connects
MCP is the vertical one. An agent, through its client, discovers the tools, resources and prompts a server offers and calls them. The unit of work is a tool call or a resource read. The current revision of the specification lists "Stateless, self-contained requests" among its design points, and its tools page is blunt about it:
MCP has no protocol-level session, so a server cannot rely on implicit per-connection state to relate one tool call to the next.
A2A is the horizontal one. It is a protocol for agents to hand work to other agents without seeing inside them, and the A2A specification states that directly: agents coordinate "without needing access to each other's internal state, memory, or tools". Its building blocks are an Agent Card, a manifest of what an agent can do and where to reach it, and Tasks, which carry Messages and produce Artifacts. The specification defines JSON-RPC, gRPC and HTTP+JSON bindings. And a Task has a lifecycle, with states such as working, input-required and completed, at the core of the protocol.
The lifecycle alone no longer separates them. Since the July revision an MCP tool call can come back asking for more input, and MCP's official tasks extension, opt-in on both client and server, gives long-running operations the same kind of states: working, input_required, completed, failed, cancelled. What separates the two is what sits on the other side. An MCP task is a long operation of a tool you called and understand. An A2A task is work handed to an agent you cannot see into, which decides for itself how to do it and hands you back a result.
Both projects say they compose
The A2A documentation has a page on exactly this question, A2A and MCP, and describes the two as addressing "distinct but highly complementary needs". It uses an auto repair shop to make the point: mechanics use their tools to do the work, and talk to each other to coordinate it.
Google's launch post for A2A put it the same way from the start, describing A2A as a protocol that "complements Anthropic's Model Context Protocol (MCP), which provides helpful tools and context to agents" (Google Developers Blog). A 2025 analysis of integrating the two, arXiv 2505.03864, frames them as horizontal and vertical integration standards respectively.
In practice a system that uses both looks like this. A planner agent receives a request. It delegates part of it over A2A to a specialist agent that another team runs. The specialist calls its own tools over MCP, finishes the task, and returns an Artifact over A2A. The planner never sees the specialist's tools, and does not need to.
The test for any given connection
Look at the other end of the connection you are about to build.
If it is a tool, an API, a data source, a file system or a context provider, something that does what it is told and returns, MCP is the protocol. That covers most of what a single agent needs.
If it is another agent, something with its own model, its own tools and its own judgement, that you want to hand a goal rather than a function call, A2A is the protocol. That matters most when the other agent is opaque to you: owned by another team or another company, running somewhere you do not control, and not something you want to import into your own process.
And if all your agents live in one process inside one framework, you may not need A2A at all yet. Handing work between them is a function call in your own code. A2A earns its place at the boundary where you stop owning the other side.
Where composing them costs something
The same 2025 analysis lists the costs at the seam: matching what a task means to what a tool can do, security exposure that compounds when discovery and execution are chained across agents, and debugging tools that do not span both protocols.
Security is the least settled of the three. A February 2026 threat-modelling study of MCP, A2A, Agora and the Agent Network Protocol, arXiv 2602.11327, says in its abstract that standardised threat modelling is limited and that "no protocol-centric risk assessment framework has been established yet". When an A2A task on one agent triggers MCP tool calls on another, each protocol's security model covers its own hop, and a model for the chain is exactly what that study is trying to start.
A2A is also not the only protocol on the horizontal axis. The same study covers Agora and the Agent Network Protocol, and the field has not settled on one.
What neither of them does
Both protocols move information. Neither keeps it.
MCP can connect an agent to a memory tool, and the agent can read and write through it like any other tool, but the protocol defines nothing about memory itself, and two agents with their own MCP connections do not share anything unless the server behind them does. A2A deliberately keeps agents opaque to each other: a task carries messages and artifacts, and nothing in the protocol carries the context the two agents built into the next task. It survives only if one side, or something outside the protocol, decides to keep it.
Research names the same gap. SAMEP opens with the claim that current agent architectures "suffer from ephemeral memory limitations" and proposes a memory exchange layer built to work alongside MCP and A2A. A 2026 position paper on multi-agent memory from a computer architecture perspective names two protocol gaps, "cache sharing across agents and structured memory access control", and calls multi-agent memory consistency the most pressing open challenge.
That is not a defect in either protocol. It is a layer neither was designed to fill, and it is worth knowing before you expect A2A to give your agents a shared history. It gives them a shared task. The history is a separate decision.
So the answer to the question in the title is usually no, not yet, and not instead. Keep MCP for everything an agent uses. Add A2A at the point where you delegate to an agent you do not own. Then decide separately what should outlive the task.
Where in your system is the first agent you hand work to without owning it?
Disclosure: I work on Mnemoverse, a memory service for agents that connects over MCP, which is one way to fill the gap in the last section, so weigh that section accordingly. The longer version with every source is on our library, and the MCP server is open source (MIT): github.com/mnemoverse/mcp-memory-server.
Top comments (0)