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 privately

Each 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.

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.

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

"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

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 privately

Each 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.

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.

What A2A Solves That MCP Doesn't

Buscar en la documentación

What A2A Solves That MCP Doesn't