A2A vs MCP is not a winner-take-all choice. The Model Context Protocol (MCP) standardizes how a single agent reaches tools, databases, and APIs. Google's Agent2Agent (A2A) protocol standardizes how autonomous agents discover each other, delegate tasks, and coordinate long-running work. Google states A2A "complements" MCP rather than replacing it. 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. For most teams, the practical order is MCP first for tool access, then A2A when workflows span multiple agents or vendors.
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)
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
| Dimension | MCP (Model Context Protocol) | A2A (Agent2Agent) |
|---|---|---|
| Primary scope | Agent-to-tool and agent-to-data access | Agent-to-agent task delegation and collaboration |
| Origin / governance | Anthropic-originated; MCP steering + Linux Foundation path | Google-contributed; Linux Foundation Agentic AI ecosystem |
| Discovery | tools/list, resources/list, server capabilities | Agent Card (JSON metadata + endpoint), optional extended card after auth |
| Core unit of work | Tool call with typed arguments | Task with lifecycle, messages, and artifacts |
| Transport | stdio, Streamable HTTP (SSE for streaming) | HTTP(S), JSON-RPC 2.0, SSE; gRPC in v1.0 bindings |
| Session model (2026) | Stateless at protocol layer in 2026-07-28 RC | Task-stateful; async push notifications for long jobs |
| Auth direction | OAuth/OIDC alignment hardened in 2026 RC | Enterprise auth schemes declared on Agent Card |
| Typical deployment | MCP server per tool domain behind API gateway | A2A server per agent role; orchestrator as client |
| Maturity signal (June 2026) | RC locked May 21; final spec July 28, 2026 | Spec 1.0.0; GitHub repo 24,259 stars at fetch time |
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.
Can A2A and MCP be used together?
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.
Is A2A a replacement for MCP?
No. A2A addresses agent-to-agent task delegation, discovery, and collaboration. MCP addresses agent-to-tool execution and context retrieval. They operate at different layers. Choosing A2A does not eliminate the need for MCP (or another tool interface) inside each agent that performs work with external systems.
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.
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/google/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
