The MCP vs A2A question has a short answer: they operate at different layers of the stack, and most non-trivial agent systems will eventually use both. The longer answer explains why developers keep framing it as a choice, what each protocol actually does at the wire level, and where the real asymmetry lies. It turns out to be in the security track record, not the architecture.
MCP (Model Context Protocol) launched November 25, 2024, designed at Anthropic by David Soria Parra and Justin Spahr-Summers.1 A2A (Agent2Agent Protocol) launched April 9, 2025, by Google, with more than 50 technology partners at launch.2 Both use JSON-RPC 2.0 as the message encoding. Both are now governed by the Linux Foundation under the Agentic AI Foundation umbrella. The resemblance stops at the wire format.
What Each Protocol Actually Does
MCP is a client-server protocol for connecting an LLM application to external tools, APIs, and data sources. An MCP host (Claude Desktop, Cursor, VS Code with Copilot, a custom agent runtime) spawns MCP clients that each maintain a dedicated 1:1 connection to an MCP server.4 Servers expose three primitive types: Tools (callable functions the model can invoke), Resources (data sources the application can retrieve), and Prompts (reusable interaction templates the user controls). The host always initiates the connection. Servers are passive infrastructure with no opinion about what the LLM does with their output.
A2A is a task delegation protocol between agents that reason independently. An A2A client sends a task to an A2A server. That server might be a LangGraph workflow, a Google ADK agent, a CrewAI crew, or a hand-rolled Python process. It uses its own tools internally, runs for as long as the task requires, and returns structured artifacts when it finishes.5 The client never sees the server’s internal state, prompt chain, or tool configuration. Capability discovery happens out-of-band via Agent Cards: JSON documents served at /.well-known/agent-card.json that declare what the agent handles, what authentication it requires, and what input and output formats it accepts.
A2A’s own documentation makes the stack explicit: “An agentic application might primarily use A2A to communicate with other agents. Each individual agent internally uses MCP to interact with its specific tools and resources.”3
Shared Wire Format, Different Semantics
The identical wire format is not coincidental. JSON-RPC 2.0 is well-understood, library support exists in every major language, and it maps cleanly to request/response semantics without the conceptual overhead of REST’s resource-oriented conventions. Both protocols layer streaming on top via Server-Sent Events. Both commit to HTTP as the primary remote transport, though MCP also offers a stdio transport for local process-to-process communication that has no A2A equivalent and adds no network overhead.
The behavioral divergence is in what the server is permitted to be. MCP servers are infrastructure: deterministic given the same inputs, stateless between calls in the server-side sense, returning results in a single response. A2A servers are agents: they maintain their own reasoning loop, run for seconds to hours, and define task state explicitly in the protocol. The A2A v1.0.1 spec defines task lifecycle states including TASK_STATE_SUBMITTED, TASK_STATE_WORKING, and terminal states TASK_STATE_COMPLETED, TASK_STATE_FAILED, TASK_STATE_CANCELED, and TASK_STATE_REJECTED, along with interrupt states TASK_STATE_INPUT_REQUIRED (the remote agent needs more information from the caller) and TASK_STATE_AUTH_REQUIRED (the agent encountered an authorization boundary it cannot cross unilaterally).5
The programming model analogy is direct: MCP is a function call, bounded, scoped, returning a value synchronously in the RPC sense. A2A is a job submission, where the client hands off a task, subscribes to state updates via SSE or polling, and receives the artifact when the remote agent terminates the task.
The Security Track Record
MCP’s deployment history through mid-2026 is not clean. The protocol has accumulated 50+ known vulnerabilities across servers, clients, and infrastructure; 13 were rated critical.10 Three chained flaws in Anthropic’s own mcp-server-git reference implementation (CVE-2025-68143, CVE-2025-68144, CVE-2025-68145) created a path traversal to arbitrary file write to remote code execution chain. The mcp-server-filesystem reference implementation contributed two additional path traversal CVEs (CVE-2025-53109, CVE-2025-53110). Independent analysis found 24,008 unique secrets exposed in MCP-related configurations on public GitHub repositories, 2,117 of which were still valid at time of collection.10
The root cause is stated plainly in the MCP specification: “MCP itself cannot enforce these security principles at the protocol level.”6 Authentication, rate limiting, and access control are fully delegated to server implementors. OAuth 2.1 with PKCE is recommended but not required.
A2A launched with authentication declarations as a first-class protocol concept. Every A2A server must declare its supported security schemes in the Agent Card before any client interaction. Supported scheme types in the spec include API key, HTTP bearer, OAuth 2.0 flows (authorization code, client credentials, device code), OIDC, and mTLS.5 Agent Cards can carry JWS digital signatures for tamper-evidence; that capability was added in v0.3.0. The TASK_STATE_AUTH_REQUIRED state is an explicit acknowledgment that long-running tasks may hit authorization boundaries the initial request could not anticipate.
Neither protocol has solved cross-agent authorization. Which agents can delegate to which others, how credential scope propagates through multi-hop chains, and how revocation works across agent boundaries remain application-layer concerns in both specs. The local-host trust model that generated MCP’s spring 2026 CVE wave has no equivalent patch in A2A, but A2A’s stateful task model introduces its own attack surface: multi-turn session manipulation allows an attacker to refine prompt injections across successive task interactions in ways that MCP’s stateless tool-call model does not permit.
Adoption Asymmetry
MCP’s 18-month head start is visible in deployment breadth. The protocol’s Python and TypeScript SDKs draw tens of millions of monthly downloads by Anthropic’s stated figures,11 and the MCP server registry catalogs thousands of community-built integrations. Client support appears in Claude Desktop, Cursor, VS Code’s Copilot extension, Mastra, LangGraph, Goose, Postman, and dozens of other hosts. MCP was donated to the Linux Foundation in late 2025 under the Agentic AI Foundation, with OpenAI, Block, Microsoft, AWS, Cloudflare, and Google joining as supporting members.7
A2A is earlier in its adoption curve. Version 1.0.0 (the first stable release, with breaking changes from the 0.x series) shipped in early 2026, followed by v1.0.1 with HTTP binding fixes.9 The Linux Foundation’s one-year count placed participating organizations at 150+, with a steering committee that includes AWS, Cisco, Google, IBM, Microsoft, Salesforce, SAP, and ServiceNow.8 Cloud-platform support arrived quickly: AWS Bedrock AgentCore Runtime, Azure AI Foundry, and Google Cloud Agent Engine all ship native A2A support.8 The developer-side tooling ecosystem (agent registries, debugging proxies, hosted Agent Card directories) is thinner than MCP’s, reflecting the protocol’s younger deployment age rather than its adoption trajectory.
The competitive framing that characterized the first year after A2A’s release has been formally retired. Both protocols share a governing foundation, and the original Anthropic launch announcement for MCP predates A2A by five months; there was no competition to claim.79
Frameworks That Commit to Both
Every major agent framework now supports both protocols rather than picking one. LangGraph handles MCP tool loading natively and ships A2A adapters for cross-framework agent coordination. CrewAI and AutoGen added A2A for inter-agent communication while retaining their existing MCP integrations. Mastra supports bidirectional MCP: consuming external MCP servers and also exposing itself as an MCP server, making it reachable from any host that speaks the protocol.14 Google’s ADK, with A2A integration features made generally available in 2026, is the clearest production example of the dual-stack: ADK agents use MCP for internal tool access while A2A coordinates between agents and across third-party frameworks.13
A March 2026 taxonomy from the Google Developers Blog places MCP and A2A inside a six-protocol stack that also includes UCP (commerce transactions), AP2 (payments), A2UI (UI composition), and AG-UI (streaming UI events).12 The practical implication for most developers: start with MCP for tool access; add A2A when the remote endpoint makes independent decisions rather than processing requests. Whether a particular remote system is “infrastructure” or “an agent” is the question the architecture forces.
How to Choose
The operative question is: what is the remote endpoint? If it is deterministic infrastructure (a filesystem accessor, a database query interface, a REST API wrapper, a search index), MCP is the right choice. The ecosystem is wider, the server inventory is larger, and the operational profile is simpler. If the endpoint has its own reasoning loop, maintains state between calls, and might ask clarifying questions or seek authorization mid-task, A2A is appropriate.
Three concrete signals that A2A belongs in the architecture: tasks that span longer than a single request-response cycle; endpoints where capability discovery matters because the schema is not known in advance; and cross-organizational or cross-framework agent collaboration where sharing internal prompt design or tool configuration is not feasible.
The HN criticism about MCP context window overhead is real: loading a server’s tool list consumes prompt budget proportional to the number and description length of its tools. This is a client implementation problem that better MCP clients address through selective tool loading, not a protocol defect. A2A’s Agent Card discovery is out-of-band and has no equivalent cost. But MCP’s tool description poisoning problem is harder to route around: the spec explicitly labels tool annotations as “MUST be treated as untrusted unless from a trusted server,” a requirement that presupposes a mechanism for establishing server trust that MCP itself does not provide.
For most teams, the sequencing heuristic holds: start with MCP for context sharing and tool access, then add A2A when coordination between independently reasoning agents becomes the constraint. The choice is often sequential rather than architectural.
Asterisks
Several adoption figures in this article carry sourcing caveats. The monthly SDK download numbers reflect Anthropic’s stated figures and have not been independently verified against npm or PyPI raw counts.11 The “150+ organizations” figure from the Linux Foundation is a membership count, not a deployment count.8 A2A’s security record looks cleaner than MCP’s partly because A2A has been in production for a shorter period and has attracted less dedicated security research; the gap will narrow as A2A deployments scale.
No published benchmarks exist comparing MCP and A2A performance as of mid-2026. The arxiv survey of agent interoperability protocols by Ehtesham, Singh, Gupta, and Kumar explicitly flags this as a research gap across all four protocols in the space (MCP, ACP, A2A, and the emerging ANP).15 A direct latency comparison would be a category error in most architectures anyway: you would typically be measuring “MCP tool call plus A2A task delegation overhead” against “direct API call,” not MCP against A2A against each other. The protocols are not alternatives on the same call path.
Frequently Asked Questions
Can an A2A server use MCP internally?
Yes, and this is the intended design. A specialized agent exposes its capabilities to peers via A2A while using MCP servers to access the databases, APIs, and tools it needs to complete work. The protocols address different interaction scopes and do not conflict. Google’s ADK illustrates the pattern: ADK agents manage their own MCP tool connections internally and present themselves to other agents as A2A servers.13
Does MCP require using Anthropic’s products?
No. MCP is Apache 2.0 licensed and Linux Foundation governed.7 The MCP client support matrix includes OpenAI’s ChatGPT, VS Code with GitHub Copilot, and dozens of third-party hosts with no Anthropic affiliation.4 Anthropic originated the spec; it does not control the roadmap under Linux Foundation governance.
What happens to an A2A task if the server restarts mid-execution?
The A2A spec defines the task state model but does not mandate server-side durability. Task persistence is implementation-specific. AWS Bedrock AgentCore and similar managed runtimes handle crash recovery at the infrastructure layer, not the protocol layer.5 If you need durable task state for long-running jobs, pick a runtime that provides it rather than expecting the protocol to enforce it.
Is there a third protocol worth tracking?
ACP (Agent Communication Protocol), whose registry landed in JetBrains and Zed editors in 2026, targets multimodal and asynchronous agent messaging, a use case neither MCP nor A2A addresses well. The arxiv survey of agent interoperability protocols identified four distinct layers: MCP (tool access), ACP (async multimodal messaging), A2A (task delegation between reasoning agents), and ANP (decentralized peer discovery).15 ACP adoption is much smaller than either MCP or A2A, but IDE-level support from JetBrains and Zed accelerates the developer feedback loop considerably.
Why do both protocols use JSON-RPC 2.0?
JSON-RPC 2.0 has library support in every major language, a simple symmetric request/response semantic, and no dependency on a particular framework. Both protocols extend it with SSE streaming for long-running operations rather than modifying the base format. The shared choice was probably independent convergence on the same practical answer. Having a shared governing foundation now makes it realistic to build unified debugging proxies and inspection tooling that handles both protocols from a single wire tap.
