A2A vs MCP: Two Different Games

Everyone's arguing about whether MCP is dead. They're asking the wrong question. Here's the architectural split that actually matters.

The MCP discourse is exhausting.

One week it's dead. The next week it's the future of agentic systems. The week after that, a Perplexity CTO post goes viral saying it's overhead-heavy and overengineered, and the cycle starts again.

Here's what nobody says clearly: MCP and A2A aren't competing protocols. They're solving different problems at different layers of your stack. Conflating them doesn't just create confusion — it produces architectures with the wrong failure modes built in from day one.

Let me show you what I mean.

The layer split nobody draws

When you're building a multi-agent system, you have two fundamental coordination problems:

Problem 1: How does my agent find and use tools?

A tool might be a database query, an API call, a file operation, a code execution environment. The agent needs to know what tools exist, what they accept, and what they return. This is a *vertical* relationship — agent to tool, one layer down.

Problem 2: How do my agents coordinate with each other?

Agent A needs to hand off context to Agent B. Agent B needs to report results back to an orchestrator. Two agents need to avoid stepping on each other in a shared workspace. This is a *horizontal* relationship — agent to agent, same layer.

MCP solves Problem 1.

A2A solves Problem 2.

That's it. That's the whole split. The reason it gets muddled is that both protocols involve "agents talking to things" — but the direction, the semantics, and the failure modes are completely different.

What MCP actually does

Model Context Protocol is a standardized way for an agent to discover and invoke tools. When you define an MCP server, you're publishing a schema: here are the tools available, here's what they accept, here's what they return.

The agent ingests that schema at startup — typically as a block of tool definitions injected into the context window. It then uses those definitions to decide which tool to call, constructs the call, and processes the response.

The real value isn't the protocol itself. It's standardization. Before MCP, every team was building their own tool-calling wrapper, slightly differently, with slightly different schemas, with slightly different error handling. The integration cost was per-team, per-tool, every time.

MCP makes that cost pay-once. You write the server once. Any compliant agent can use it.

The overhead critique is real but mislocated. Yes — injecting a 10-tool MCP server schema consumes context tokens at startup. Yes, for a single-agent system with three known tools, that overhead is pure waste. But the critique assumes single-agent, static-tool architectures.

In multi-agent systems where tools are discovered at runtime across agent boundaries, MCP overhead is the cheaper problem. The alternative is every team maintaining custom tool registries, each one a liability.

We run MCP in production at AIGENTIVE for exactly one purpose: tool discovery across agent boundaries. The initialization cost is paid once at agent startup, not per query. Different architecture, different math.

What A2A actually does

Google's Agent-to-Agent protocol is about agent coordination, not tool invocation. Where MCP is agent→tool (vertical), A2A is agent→agent (horizontal).

A2A defines how agents expose their *capabilities* to each other, how they negotiate tasks, how they stream results back, and how they handle long-running operations across sessions. The mental model is closer to a microservice mesh than a tool registry — agents as independent services that communicate, delegate, and report.

The key distinction: an A2A call is a peer interaction. When Agent A calls Agent B via A2A, Agent B isn't a tool. It has its own context window, its own memory, its own decision-making loop. It can push back, ask clarifying questions, return partial results, or fail gracefully with a structured error.

A tool can't do any of that. A tool executes and returns. That's the whole contract.

This matters enormously when you're building systems where the "tools" have agency of their own — code review agents, research agents, planning agents. You don't want those running inside your context window. You want them running independently, reporting back via a structured protocol.

Where teams go wrong

The failure mode I see most often: teams reach for A2A when they actually have a tool problem, or bolt on MCP when they actually have a coordination problem.

Mistake 1: Using A2A for what should be MCP tools

A team builds a "Search Agent" that their main orchestrator coordinates with via A2A. But the search agent doesn't have memory, doesn't make decisions, doesn't push back on requests. It just takes a query and returns results.

That's a tool. It should be an MCP server. You're paying A2A coordination overhead — task negotiation, streaming setup, session management — for something that should be a single function call.

The tell: if your "agent" has no persistent state, no decision loop, and always returns synchronously — it's a tool wearing an agent costume.

Mistake 2: Using MCP for agent coordination

The opposite error. A team uses MCP tool calls to coordinate between two actual agents — passing context, delegating subtasks, collecting results. The whole thing runs inside one context window.

Context bloat is the obvious problem. But the subtler issue is failure isolation. When one MCP tool fails, it fails inside your context. There's no retry logic at the agent boundary, no graceful degradation, no circuit breaking. The whole session is now in a degraded state with no clean way to recover.

A2A handles this at the protocol layer. Failed tasks can be retried by the caller. Long-running operations can be checkpointed. Agents can report "blocked" status without corrupting the orchestrator's state.

The decision framework

Three questions to know which you need:

1. Does the thing you're calling have its own decision loop?

If yes → A2A. If no (it just executes) → MCP.

2. Does it need to run longer than your context window budget?

If yes → A2A (long-running task support, streaming, checkpoints). If no → MCP.

3. Will multiple different agents need to call it independently?

If yes → MCP (standardized interface, any agent can use it). If this is point-to-point → A2A.

Most production systems need both. The architecture isn't A2A *or* MCP. It's A2A *and* MCP at different layers.

What our stack actually looks like

At AIGENTIVE, the split is clean:

MCP layer (vertical): Tool servers for database access, file operations, web search, code execution, memory read/write. Every tool is an MCP server. Any agent that needs those tools gets them injected at startup. One codebase, used by every agent in the system.

A2A layer (horizontal): Our orchestrator agent coordinates with specialized subagents — a research agent, a code review agent, a content agent — via A2A. Each runs in its own process with its own context window. The orchestrator delegates, polls for results, and assembles the final output.

The boundary is deliberate: nothing that has a decision loop runs as an MCP tool. Nothing that's a simple executor runs as an A2A agent.

When we got this wrong early on, we had a "research agent" running as an MCP tool inside our main context window. It worked until the research output got long. Then it consumed 40% of our context budget on every call, leaving almost no room for the actual task. Refactoring it to A2A dropped context usage to near-zero on the orchestrator side — the research happened externally and came back as a structured summary.

The perf difference was immediate. The cognitive overhead of building agents that could run in their own process was worth it completely.

The practical upshot

Stop asking "MCP or A2A?" Start asking "tool or agent?"

If what you're building executes a defined operation and returns a result: MCP. Write the server once, inject it everywhere, pay the startup cost once.

If what you're building has state, makes decisions, or runs longer than a single turn: A2A. Let it run independently, coordinate via the protocol, keep your orchestrator's context clean.

The debate isn't MCP vs A2A. It's: do you know which problem you're actually solving?

Most teams don't. That's where the architectural debt starts.