A2A and MCP Together

If you only learn one distinction about the protocol landscape, make it this one: MCP connects an agent to its tools; A2A connects an agent to other agents. Same broad goal — interoperability without bespoke glue — aimed at two different boundaries. They aren't rivals. They stack.

People keep framing them as competitors because they showed up around the same time and both have the word "protocol" in them. That's a category error, and it leads to silly arguments about which one "wins." Let me lay out what each actually does and then show them working in the same request, because that's when the relationship stops being abstract.

A2A in one paragraph

The Agent2Agent protocol was announced by Google in April 2025 and handed to the Linux Foundation a couple of months later, the same vendor-neutral move MCP made. Its job is agent-to-agent communication: how one agent discovers another, learns what it can do, hands it a task, and gets a result back — even when the two agents were built by different teams on different frameworks and you can't see inside either one.

The centerpiece is the Agent Card — a JSON document an agent publishes describing its identity, capabilities, and how to reach it. It's the agent-level analog of MCP's tools/list: a machine-readable "here's what I can do and how to call me." A client agent reads the card, then sends tasks over plain HTTP with JSON messages. No shared codebase, no SDK lock-in — just a published contract and web transport. By early 2026 the partner list had grown past a hundred organizations, which is the boring signal that matters: enough of the industry treats it as real that building on it is safe.

Why you need both

Here's the thing the "versus" framing misses. An agent is not just a thing that talks to other agents, and it's not just a thing that calls tools. A capable agent does both, constantly, and the two protocols cover the two halves.

Think of a travel-planning system. There's an orchestrator agent the user talks to. It doesn't know everything — so it delegates flight search to a flights agent and lodging to a hotels agent. That delegation, agent to agent, is A2A. But the flights agent, to actually do its job, has to query a live flight API. That query, agent to tool, is MCP. Strip out A2A and your orchestrator has to contain every capability itself — back to one monolith doing everything. Strip out MCP and each agent has to hand-roll every tool integration — back to M×N. You want both, because the boundaries they cover are both real.

The arxiv surveys of agent-interoperability protocols that came out through 2025 land on the same conclusion from a more formal angle: these are complementary layers, not substitutes. MCP is the vertical connection (agent → resources). A2A is the horizontal one (agent ↔ agent). A serious multi-agent system draws on both axes.

The two layers in one request

Watch a single user request move through both protocols:

The pink band is A2A: the orchestrator finding the flights agent via its card and handing off a task. The green band is MCP: the flights agent calling an actual tool to do the work. One user message, two protocols, each at its own boundary. Neither could cover the whole path alone — and that's exactly why they coexist rather than compete.

Where it gets sharp

The clean diagram hides a real question: where does the trust boundary go? When your orchestrator delegates to a flights agent it didn't build, that agent is now reasoning on your user's behalf — and it has its own MCP servers you can't see. Everything from the security post applies, now one level removed. A prompt-injection payload that reaches the flights agent can drive its tools, and you only ever see the result it hands back. A2A's identity and authentication features exist for exactly this reason: you want to know which agent you're delegating to and that it is what its card claims. Delegating to an agent is delegating authority. Treat it with the suspicion you'd treat connecting an unknown MCP server, because the risk is the same shape, just further away.

The second sharp edge is the same temptation that haunts every part of MCP: don't reach for the heavy layer when the light one suffices. A2A earns its complexity when you have genuinely independent agents — separate teams, separate deployment lifecycles, separate capabilities — that need to cooperate. If your "multi-agent system" is really one codebase with a few functions you've dressed up as agents, you don't need an inter-agent protocol. You need function calls. A2A between two modules in the same process is the agent-era version of microservices for a blog with nine readers.

How to hold the whole stack

After nine posts, here's the layered picture the MCP series has been building toward:

• A model decides and reasons.
• Function calling is how it acts — the in-process loop.
• MCP standardizes and ships the tools that loop calls, so capabilities are reusable across hosts.
• A2A lets whole agents — each with their own model and their own MCP tools — discover and delegate to each other.

Each layer covers a boundary the one below it can't reach, and each one is dead weight if you adopt it before you have that boundary. The skill isn't knowing the protocols. It's knowing which boundary you're actually standing at — and refusing to pay for the ones you haven't reached yet.

A2A and MCP together aren't a grand unified theory of agents. They're two sensible contracts for two real seams. Use the one the seam in front of you needs. Most days, that's still just MCP — and most days, that's enough.