A2A vs MCP: How They Differ (and Compose)
TL;DR
- MCP connects an agent down to its tools, data sources, and context. It is a vertical protocol.
- A2A connects agents across to other agents. It is a horizontal protocol.
- The two protocols are complementary layers of one stack, not competitors. The documentation from both Google and the A2A project says so directly.
- The hard problems live at the intersection: semantic interoperability, compounded security, and cross-protocol debugging.
- Neither protocol defines persistent shared memory. That remains an open layer in the multi-agent stack.
A search for "A2A vs MCP" usually signals one question: which protocol should I bet on? The honest answer is that the question itself is mis-framed. The two protocols address different axes of the agent integration problem. They were designed to compose, not to compete. Understanding the difference—and the real cost of making them work together—is what this article is about.
What is MCP?
MCP (Model Context Protocol) is an open standard for connecting models and agents to external tools, APIs, and data sources. It was originated by Anthropic and defines a client-server architecture where an agent (the client) discovers and calls tools exposed by one or more servers.
The protocol's unit of work is the tool call or resource read. Discovery happens through a server-provided listing of available tools and resources. State management is per-tool: a server may maintain internal state for a given tool session, but MCP itself does not prescribe a shared state model across tools or agents.
MCP's role in the stack is vertical. It connects an agent down to the things it can act upon—databases, APIs, file systems, memory servers. For a deeper walkthrough of how MCP works and where it fits, see our MCP memory server documentation and the companion piece on memory over MCP.
What is A2A?
A2A (Agent2Agent) is an open protocol for communication between opaque agents. It was originated by Google and contributed to the Linux Foundation under an Apache-2.0 license. The protocol lets agents coordinate tasks without needing access to each other's internal state, memory, or tools.
A2A's primitives are Agent Cards, Tasks, Messages, and Artifacts. An Agent Card is a machine-readable manifest that describes an agent's capabilities, skills, and endpoint. Tasks are stateful, asynchronous units of work that one agent delegates to another. Messages carry conversational context, and Artifacts carry structured outputs. The wire protocol is JSON-RPC 2.0, with HTTP/REST and gRPC as transport bindings and SSE for streaming, as defined in the A2A specification.
A2A's role is horizontal. It connects an agent across to other agents. For a full primer on the protocol, see A2A Protocol Explained.
A2A vs MCP: the difference
The cleanest one-liner comes from the A2A documentation: MCP and A2A address "distinct but highly complementary needs" A2A and MCP. The same page uses an auto-repair-shop analogy: mechanics (agents) use tools (MCP) to do their individual work, and they coordinate across bays via conversation (A2A).
Google's announcement of A2A states the relationship plainly: "A2A … complements Anthropic's Model Context Protocol (MCP), which provides helpful tools and context to agents" Google Developers Blog.
Academic literature formalizes this as a horizontal/vertical split. A 2025 critical analysis of A2A and MCP integration frames A2A and MCP as horizontal and vertical integration standards, respectively arXiv 2505.03864.
The table below distills the comparison from primary sources:
| Dimension | MCP | A2A |
|---|---|---|
| Connects | agent ↔ tools/context | agent ↔ agent |
| Direction | vertical | horizontal |
| Unit of work | tool call / resource | Task / Message / Artifact |
| Discovery | tool/resource listing | Agent Card |
| State model | per-tool | stateful, async tasks |
| Origin | Anthropic | Google → Linux Foundation (Apache-2.0) |
The disambiguation is mechanical once the axes are clear. If the integration point is a tool, API, resource, data source, or context provider, MCP is the relevant protocol. If the integration point is another agent that owns its own process and returns task results, A2A is the relevant protocol.
Do they compete?
No. The documentation is consistent on this. The A2A specification is explicit about complementarity. Google's launch blog frames A2A as additive to MCP. The academic analysis treats them as orthogonal layers of the same stack.
A practical system uses both. A concrete composition looks like this:
- A planner agent receives a user request.
- It uses A2A to delegate a subtask to a specialist agent.
- The specialist agent uses MCP to call tools and read context.
- The specialist returns Messages or Artifacts through A2A.
- The planner integrates the result.
That composition is valid. It is not free.
Integration is not free
The more useful question is not whether the protocols compete, but what happens at the intersection. The same critical analysis that frames the horizontal/vertical split also catalogs the integration risks: semantic interoperability between task definitions and tool capabilities, compounded security exposure from chained discovery and execution, and a lack of mature debugging tooling that spans both protocols arXiv 2505.03864.
Security is an especially open concern. A 2025 threat-modeling study across MCP, A2A, Agora, and ANP found that "no protocol-centric risk assessment framework yet exists" for multi-agent systems arXiv 2602.11327. When an A2A task triggers an MCP tool call across agent boundaries, the attack surface compounds. The protocols compose architecturally, but the security model does not yet compose cleanly.
A2A is also not the only inter-agent protocol. ANP (Agent Network Protocol), ACP (Agent Communication Protocol), and Agora are active alternatives. The landscape is plural, and A2A's adoption trajectory is still being determined by the Linux Foundation governance process and community uptake.
So the honest guidance is not "just use both." It is: use MCP for tool and context access, use A2A for agent-to-agent coordination, then design the boundary between them deliberately.
What about memory?
Both protocols move information. Neither remembers it across sessions, agents, or machines.
On the MCP axis, MCP can connect an agent to a memory tool—the agent calls a memory server like any other tool, reading and writing facts within a session. But MCP itself defines no shared memory model. Two agents, each with their own MCP connections, do not automatically share a memory substrate. A2A explicitly scopes agent interactions to opaque execution: the specification states that agents coordinate "without needing access to each other's internal state, memory, or tools" A2A Specification. A2A tasks carry Messages and Artifacts, not persistent memory. When a task completes, the shared context dissolves unless an external system captures it.
Research describes the same gap. The SAMEP framework identifies persistent shared memory as a missing primitive in current multi-agent architectures arXiv 2507.10562. A 2026 position paper on multi-agent memory concludes that the problem remains unsolved at the protocol level arXiv 2603.10062.
This is not a defect in either protocol. It is a layer they were never designed to fill. A persistent, domain-scoped memory substrate—shared across agents, surviving session boundaries, and independent of any single agent's internal state—sits alongside MCP and A2A as a third architectural concern:
Agent A ◄────── A2A (horizontal) ──────► Agent B
│ │
MCP (vertical) MCP (vertical)
│ │
tools/ tools/
context context
│ │
└──────────────┐ ┌────────────────┘
▼ ▼
┌──────────────────────────────────────┐
│ persistent shared memory substrate │
│ (survives sessions, agents, machines)│
└──────────────────────────────────────┘On the MCP axis, that substrate plugs in as a memory tool. On the A2A axis, it serves as the shared ground agents coordinate through. Mnemoverse ships an MCP memory server, @mnemoverse/mcp-memory-server, that fills the first of those roles; the design rationale is covered in memory over MCP. Why such a layer is more than a vector store is the subject of Not a Vector Database.
Common questions
What is the difference between A2A and MCP?
MCP connects an agent down to its tools and context (vertical integration). A2A connects agents across to other agents (horizontal integration). They address distinct layers of the agent stack and are designed to compose.
Does A2A replace MCP?
No. Google, the A2A protocol documentation, and independent research describe A2A as complementary to MCP. A2A handles agent-to-agent communication; MCP handles agent-to-tool connections.
Who created A2A and MCP?
MCP was originated by Anthropic. A2A was originated by Google and contributed to the Linux Foundation under an Apache-2.0 license.
What are the other inter-agent protocols besides A2A?
A2A is one of several emerging inter-agent protocols. Others include the Agent Network Protocol (ANP), Agent Communication Protocol (ACP), and Agora. The field is active and no single protocol holds a monopoly.
Do A2A and MCP handle persistent memory for agents?
No. Both protocols move information between or into agents, but neither defines a mechanism for persistent shared memory across sessions, agents, or machines. That remains an open layer addressed by separate memory substrates.
Related
- A2A Protocol Explained — full primer on the Agent-to-Agent protocol
- A2A Integration How-To (Python) — stand up + connect an A2A agent in Python
- Memory MCP: Why Agents Need Persistent Memory — the case for memory as a first-class MCP tool
- MCP Memory Server API — the
@mnemoverse/mcp-memory-serverintegration - Not a Vector Database — why memory is more than retrieval
- Multi-Tenant Memory Platform — domain-scoped memory for multi-agent systems
Mnemoverse is a persistent-memory engine for AI agents. This article is part of the Mnemoverse Library, a research surface for AI engineers and architects. Published June 18, 2026.