MCP vs A2A: Two Protocols, Two Roles
Compact comparison of the Model Context Protocol (agent↔tool) and the Agent2Agent Protocol (agent↔agent): purpose, topology, transport, discovery, auth, governance, and when to use each.
MCP and A2A are complementary open protocols that solve different problems in agentic systems. MCP connects an agent to tools and data. A2A connects agents to other agents. Confusing them is the most common protocol mistake in multi-agent architecture.
Key facts
- MCP sets up a client/server relationship so an agent can call out to tools, read resources, and use prompt templates, while A2A sets up a peer relationship where one agent hands off a task to another and waits for the result.
- MCP discovery runs through the official registry and client-vendor marketplaces; A2A discovery instead relies on a self-published Agent Card fetched from a well-known discovery endpoint on the agent's own domain.
- MCP requires OAuth 2.1 + PKCE for remote transport; A2A auth is declared per-agent via OpenAPI security schemes in the Agent Card.
- In production, agents typically communicate with each other over A2A for the inter-agent handoff, then each one separately uses MCP to reach whatever tools or data it personally needs.
- Confusing the two protocols — expecting MCP to handle inter-agent delegation, or A2A to handle tool access — is the most common architecture mistake.
What each protocol is for
MCP (Model Context Protocol) is a client/server protocol for connecting an AI model to external capabilities: tools (functions the model can call), resources (files, database rows, URLs it can read), and prompts (reusable instruction templates). The model is the client; the capability provider is the server. MCP standardises the wire format so a single agent can talk to any MCP-compliant tool without custom glue code.
A2A (Agent2Agent Protocol) is a peer protocol for one agent to delegate tasks to another agent. The delegating agent (client) does not know or care how the remote agent is built — it sends a task, receives streamed status updates, and gets a result. A2A standardises discovery (Agent Card), task lifecycle, and wire format so agents from different vendors interoperate without shared code.
Comparison table
| Dimension | MCP | A2A |
|---|---|---|
| Purpose | Agent ↔ tool / data / context | Agent ↔ agent task delegation |
| Topology | Client (host/agent) → server (tool) | Peer: client agent → server agent |
| Transport | stdio (local); Streamable HTTP (remote); HTTP+SSE (deprecated) | JSON-RPC, gRPC, or HTTP+JSON/REST — three functionally-equivalent bindings as of v1.0 (spec §§9-11) |
| Message format | JSON-RPC 2.0 | JSON-RPC 2.0 |
| Discovery | Registry at registry.modelcontextprotocol.io; client-vendor marketplaces | Agent Card at /.well-known/agent-card.json (self-hosted) |
| Auth | OAuth 2.1 + PKCE (mandatory for HTTP); stdio uses env credentials | OpenAPI 3.x Security Schemes declared in Agent Card |
| Governance | AAIF (Linux Foundation directed fund) — donated Dec 2025; co-founded by Anthropic, Block, OpenAI | Linux Foundation — donated Jun 2025; originated by Google |
| Stable version / date | 2025-11-25 (RC: 2026-07-28, stateless architecture) | v1.0 — released March 2026 (current v1.0.x; prior: v0.3) |
| License | MIT (spec + SDK) | Apache 2.0 |
| Adoption | Thousands of servers in the official registry; backed by AAIF members | 150+ organizations; adopters include AWS, Azure, Salesforce, SAP, ServiceNow |
Capabilities inside MCP
- Tools — functions the model invokes (read DB, call API, run code).
- Resources — read-only data the model can subscribe to (files, rows, live feeds).
- Prompts — named, parameterised prompt templates served by the server.
- Sampling — server requests the client to run an LLM inference on its behalf.
A2A core objects
- Agent Card (
/.well-known/agent-card.json) — JSON document describing the agent's name, endpoint, skills, auth requirements, and SLAs. v1.0 adds a cryptographic signature so callers can verify the card was issued by the domain owner. (older spec versions used agent.json) - Task — the unit of work; has a lifecycle (submitted → working → completed/failed).
- Message — the wire envelope; sent via
message/send; streaming viamessage/stream(Server-Sent Events).
How they compose in one stack
The standard pattern: agents talk to each other via A2A; each agent reaches its tools via MCP. This is not a convention — Microsoft Azure AI Foundry and Copilot Studio explicitly support both simultaneously (confirmed at Microsoft Build 2025).
Example flow:
- Orchestrator agent receives a task from a user.
- Orchestrator delegates a sub-task to a specialist agent via A2A (
message/send). - Specialist agent fetches context (CRM records, docs) via MCP tool calls.
- Specialist returns result to orchestrator via A2A streaming.
- Orchestrator synthesises and responds.
Each layer stays within its protocol: A2A for the inter-agent envelope, MCP for the tool/data layer inside each agent.
Common confusions
"MCP already does multi-agent — why A2A?" MCP's sampling capability lets a server request an LLM inference, but it does not define task lifecycle, agent discovery, or cross-organisational delegation. A2A fills that gap.
"A2A replaces MCP." No. They operate at different layers. A2A does not define how an agent accesses a database or calls a REST API; MCP does.
"They are competing standards." Neither spec mandates exclusivity. The reference implementations for Google ADK, AWS Strands, and Microsoft Agent Framework all use both.
"MCP is still just Anthropic's." No. MCP governance moved to the Agentic AI Foundation (AAIF) under the Linux Foundation on 2025-12-09. Anthropic remains a co-founder and active contributor but no longer controls the spec unilaterally.
What is emerging vs stable
- Stable: MCP 2025-11-25 spec; A2A v1.0, including all three of its protocol bindings — JSON-RPC, gRPC, and HTTP+JSON/REST — which the v1.0 spec (§§5.1, 9-11) requires to stay functionally equivalent (same operations/capabilities, semantically equivalent results, consistent protocol-specific error mapping) whenever an agent supports more than one; the composition pattern.
- Emerging: MCP RC 2026-07-28 (stateless architecture, MCP Apps, Tasks extension — final spec targeted late July 2026); A2A global agent registry (proposal only as of Jun 2026 — no canonical registry exists yet, unlike MCP's registry.modelcontextprotocol.io). Real-world usage share across A2A's three bindings (what fraction of deployed agents actually use gRPC vs. JSON-RPC vs. REST in production) could not be confirmed from any source found — the spec mandates behavioral equivalence, not adoption reporting; treat any claim about which binding dominates in practice as unverified.
Bottom line
Most production multi-agent systems need both protocols, not one instead of the other, because they govern different layers of the stack: A2A governs the agent-to-agent envelope (discovery via Agent Card, task lifecycle, delegation), while MCP governs the agent-to-tool/data layer inside each agent (tools, resources, prompts). The standard pattern above — orchestrator delegates via A2A, each agent then reaches its own tools via MCP — is already how Google ADK, AWS Strands, and Microsoft Agent Framework ship by default. Asking "MCP or A2A?" is the confusion this resource opened by naming: they solve different problems, so the real design question is which agent in your architecture needs which layer, not which protocol wins.
Getting started — verified free resources
- MCP spec (stable 2025-11-25): https://modelcontextprotocol.io/specification/2025-11-25
- MCP registry: https://registry.modelcontextprotocol.io/
- MCP reference servers: https://github.com/modelcontextprotocol/servers
- A2A spec (v1.0): https://a2a-protocol.org/latest/specification/
- A2A GitHub (spec + SDKs + samples): https://github.com/a2aproject/A2A
- MCP course (hands-on, free): https://huggingface.co/learn/mcp-course/