MCP and A2A solve different problems, and most teams need one of them

Every few weeks someone asks us to choose between the Model Context Protocol and the Agent-to-Agent protocol, as though picking one rules out the other. They are not alternatives. They sit at different layers of the same stack, and a system can reasonably use one, both, or neither.

What each one is for#

MCP standardises how a model or agent reaches context and capability. Tools, files, databases, internal services. Instead of writing a bespoke integration for each tool and each agent, you expose the tool once behind a standard interface, and any MCP-speaking client can use it. It is, in the most useful sense, a driver model.

A2A standardises how agents delegate to each other. Discovery (what can you do) and task handoff, with status and results flowing back. It assumes the other agent is opaque: you do not know its internals, and you should not need to.

The distinction that makes it click: MCP is about an agent reaching downwards to things that are not agents. A2A is about an agent reaching sideways to things that are.

Which one you actually need#

Here is the uncomfortable observation from our engagements: most systems that ask for A2A do not need it yet.

If your “multi-agent system” is one team’s code, deployed as one unit, with all the sub-agents in the same repository, then delegation between them is a function call. Wrapping it in a network protocol with capability discovery adds latency, failure modes and debugging surface, and buys you nothing, because you already know what the other agent can do. You wrote it.

A2A earns its place at an organisational boundary. Two teams shipping independently. A vendor’s agent your agent needs to consult. A capability that must be swappable without redeploying the caller. Those are real, they are increasingly common, and the protocol exists because bespoke solutions to them were painful.

MCP, by contrast, earns its place almost immediately, because the tool integration problem shows up in every system with more than three tools and does not go away.

The performance angle, briefly#

There is measurement work suggesting MCP is faster for simple single-source queries while A2A consumes substantially fewer tokens on complex multi-step orchestration. That is roughly what you would expect from the shapes: direct tool access has less overhead; delegation to a specialist avoids dragging the whole problem through one context window.

We would not make an architecture decision on those numbers alone. They depend heavily on task shape, and the token saving from delegation only materialises when the specialist genuinely does the work with less context, which is a property of your decomposition, not of the protocol.

What to be careful about#

Tool exposure is an authorisation decision. A standard protocol makes it easy to connect a tool to an agent. Easy is the problem. Every tool an agent can reach is a capability an injected instruction can attempt to use. Scope tokens per agent, not per system, and log the principal on every call.

Discovery is an attack surface. In A2A, an agent advertises what it can do. Anything advertised can be requested. Treat capability discovery like an API surface, because it is one.

Neither protocol makes your agent good. They standardise plumbing. The reason an agent fails is almost never that its tool-calling convention was non-standard.

Where we land#

Use MCP for tool and context access. It removes real, repetitive integration work and gives you one place to enforce authorisation. Reach for A2A when a genuine organisational or deployment boundary appears between agents, and not before. If you are building both sides of the boundary and shipping them together, you have a module, not an agent, and you should let it be a module.