A2A and MCP: two protocols, two jobs.

Open any agent-infrastructure thread from the last year and you will find the same question phrased as a cage match: A2A or MCP — which one wins. Comparison posts line them up feature by feature. Conference talks slot them into the same “agent protocol” bucket and ask the audience to pick. The framing has hardened into received wisdom: two standards, one slot, may the best one ship.

It is the wrong frame, and it is wrong in a way that costs you. A team that believes A2A and MCP compete will choose one, build on it, and discover halfway through that the protocol it picked does not do the job the other one was for — because the two were never answering the same question. MCP connects an agent to its tools. A2A connects an agent to other agents. Those are different jobs at different layers of the same system, and a multi-agent system of any seriousness needs both.

This post is the layering: what each protocol’s job actually is, where they genuinely overlap, where identity has to span both — and the honest answer to the question most teams should ask first, which is whether they need A2A at all yet.

The framing error — a rivalry that was never declared

Start with where the “versus” came from, because it did not come from the protocols’ authors. MCP is Anthropic’s, open-sourced in November 2024 as a standard way to connect a model to external tools and data. A2A — Agent2Agent — is Google’s, announced in April 2025 at Google Cloud Next and donated two months later to the Linux Foundation. Two protocols, two vendors, two press cycles inside six months. The “versus” is an artifact of that timing and of the human habit of sorting new things into rivalries.

The authors say the opposite. Google’s A2A material describes the protocol as complementary to MCP from the first announcement, and the A2A specification carries an explicit section on the relationship. Its analogy is an auto-repair shop staffed by AI agents: A2A is the conversation between the customer, the shop manager, the mechanic, and the parts supplier; MCP is each mechanic reaching for a diagnostic scanner or a repair-manual database. The shop needs both. Nobody asks whether the conversation competes with the wrench.

The reason the error costs you is architectural, not semantic. Pick MCP “instead of” A2A and you have a good way for one agent to call tools and no standard way for it to delegate to another agent. Pick A2A “instead of” MCP and you have agents that talk to each other and no standard way for any of them to touch a database. You did not choose the better protocol. You shipped half a system and named the missing half a decision.

MCP’s job — an agent reaching for a capability

MCP’s job is vertical. It connects a single agent, downward, to the tools and data it needs: a filesystem, a database, a search index, a payments API. The agent sits on top; the capability sits below; MCP is the standardized call between them. The model decides it needs to read a file or run a query, and MCP is how that intent becomes an actual tool invocation with a typed result coming back.

This is the layer the agent boom standardized first — MCP is now the de facto tool-integration format across every major lab. But “won the standard” and “solved the problem” are different claims. MCP standardizes the conversation with a tool and deliberately leaves the operational layer alone: session affinity, scaling on concurrent connections, which agent may call which server, the audit trail. Our field notes on MCP in production walk the four gaps that open at scale; the short version is that a working MCP deployment is the protocol plus a wrapper that owns everything the protocol does not.

Hold onto one property of this layer: in MCP, the thing on the other end is a tool. It is not expected to plan, to hold a goal, to reason about a task across many turns. It has a typed input and a typed output and it does one discrete thing. That expectation is exactly what A2A’s job does not fit.

A2A’s job — one agent delegating to another

A2A’s job is horizontal. It connects agents to each other as peers: one agent discovering a second agent, handing it a task, and coordinating with it until the task is done — potentially across organizations, vendors, and frameworks that share no code and no infrastructure.

The unit of work makes the difference concrete. In MCP you call a tool and a value returns. In A2A you create a Task — and a Task is stateful, with a defined lifecycle: submitted, working, input-required, completed, failed. The remote agent can come back and ask for more input; it can stream partial progress; the work can take real time. You are not invoking a function. You are delegating a goal to something that will reason about it. That is the line between a tool and an agent, and it is the line between the two protocols.

A2A’s mechanics follow from “the counterparty is an autonomous peer you may never have met”:

• The Agent Card. Every A2A agent publishes a JSON document — by convention at /.well-known/agent-card.json — describing its identity, skills, service endpoint, authentication requirements, and an optional signature. It is how one agent learns what another can do before delegating anything: the agent-to-agent analogue of an OpenAPI document, not of an MCP tool list.
• Discovery with three modes. A2A defines discovery via the well-known URI for public agents, via curated registries for enterprise or marketplace settings, and via direct configuration for static, known relationships. An agent finds a peer the way a service finds a service.
• Opaque execution. A delegated agent runs the task without exposing its internal state, memory, or toolset to the caller. The caller sees a Task moving through its lifecycle, not the callee’s plan. Two competitors can interoperate without either showing the other its internals.
• Transport plurality. A2A binds to JSON-RPC 2.0, gRPC, and HTTP/REST, with streaming over server-sent events and asynchronous push notifications for long-running work — because agent-to-agent tasks are not all short request-response.

None of that is what a tool needs. All of it is what a delegated peer needs.

The layering — coordination above, tools below

Stack the two and the picture is clean. A2A is the coordination layer; MCP is the tool-access layer; they are not on the same shelf at all.

            ┌─────────────────────────────────────────┐
   A2A ───► │  Orchestrator agent                       │
 (agent ↔   │   discovers, delegates a Task, coordinates │
  agent)    └───────┬───────────────────────┬───────────┘
                    │ A2A Task              │ A2A Task
            ┌───────▼────────┐      ┌───────▼────────┐
            │  Research agent │      │  Booking agent  │
            └───────┬────────┘      └───────┬────────┘
   MCP ───►         │ MCP calls             │ MCP calls
 (agent ↔   ┌───────▼───────┐       ┌───────▼────────┐
  tool)     │ search · DB    │      │ payments · CRM  │
            │ MCP servers    │      │ MCP servers     │
            └────────────────┘      └─────────────────┘

Read it top to bottom. An orchestrator uses A2A to delegate a Task to a research agent and another to a booking agent — peers it discovered by their Agent Cards, possibly run by other teams or vendors. Each agent, internally, uses MCP to reach its own tools: the research agent calls a search server and a database server; the booking agent a payments server and a CRM server. A2A moves work between the boxes; MCP moves capability into each box. The orchestrator never sees the research agent’s MCP servers — that is opaque execution doing its job. The two protocols never touch the same wire.

This is why “which one wins” dissolves on contact with a real architecture. They are not contestants. They are two floors of the same building, and a multi-agent system spanning organizations needs the staircase and the wiring both.

The gray zone — when a remote agent could just be a tool

The clean stack has one genuinely blurry seam, and an honest post names it. A2A’s “remote agent” and MCP’s “remote tool” are both, mechanically, a thing your agent calls over HTTP and gets a result from. So when does a remote capability deserve to be an A2A agent rather than just another MCP server?

The deciding question is not the transport — it is whether the thing on the other end is expected to reason.

• Expose it as an MCP tool when the capability is discrete and deterministic in shape: convert this currency, geocode this address, run this query, fetch this document. Typed input, typed output, no goal of its own, no multi-turn negotiation. Wrapping that in A2A’s Task lifecycle is ceremony you will pay for in latency and complexity and never use.
• Expose it as an A2A agent when the counterparty is meant to plan: “research this company and tell me whether to engage them,” “book travel for this trip within this budget.” The work is open-ended, may need clarification mid-flight, may take minutes, and the callee decides how. That is a Task, not a tool call.

The honest caveat: the line moves, and reasonable architects place a capability differently — a summarization endpoint is a tool to one team and a “summarization agent” to another. The test that travels: if the only thing you ever do with the response is read a structured field out of it, you built a tool and should call it like one; if you delegate a goal and let the other side decide the path, you built an agent and A2A is what that relationship needs. When genuinely unsure, default to the MCP tool — it is the smaller commitment, and promoting a tool to an agent later is cheaper than discovering you wrapped a function call in a coordination protocol.

Identity has to span both layers

Here is the requirement that does not respect the layering, and it is the one most likely to bite. An agent calling an MCP tool and an agent delegating to an A2A peer both have to answer the same question — who is on the other end, and may I trust them — and neither protocol fully answers it for you.

On the MCP side, the production-gaps notes make the case: an agent without a verifiable identity cannot be governed, and “which servers may this agent open a session to” is an identity question pointed at your own fleet. On the A2A side the question is sharper, because the counterparty is not a tool you chose — it is a peer your agent discovered, possibly at runtime, possibly operated by someone you have no contract with. A2A leans on standard web security for the transport: the spec supports API keys, OAuth 2.0, mutual TLS, and OpenID Connect, and the Agent Card can be signed against tampering. That secures the channel and authenticates the endpoint. It does not, on its own, tell you whether the agent behind a freshly discovered Agent Card has a track record or is an impostor quoting impressive numbers.

That gap is exactly the one ERC-8004 was built to close: a portable, on-chain agent identity with a reputation layer, so a buyer agent can check who a seller agent is without a central directory mediating every introduction. A2A standardizes the conversation between two agents; ERC-8004 gives the agents durable identities to have that conversation as. They compose — most production stacks that take agent-to-agent trust seriously will run A2A for the protocol and an identity layer like ERC-8004 underneath it for the “should I trust this peer” question A2A deliberately leaves to the consumer.

The principle: identity is not a per-protocol concern you can solve twice, once for tools and once for agents. It is a property of the agent itself, and it has to be verifiable whether the agent is reaching down to a tool or sideways to a peer.

Do you need A2A at all yet — usually not

Now the question a hype-skeptical team should ask before any of this, and the answer the comparison posts skip: most systems shipping today do not need A2A.

A2A’s adoption is real and worth stating precisely, because precision is what keeps this honest. At its one-year mark in April 2026 the Linux Foundation reported the A2A project past 150 supporting organizations, up from roughly 50 launch partners, with a v1.0 stable specification, SDKs in five languages, and native integration in Azure AI Foundry, Amazon Bedrock AgentCore, and Google Cloud. That is a healthy, fast-moving standard with serious institutional weight. It is not evidence that your system needs it.

A2A earns its place when you have a genuine multi-agent problem: separate agents, owned or operated by different teams or different vendors, that must coordinate — and especially when they cross an organizational boundary, where there is no shared codebase to coordinate through and a protocol is the only option. That is a real and growing class of system. It is not most systems.

Most agent systems in production right now are a single agent — one planner, one model loop — calling a set of tools. That agent needs MCP and does not need A2A; adding A2A to it buys nothing but a protocol to maintain. Even many systems described as “multi-agent” are one process with several sub-agents sharing memory and a codebase — in-process orchestration handles those, and reaching for an inter-organizational protocol to connect two objects in the same runtime is just the framing error inverted, a coordination protocol where a function call would do.

The skeptical rule: adopt MCP now, because the moment your agent touches a tool you want the standard. Adopt A2A when you have two agents that genuinely cannot share a process — different owners, different infrastructure, a trust boundary between them. Until then it is a dependency you carry and do not use.

Building with both

When you do need both, build them as the two layers they are, not as one tangled thing:

• Keep the layers separate in code. A2A coordination logic and MCP tool-access logic are different modules with different concerns. An agent exposes an A2A interface to its peers and, separately, consumes MCP tools internally. Collapsing them produces an agent whose delegation logic and tool logic cannot be reasoned about or tested apart.
• Put a policy layer on both boundaries. MCP needs a broker for server allowlists, credential injection, and an audit log; A2A needs the equivalent for which peers an agent may delegate to and which it may accept Tasks from. Same discipline — authenticate, authorize, log — applied at both the horizontal and the vertical boundary.
• Make identity the shared substrate. One verifiable identity per agent, checked whether the agent is calling a tool or a peer. Do not build a trust model for MCP and a second, unrelated one for A2A.
• Treat a delegated A2A Task as failure-prone. A peer agent can stall, reject, or drop a Task mid-flight exactly as an MCP session can drop mid-call. The recovery contract — classify the failure, demand idempotency for anything with a side effect, bound the retry — is the same discipline the MCP production notes prescribe, applied one layer up.
• Default new capabilities to MCP tools. Promote a capability to a full A2A agent only when it genuinely needs to reason. The smaller commitment is the right starting point.

The whole confusion collapses into one sentence worth keeping. MCP is how an agent uses a tool; A2A is how an agent works with another agent. Different jobs, different layers — and the system that needs both is a system you build deliberately, not a contest you resolve by picking a winner.

Reading list

• The A2A protocol specification, including its explicit section on the relationship to MCP — read that section first; it settles the “versus” framing in a paragraph.
• Google’s announcement of donating A2A to the Linux Foundation — the origin, the governance move, and the vendor-neutrality argument.
• The Linux Foundation’s one-year A2A report — the adoption numbers, stated by the body that governs the protocol, so you can judge the momentum for yourself.
• Anthropic’s introduction of MCP — the other layer, framed by its authors, which makes the boundary between the two protocols easy to see.

Two protocols, two jobs. The only real mistake is believing you have to choose.