What A2A Solves That MCP Doesn't
MCP and A2A both use familiar web plumbing (JSON-RPC-style messages, HTTP, streaming). They solve different seams in an agent stack.
MCP standardizes how a host connects to tools and context. A2A standardizes how independent agents discover each other, exchange tasks, and collaborate without sharing internals.
Summary
- Treat MCP as "USB for tools" and A2A as "HTTP for agents talking to agents." One is agent-to-capability packaging; the other is agent-to-agent task coordination across processes, teams, and vendors.
- Insight: Teams that force multi-agent handoffs through tool-shaped MCP wrappers re-invent discovery, long-running tasks, opaque peer execution, and cross-org auth without a shared task model.
- Key Concepts: Agent Card, client vs remote agent, Task / Message / Part / Artifact, opaque execution, streaming and push notifications, MCP tools/resources/prompts.
- When to Use This Model: Explaining why your multi-agent design needs a collaboration protocol, not more tools; choosing MCP-only vs MCP+A2A; reviewing architecture docs that conflate "plugin" with "peer agent."
- Limitations/Trade-offs: A2A does not replace tool access, model routing, or your internal orchestrator. MCP does not replace cross-agent discovery or long-running peer tasks. Spec versions evolve; verify method names and well-known paths at build.
- Related Topics: Agent Cards, A2A transport (HTTP + SSE + JSON-RPC 2.0), the wider stack (MCP, ACP, WebMCP), when to adopt A2A vs a custom handoff.
Foundations
Two different N×M problems
| Seam | Problem without a standard | What won / is emerging |
|---|---|---|
| Agent ↔ tools/data | Every host invents plugins; every integration rewrites per client | MCP (tools, resources, prompts) |
| Agent ↔ agent | Every multi-agent stack invents handoff JSON, status polling, and capability ads | A2A (Agent Cards, tasks, messages) |
MCP answers: "How does this agent use a filesystem, ticket system, or DB?"
A2A answers: "How does this agent delegate work to another agent it does not control?"
User
→ Host agent (your runtime)
├─ MCP clients → MCP servers (tools / resources / prompts)
└─ A2A client → remote A2A agents (tasks, messages, artifacts)You often want both. They are complementary, not competitors.
Opaque peers vs transparent tools
MCP tools are usually transparent to the host:
- The host lists schemas.
- The model chooses a tool name and arguments.
- The host authorizes and executes.
- Results return as structured observations.
A2A remote agents are opaque by design:
- You see declared skills and modalities on an Agent Card.
- You send messages and manage Tasks.
- You receive status updates, messages, and Artifacts.
- You do not get the remote agent's prompts, tools, memory, or internal plan.
That opacity is the point for cross-team and cross-vendor work. Peers collaborate on outcomes without merging codebases or leaking tool credentials.
What MCP already covers well
MCP is the right default when the "other side" is a capability package, not a peer reasoner:
- Read/write scoped systems of record
- Sandboxed code execution
- Shared prompt templates and resources
- Portable tool servers used by many hosts (IDE, chat, custom runtime)
See What MCP Standardizes and Why It Won the Tool-Connection Wars.
What A2A adds on the agent-to-agent seam
A2A's job is collaborative work between agents that may differ in framework, language, cloud, and owner:
- Discovery - publish an Agent Card (identity, endpoint, skills, auth, modalities).
- Negotiation - agree on input/output modes (text, files, structured data).
- Task lifecycle - create and track work that may run a long time.
- Messaging - exchange multi-part messages (text, file refs, data).
- Progress - stream updates (often SSE) or use push notifications / webhooks for disconnected clients.
- Results - return artifacts without sharing internal state.
That is a collaboration contract, not a tool schema list.
Mechanics & Interactions
Side-by-side: same user goal, different protocols
Goal: "Summarize last week's support tickets and draft a reply plan."
| Layer | MCP-shaped path | A2A-shaped path |
|---|---|---|
| Ticket access | Host calls MCP list_tickets / get_ticket tools | Support agent (or host) already has ticket tools; another agent never needs raw API keys |
| Planning | Single host agent reasons over tool results | Research agent tasks a specialized "support triage" agent |
| Long work | Host polls its own jobs or blocks the loop | Task IDs, streaming status, optional push when the remote agent finishes |
| Ownership | Host owns every side effect | Remote agent owns its tools; host owns the handoff policy |
If the second party is your own function behind a schema, use MCP or in-process tools. If the second party is another agent product or service, A2A (or a deliberate custom peer protocol) is the seam.
"Isn't a remote agent just a tool?"
You can wrap call_support_agent(prompt) as an MCP tool.
That works for demos and single-team glue.
It breaks down when you need:
| Need | Tool wrapper pain | A2A-oriented answer |
|---|---|---|
| Capability ads without hardcoding | Ad hoc descriptions in tool docs | Agent Card skills and metadata |
| Multi-turn negotiation with a peer | Fake "session_id" args on every tool | Messages + task state |
| Streaming partial artifacts | Custom SSE beside MCP | Built-in streaming task updates |
| Cross-org auth and opacity | Sharing tool credentials into your host | Peer endpoint + standard auth schemes on the card |
| Ecosystem of many remote agents | N custom tools | One client against many cards |
Tool wrappers also tempt hosts to treat peer agents like pure functions, which under-models failure, partial results, and human-in-the-loop delays inside the remote system.
Ownership split that keeps systems sane
| Concern | MCP | A2A | Still your product |
|---|---|---|---|
| Discover capabilities | list_tools / resources / prompts | Agent Card | Which peers/tools to allowlist |
| Invoke work | tools/call | Send message / manage task | Budgets, retries, kill switches |
| Side effects | MCP server process | Remote agent runtime | Least privilege and approvals |
| Context packaging | Resources, results | Messages, artifacts, context ids | What you put in the next model turn |
| Multi-agent topology | Not the job | Peer connectivity | Orchestrator vs mesh design |
Internal multi-agent systems that share one process may still use framework handoffs (LangGraph nodes, SDK handoffs) without A2A. A2A becomes compelling when agents are separately deployed or separately owned.
Complementary stack, not either/or
A production pattern looks like this:
Orchestrator agent
├─ MCP → internal docs search, CRM, sandbox
├─ A2A → partner "compliance review" agent
└─ A2A → cloud "research" agent
└─ that agent may use its own MCP tools privatelyEach remote A2A agent can run MCP underneath for its tools. Your host does not need those tools; it needs a task contract.
For the wider map (MCP, A2A, ACP, WebMCP), see The Broader Protocol Stack.
Advanced Considerations & Applications
When MCP alone is enough
| Situation | Why MCP (or in-process tools) wins |
|---|---|
| Single agent, many integrations | Tool catalog, not peer negotiation |
| Same team owns host and "specialists" in one runtime | Framework handoffs are simpler |
| Strict low latency local tools | stdio MCP or in-process functions |
| You only need schemas and results | No long-running peer task model required |
When A2A becomes the better seam
| Situation | Why A2A (or equivalent) wins |
|---|---|
| Agents from different vendors/clouds | Shared discovery + task semantics |
| Long-running work with progress | Streaming / push notification patterns |
| Opaque specialist services | Skills without exporting tools |
| Enterprise boundary between teams | Auth, audit, and endpoint separation |
| You want clients to pick peers dynamically | Agent Cards as machine-readable ads |
Mapping mistakes that create dual systems
Avoid inventing two half-standards:
- MCP for all peer calls and a private handoff JSON for the same peers.
- A2A for tool-like DB access where MCP (or OpenAPI) is the real need.
- Agent Cards that list every internal tool as a "skill" (leaks surface area).
- Treating task completion as "tool returned a string" with no lifecycle.
Prefer one clear boundary per dependency: tool server vs peer agent.
Trade-off table
| Approach | Strength | Weakness | Best fit |
|---|---|---|---|
| MCP only | Mature tool ecosystem, simple mental model | Weak peer/task semantics | Single host + many tools |
| Framework multi-agent (in-process) | Fast iteration, shared memory options | Not portable across orgs | One product, one deploy unit |
| Custom handoff HTTP JSON | Exact fit for two services | N×M if more peers appear | Two stable internal agents |
| A2A | Standard discovery + tasks across peers | Another protocol to operate | Cross-team / cross-cloud agents |
| A2A + MCP | Clear separation of seams | Two stacks to secure and observe | Serious multi-agent products |
Common Misconceptions
- "A2A replaces MCP." No. Different seams: peers vs tools.
- "MCP replaces multi-agent systems." MCP connects capabilities; topology is still your design.
- "Exposing an agent as one MCP tool is always enough." Fine for simple glue; weak for long tasks, streaming, and multi-vendor discovery.
- "A2A shares memory and tools between agents." Opaque execution is a guiding principle; you exchange messages and artifacts, not internals.
- "If both use JSON-RPC, they are the same protocol." Shared style of messages does not mean shared operations or data model.
- "Adopting A2A removes the need for an orchestrator." You still choose who initiates tasks, how budgets work, and when humans approve.
FAQs
What does A2A stand for?
Agent2Agent (often written Agent-to-Agent): an open protocol for communication between independent AI agents.
What does MCP stand for?
Model Context Protocol: an open standard for connecting AI applications to tools, resources, and prompt templates.
Can one product implement both?
Yes. Typical design: MCP for tools/context, A2A for remote peer agents.
Does A2A require Google Cloud?
No. A2A is an open protocol with multi-party interest. Cloud products may offer managed support; the protocol itself is not a single-cloud lock-in. Verify current cloud support at build.
Is every multi-agent LangGraph graph an A2A system?
No. In-process graphs use framework edges. A2A matters when agents are separate endpoints that speak the protocol.
Where do Agent Cards fit?
They are A2A's discovery document: identity, endpoint, skills, auth, and modality support. See Agent Cards.
Does MCP support long-running work?
Hosts can implement jobs around tools, but MCP's core model is capability invocation, not a shared multi-agent task lifecycle like A2A.
Should I convert all internal APIs to A2A agents?
No. Prefer MCP or ordinary APIs for systems of record. Promote something to an A2A agent when it reasons, owns tools, and should stay opaque.
How do auth and least privilege differ?
MCP: scope the server's tools and credentials. A2A: authenticate to the remote agent endpoint and constrain which skills/tasks clients may start. Both need host policy.
What about ACP and WebMCP?
They target other interoperability layers (agent communication variants and web-page capability exposure). See The Broader Protocol Stack.
Is A2A only for HTTP?
The common binding is HTTP with JSON-RPC 2.0 and SSE-style streaming. Specs may define additional bindings; verify current bindings at build. See A2A's Transport Layer.
When should we stay on a custom handoff protocol?
When you have two stable internal peers, no ecosystem pressure, and the custom scheme already covers task state. See When to Adopt A2A vs Build a Custom Handoff Protocol.
Does A2A standardize model choice?
No. Each agent picks its own models and tools. A2A standardizes how agents talk, not how they think.
Where should I go hands-on next?
Agent-to-Agent Protocols Basics for a first Agent Card and client walkthrough.
Related
- Agent-to-Agent Protocols Basics
- Agent Cards: How Agents Advertise Their Capabilities
- A2A's Transport Layer: HTTP, SSE, and JSON-RPC 2.0
- The Broader Protocol Stack: MCP, A2A, ACP, and WebMCP
- When to Adopt A2A vs Build a Custom Handoff Protocol
- What MCP Standardizes and Why It Won the Tool-Connection Wars
- Model Context Protocol Basics
- Context Handoff: Passing State Between Agents Cleanly
- Multi-Agent Handoff: Specialist Agents Passing Work to Each Other
Stack versions: Pins from the category manifest (verify at build): OpenRouter (~315+ models, July 2026 pricing/fees); LangGraph 1.0+; CrewAI 1.14+; Microsoft Agent Framework 1.0; Vercel AI SDK 6; Pydantic AI (latest); LlamaIndex (latest); OpenAI Agents SDK (latest + MCP); MCP (Linux Foundation governance); A2A (HTTP+SSE+JSON-RPC 2.0); Solana
@solana/web3.js+@solana/spl-token.