MCP vs A2A
These two are compared constantly and they are not competitors, which is the reason this page exists. MCP specifies how a host reaches a tool. A2A specifies how one agent hands work to another agent it does not own, and the A2A project frames the two as complementary: its docs put MCP at how an agent interacts with individual tools and resources, and A2A at how different agents collaborate. The axis is one question about the far end: is it a tool you call, or an agent you delegate to?
Pick A2A if the far end is somebody else's agent, with its own reasoning and its own tools, and the unit of work is a task that may take minutes rather than a call that returns. You get Agent Cards for discovery and a task lifecycle with explicit states. Stay on MCP if the far end is a tool, a database, a file system or a subprocess that should do exactly what it is told and return a result. Most production systems end up with both: A2A between agents, MCP underneath each of them.
Side by side
MCP vs A2A at a glance
| MCP | A2A | |
|---|---|---|
| Boundary it specifies | Host to server: one agent reaching a tool | Agent to agent: one agent delegating to another |
| Wire format | JSON-RPC 2.0, UTF-8, one binding | ✓ three bindings: JSON-RPC 2.0, gRPC, HTTP+JSON/REST |
| Transports | stdio and Streamable HTTP; HTTP+SSE deprecated in 2026-07-28 | HTTP, with streaming, webhook push notifications and polling |
| Discovery | server/discover, mandatory for servers since 2026-07-28; the official Registry is still labelled preview | Agent Cards, plus Signed Agent Cards for cryptographic identity since v1.0 |
| Unit of work | A tool call, request-scoped | ✓ a task with explicit states: submitted, working, input_required, completed, failed, canceled, rejected, auth_required |
| State | ✗ none. Stateless since 2026-07-28; you mint handles and pass them as ordinary tool arguments | multi-turn context and long-running tasks are in scope; multi-tenancy added in v1.0 |
| Authorization | Optional. Over HTTP: OAuth 2.1 resource server, RFC 9728 metadata, RFC 8707 resource indicators. Over stdio: credentials from the environment | Declared auth schemes: API keys, OAuth2, mTLS, OpenID Connect |
| Deliberately out of scope | Agent-to-agent delegation; sampling, roots and logging (all deprecated); stream resumability; a global tool namespace | Agent internals: collaborators never share thoughts, plans or tool implementations. And tool or data access, which is MCP's job |
| Custodian | MCP a Series of LF Projects, LLC, under the Agentic AI Foundation at the Linux Foundation since 2025-12-09 | Linux Foundation, donated by Google Cloud and hosted since June 2025; TSC members from AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP and ServiceNow |
| Licence | ✓ Apache-2.0 for spec and code, CC-BY-4.0 for docs | ✓ Apache-2.0 |
| Current version | Revision 2026-07-28, replacing 2025-11-25 | v1.0.0 on 2026-03-12; v1.0.1 on 2026-05-28 |
| Price | No price: it is a spec | No price: it is a spec |
| Best for | Giving one agent access to your tools, data and prompts | Handing a task to an agent across a team, org or vendor boundary |
Sources: A2A specification · A2A releases · MCP specification · MCP 2026-07-28 changelog. Compiled August 2026.
Where A2A wins
The far end reasons for itself
A tool call is an instruction. A task is a request to something that will decide how to do the work. A2A is built for the second case: agents collaborate without needing to share their internal thoughts, plans or tool implementations, and it is deliberately modality-agnostic and model-agnostic. MCP has no vocabulary for any of that, because a server is not supposed to have opinions. Trying to expose someone else's agent as an MCP tool means flattening an autonomous process into a function signature and losing every state it goes through.
Work that outlives a single request
A2A's task lifecycle is the part that has no MCP equivalent. States such as submitted, working, input_required and auth_required are in the specification, alongside artifact exchange, streaming, webhook push notifications and polling, so a delegated job can pause for a human, ask for credentials and resume. MCP moved the other way in 2026-07-28: it dropped protocol-level sessions and the initialize handshake, and removed stream resumability, so a dropped stream loses the in-flight request. Its own long-running-operations answer is now an opt-in extension, Tasks, negotiated through capabilities.extensions.
Identity across an organizational boundary
v1.0 added multi-tenancy and Signed Agent Cards, which is the piece you need when the agent you are calling belongs to another company. The Linux Foundation's press release of 2026-04-09 reports more than 150 participating organizations, with Microsoft integrating A2A into Azure AI Foundry and Copilot Studio and AWS adding support via Amazon Bedrock AgentCore Runtime. Read that carefully: the platform integrations are named and citable, but the release describes production deployments only by industry, such as supply chain, financial services, insurance and IT operations. Treat any logo wall of named enterprise users as unverified, and the participation count as the foundation's own figure.
Where MCP still wins
A2A has not rebuilt tool access and is not going to, because refusing to expose tool implementations is the point of its design. If what you need is for a model to read a row, write a file or call an internal endpoint, A2A offers nothing at all and MCP is the only one of the two in the conversation. This is why the pairing is not a migration: the two specs do not overlap enough to replace each other.
MCP also still owns the local case. A stdio server is a subprocess the client launches, framed as newline-delimited JSON-RPC over the standard streams, taking credentials from the environment, with the specification advising against OAuth there entirely. A2A is network-first and has no equivalent story for a tool that lives on the same machine as the user. The trade is that MCP's local model is also its worst security surface: the specification's own local-server section lists arbitrary code execution, no visibility, command obfuscation and data exfiltration as the risks, and puts mitigation on the client.
Running MCP and A2A together
The shape most systems converge on:
1. Inventory the far ends. Sort every integration into two piles: things that execute an instruction and return (tools) and things that decide how to do the work (agents). The sorting is the whole design decision; almost nothing sits in both piles.
2. Draw the boundary at the org edge. A2A earns its complexity where you do not own the other side. Inside one codebase, delegating between your own components over A2A buys discovery and lifecycle you could have written as function calls.
3. Keep MCP underneath. Each agent still needs tools, so the usual layout is A2A between agents and an MCP server per agent for its own data. Nothing in either spec conflicts; they are both JSON-RPC-friendly and both Apache-2.0.
4. What does not carry over. MCP's deprecated primitives have no A2A equivalents to migrate to: Roots becomes tool parameters or server configuration, Sampling becomes a direct call to an LLM provider API, and Logging becomes stderr or OpenTelemetry. Do not wait for A2A to absorb them.
Common questions
FAQ: MCP vs A2A
Can A2A replace MCP?
No. A2A specifies how one agent discovers another, hands it a task and tracks that task through a lifecycle. It says nothing about reaching a database, a file or an internal endpoint, and refusing to expose tool implementations is deliberate: A2A agents collaborate without sharing their internal thoughts, plans or tool implementations. The A2A project states the division itself, that MCP is for agent-to-tool communication and A2A is for agent-to-agent communication. If your far end executes an instruction and returns a result, it is a tool, and A2A has no layer for it.
Do I have to choose between MCP and A2A?
No, and most systems that need both use both. The common layout is A2A at the boundary between agents, often across a team, org or vendor line, with an MCP server under each agent giving it access to its own tools and data. Nothing in either specification conflicts: both are Apache-2.0, both are JSON-RPC-friendly, and A2A adds two more bindings in gRPC and HTTP+JSON. The design decision is not which protocol, it is which far ends are agents and which are tools.
Is A2A production-ready?
It reached v1.0.0 on 2026-03-12, with v1.0.1 on 2026-05-28 fixing HTTP binding preference and TaskStatus values and adding an extension mechanism. It is hosted by the Linux Foundation after Google Cloud donated it, with a Technical Steering Committee drawn from AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP and ServiceNow. The Linux Foundation's press release of 2026-04-09 reports more than 150 participating organizations and names platform support in Azure AI Foundry, Copilot Studio, Amazon Bedrock AgentCore Runtime and Google Cloud. Note what it does not name: production deployments are described by industry only, so any list of named enterprise users is unverified.