A2A vs MCP: Which Agent Protocol Should You Pick?

A2A vs MCP comes down to layer, not rivalry: reach for the Model Context Protocol (MCP) when a single agent needs governed access to tools, databases, and APIs, and add Google's Agent2Agent (A2A) when autonomous agents must discover each other, delegate tasks, and coordinate long-running work. Google states A2A "complements" MCP rather than replacing it, so most teams implement MCP first, then A2A when workflows span multiple agents or vendors. (Source: Google A2A Announcement) In May 2026 both stacks hit production milestones: MCP maintainers locked the 2026-07-28 stateless release candidate on May 21, and the A2A specification sits at version 1.0.0 with more than 24,000 GitHub stars on the reference repository.

Key takeaways:

• MCP is agent-to-tool: one agent calls standardized tools and resources on MCP servers.
• A2A is agent-to-agent: agents publish Agent Cards, exchange tasks, and return artifacts without exposing internal memory.
• Google positions them as complementary layers, not competing standards.
• MCP's 2026-07-28 RC removes the session handshake, making remote MCP servers easier to load-balance on plain HTTP.
• Default 2026 stack: MCP for capabilities inside each agent; A2A when an orchestrator delegates to remote specialists.

What changed in May 2026

Two protocol milestones landed within a week, which is why comparison queries spiked again.

On May 21, 2026, MCP maintainers locked the 2026-07-28 release candidate, with the final specification scheduled for July 28, 2026. The headline change is that MCP is now stateless at the protocol layer: the initialize/initialized handshake is removed, and the Mcp-Session-Id header goes away. A tool call becomes a single self-contained HTTP request that any server instance can handle, carrying client metadata in _meta instead of a persistent session. Gateways can route on Mcp-Method and Mcp-Name headers without parsing JSON bodies. (Source: MCP 2026-07-28 RC Blog)

Days later, the A2A project shipped v1.0.1 on GitHub (May 28, 2026) atop a 1.0.0 specification at a2a-protocol.org. That maturation matters for comparison shoppers: A2A is no longer a launch-day draft; it is a Linux Foundation-governed standard with JSON-RPC, gRPC, and HTTP/REST bindings. (Source: A2A GitHub)

Correction worth stating up front: A2A did not debut at Google I/O 2026. Google announced it on April 9, 2025, with more than 50 technology partners at launch. I/O 2026 renewed attention, but the primary launch date is documented on Google's developers blog. (Source: Google A2A Announcement)

A2A protocol vs MCP protocol: the 2026 state

Anyone comparing A2A vs MCP protocol today is looking at two moving specs, not two finished ones. Three details changed since the May RC that decide which one wins for a given job.

State handles replace hidden sessions. The 2026-07-28 MCP spec makes application state explicit: instead of a server-side session a client can't see, tool calls return a handle (for example basket_id) that the model reads, reasons about, and passes into the next call. That is a bigger deal for agent reliability than the stateless transport headline, because the model now has a citable pointer to its own progress instead of trusting an opaque session ID. (Source: MCP 2026-07-28 RC Blog)

Extensions are negotiated, not baked in. MCP capabilities like MCP Apps (sandboxed HTML interfaces) and Tasks (long-running work with handles) now ship as reverse-DNS-identified extensions with their own repos, versioning, and maintainers. A client and server negotiate which extensions both sides support via capability maps at connect time, so a gateway can support Tasks without also supporting MCP Apps. (Source: MCP 2026-07-28 RC Blog)

Authorization got sharper, not simpler. The RC tightens OAuth/OIDC for the common one-client-to-many-servers shape: localhost redirect URI handling, issuer validation, credential binding to a specific authorization server, and explicit token-refresh rules. Teams running MCP gateways in front of multiple backends should treat this as a required reading item before the final spec locks, not an optional upgrade. (Source: MCP 2026-07-28 RC Blog)

A2A is now a Linux Foundation project, not a Google-hosted repo. The a2aproject GitHub organization describes A2A as "an open source project hosted by The Linux Foundation," with community contributions accepted alongside Google's. The reference specification repository sits at 24,687 stars as of this writing, still on release v1.0.1 (May 28, 2026): governance moved, the spec version has not. (Source: A2A GitHub)

Operator note (first-hand): On 2026-07-08, a live fetch of github.com/a2aproject confirmed the Linux Foundation hosting language and the 24,687-star count on the main A2A repo; a separate fetch of github.com/a2aproject/A2A/releases confirmed the top release tag is still v1.0.1 (2026-05-28): no new spec version has shipped since the May maturation, only the governance move. (Source: A2A GitHub)

What MCP is and when it wins

MCP (Model Context Protocol) is an open standard, originally from Anthropic, for connecting an AI agent to external tools, resources, and prompts through MCP servers. The agent (client) discovers capabilities via tools/list, invokes functions with JSON Schema-typed arguments, and reads structured results. Transport options include stdio for local servers and Streamable HTTP for remote ones.

MCP wins when your problem is capability access, not cross-agent negotiation. Typical jobs: query a warehouse, file a ticket, run a SQL read, fetch a document, or call an internal REST API through a governed tool surface. If every integration point is "this agent needs a new tool," MCP is the right layer. Teams already rolling out MCP servers should read practical MCP implementation patterns before scaling horizontally. (Source: MCP 2026-07-28 RC Blog)

The May 2026 RC also matters for platform engineers. Stateless MCP removes sticky sessions and shared session stores from the protocol itself, so a remote MCP farm can sit behind a round-robin load balancer. Application state can still exist, but as explicit handles (for example a basket_id) passed in tool arguments rather than hidden transport metadata. (Source: MCP 2026-07-28 RC Blog)

What A2A is and when it wins

A2A (Agent2Agent) is Google's open protocol for communication between opaque agentic applications. An A2A client agent formulates work; a remote agent executes tasks and returns artifacts. Discovery happens through an Agent Card, a JSON document describing skills, endpoints, and authentication requirements. Tasks have a defined lifecycle and support long-running, human-in-the-loop flows with streaming updates over Server-Sent Events.

A2A wins when agents must collaborate as peers, not when one model simply calls a tool. Examples: a hiring orchestrator delegating candidate search to a sourcing agent, then handoff to a scheduling agent; a planning agent routing subtasks to domain specialists built by different vendors; cross-company delegation where neither side exposes internal prompts or tool implementations.

Google's launch post is explicit about layering: "A2A is an open protocol that complements Anthropic's Model Context Protocol (MCP), which provides helpful tools and context to agents." That sentence should end most "versus" debates before they start. (Source: Google A2A Announcement)

The normative A2A specification (version 1.0.0) centers on Tasks, Messages, Parts, and Agent Cards, with bindings for JSON-RPC, gRPC, and REST. Agents coordinate on declared capabilities without sharing internal state, memory, or proprietary tools. (Source: A2A Protocol Specification)

A2A vs MCP at a glance

Use the table as a layer map, not a scorecard. (Sources: MCP 2026-07-28 RC Blog, A2A Protocol Specification, A2A GitHub)

How the protocols stack in production

Production multi-agent systems rarely choose one protocol. They compose them.

Picture an orchestrator agent that receives a user goal. It uses A2A to discover a finance Agent Card, delegate a forecast task, and stream status updates. The finance agent, running in another vendor's cloud, uses MCP internally to call a ledger tool, a spreadsheet export, and an approval workflow. The orchestrator never sees those MCP tools; it only sees the finance agent's task artifacts. The finance agent never exposes its chain-of-thought; it exposes A2A task states.

That split matches how Microsoft and others frame agent workflows with MCP inside each worker while coordination stays at the framework layer. See Microsoft Agent Framework 1.0 workflows with MCP for a concrete orchestration pattern on the MCP side of the stack. (Source: Google A2A Announcement)

Inference: most "A2A vs MCP" threads in forums describe an architecture gap, not a protocol fight. If your roadmap mentions "sub-agents" or "delegate to specialist," plan for both layers early even if you implement MCP first.

Decision rules for your team

Start with three questions.

Do you only need tools inside one agent runtime? Implement MCP. Wire stdio or remote HTTP servers, publish tools/list, and harden auth using the 2026 OAuth/OIDC SEPs. Skip A2A until another agent, not a human, must assign work programmatically.

Do multiple agents, possibly from different vendors, need to assign and track tasks? Add A2A. Publish an Agent Card, expose task APIs, and treat each remote agent as an opaque service boundary.

Do you operate MCP servers with shell access? Protocol choice does not remove execution risk. Review MCP stdio config and command execution risk before exposing local servers to hosted models. (Source: MCP 2026-07-28 RC Blog)

For platform owners, sequence work this way: stabilize MCP tool surfaces and remote HTTP scaling on the stateless RC, then introduce A2A delegation once you have two or more agent roles that must interoperate without custom JSON over ad hoc webhooks.

Operator note (first-hand): On 2026-06-13, a live fetch of https://github.com/google/A2A reported 24,259 stars and confirmed release v1.0.1 dated 2026-05-28. Separately, the MCP RC blog's stateless example shows a single POST /mcp with headers MCP-Protocol-Version: 2026-07-28, Mcp-Method: tools/call, and Mcp-Name: search, with no Mcp-Session-Id line. That matches the spec narrative that any instance can serve the call. (Sources: A2A GitHub, MCP 2026-07-28 RC Blog)

Evaluating protocol choices in 2026

Protocol specs are only half the decision. Teams also need eval and observability to know whether delegated tasks and tool calls stay on policy.

When you add A2A, instrument task state transitions and artifact delivery latencies, not just token counts. When you scale MCP, trace tools/call paths through gateways using the W3C Trace Context fields documented in the 2026 RC. AgenticWire's agent eval infrastructure guide for 2026 covers scorecards that apply regardless of which protocol carries the traffic.

Both ecosystems are also deprecating foot-guns: MCP's 2026 RC deprecates Roots, Sampling, and Logging as core features in favor of tool parameters and OpenTelemetry. A2A pushes capability declarations into Agent Cards so unsupported operations fail fast with typed errors. (Sources: MCP 2026-07-28 RC Blog, A2A Protocol Specification)

"The headline change is that MCP is now stateless at the protocol layer." That shift plus A2A's 1.0 specification makes 2026 the year teams stop hand-rolling bespoke agent webhooks and start publishing cards and tool catalogs instead.

FAQ

What is the difference between A2A and MCP?

MCP defines how one agent connects to tools, resources, and prompts on MCP servers using calls like tools/list and tools/call. A2A defines how separate agents discover each other through Agent Cards, delegate Tasks, exchange Messages, and return Artifacts. MCP is vertical integration to capabilities; A2A is horizontal collaboration between autonomous agents. Google documents them as complementary layers in the same stack.

How does A2A work with MCP?

Yes. The common pattern is A2A for inter-agent delegation and MCP inside each agent for tool access. Google's A2A announcement explicitly states the protocol complements MCP. An orchestrator agent delegates work via A2A while specialist agents call CRM, database, or search tools via MCP without exposing those tools upstream.

Should I implement MCP or A2A first?

Implement MCP first if your immediate need is tool and data access for a single agent or assistant. Add A2A when you must delegate tasks to remote agents, including agents built by other teams or vendors, and track long-running task state. Most production roadmaps start with MCP servers, then publish Agent Cards once multiple agent roles exist.

Can MCP replace A2A?

No, and the reverse is also false. MCP addresses agent-to-tool execution and context retrieval; A2A addresses agent-to-agent task delegation, discovery, and collaboration. They operate at different layers, and Google documents A2A as a protocol that complements MCP. Running MCP everywhere still leaves you hand-rolling delegation between separate agents.

What changed in MCP's 2026-07-28 release candidate?

MCP maintainers locked the RC on May 21, 2026, with the final spec due July 28, 2026. The protocol layer becomes stateless: the initialize handshake and Mcp-Session-Id header are removed. Requests carry protocol version and method/name headers for routing, and list responses include cache TTL metadata. Authorization, extensions, and a formal deprecation policy are also expanded.

How do agents discover capabilities in A2A vs MCP?

MCP servers advertise tools and resources through MCP methods such as tools/list and server capability discovery on connect (or server/discover in the RC). A2A agents publish an Agent Card JSON document describing skills, service endpoints, and authentication requirements; clients fetch the card before delegating tasks. Extended Agent Cards may reveal additional skills after authentication.

Which is better, A2A or MCP?

Neither is "better" in isolation; they solve different problems. MCP is better when the job is one agent calling tools, databases, or APIs. A2A is better when multiple autonomous agents, possibly from different vendors, need to discover each other and delegate tasks. Most production stacks run both: A2A for delegation between agents, MCP inside each agent for tool access. Picking one to the exclusion of the other usually signals the architecture question was not fully scoped.

When to use A2A vs MCP

Use MCP when a single agent needs governed access to tools, files, or data sources, which covers most assistants and single-agent automations. Use A2A when your system has two or more independent agents that must hand off tasks, track long-running work, or interoperate across vendor boundaries without sharing internal prompts or memory. If you are not sure yet, implement MCP first; add A2A only once a second agent role actually exists.

Related coverage

• MCP adoption accelerates: practical implementation guides
• Microsoft Agent Framework 1.0 workflows with MCP
• MCP stdio config and command execution risk
• Agent eval infrastructure in 2026

References

• A2A GitHub - https://github.com/a2aproject/A2A
• A2A Protocol Documentation - https://a2a-protocol.org
• A2A Protocol Specification - https://a2a-protocol.org/latest/specification/
• Google A2A Announcement - https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/
• MCP 2026-07-28 RC Blog - https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate
• Model Context Protocol - https://modelcontextprotocol.io