All Resources
R-42
Intelligence (AI)
A2A vs MCP: Two Protocols, Two Different Problems
MCP connects a model to tools and data; A2A connects agents to each other. They are complementary rather than competing — here is the boundary, and how to decide which you need.
PAR2 Labs
August 22, 2026
13 min
These two get compared as rivals and they are not. The Model Context Protocol standardises how one agent reaches tools, data and prompts. The Agent2Agent protocol standardises how separate agents — often built by different teams, on different stacks — discover and delegate to one another. Most real systems end up using both, at different layers.
01
The boundary, stated plainly
MCP is vertical: it sits between an agent and the capabilities it uses. A server exposes tools, resources and prompts; a client attaches them to a model's context. The unit of exchange is a capability invocation.
A2A is horizontal: it sits between agents that each have their own reasoning, their own tools, and often their own owner. An agent publishes what it can do, another discovers it and delegates a task. The unit of exchange is a task with a lifecycle.
Fig 1 — the deciding question is whether the far side reasons. A database, an API and a file store are tools. A colleague's agent that plans its own steps is a peer.
02
How to choose
Almost every decision reduces to two questions: does the far side reason, and do you control it? The answers place you in one quadrant and the protocol follows.
| Situation | Use | Why |
|---|---|---|
| Your agent needs your database, an API, or a file store | MCP | These are capabilities, not peers — a typed tool interface is the right shape |
| Your agent needs a capability another team already exposes as tools | MCP | Still a capability. Ownership does not change the shape of the interaction |
| Your agent must delegate an open-ended task to another team's agent | A2A | The far side plans its own steps and reports progress — that is a task, not a call |
| A long-running task needs status updates and possible human input | A2A | The task lifecycle is part of the protocol rather than something you invent |
| You are wiring one model to fifteen internal systems | MCP | This is exactly the N×M problem MCP exists to collapse |
| You are building a marketplace of independently-operated agents | A2A | Discovery and capability advertisement across trust boundaries |
The deciding question is whether the far side reasons. A database does not; a colleague's agent does.
03
Implementing either without regret
Both protocols are straightforward to adopt and easy to adopt badly. These steps are mostly about the boundaries you draw around them rather than the wire format itself.
01
Decide reasoning or not, in writing
TOOL
One sentence per integration
USE
Does the far side plan its own steps?
GET
The protocol, chosen
For each integration write: what it does, whether it decides anything, and who operates it. If it executes a defined operation, it is a tool. If it decides how to accomplish a goal, it is an agent.
Why: The commonest architectural mistake is wrapping a plain API as an agent, which adds a reasoning layer, latency and non-determinism to something that was deterministic and fast.
02
Design MCP tools as narrow, typed capabilities
TOOL
MCP server
USE
Explicit input schemas, meaningful descriptions
GET
Tools a model selects correctly
Expose a small number of specific tools rather than one general one. Write descriptions as decision rules, validate arguments against a schema server-side, and return structured errors the model can act on.
Why: Selection accuracy falls as the tool count rises and as descriptions blur. Ten precise tools outperform forty vague ones, and a structured error lets the model retry sensibly instead of guessing.
03
Authorise on the server, as the end user
TOOL
Your existing authorisation
USE
Per-call checks against the caller's identity
GET
No privilege escalation path
Carry the end user's identity through to the tool call and authorise every invocation against it. Never run tools under a shared service account with broader rights than the person who triggered them.
Why: A tool call is an API call the model chose to make. Running it with more authority than the user creates a privilege-escalation path with a natural-language front end.
04
For A2A, publish an honest capability description
TOOL
A2A agent card
USE
What it can do, what it needs, what it returns
GET
Discoverable, correctly-selected agents
Describe capabilities in terms of outcomes rather than implementation, state required inputs explicitly, and be specific about what the agent cannot do. Version the description.
Why: Another team's agent selects yours from that description alone. An optimistic advertisement produces delegations you cannot fulfil, and the failure surfaces far from its cause.
05
Treat a delegated task as long-running by default
TOOL
A2A task lifecycle
USE
Submitted, working, input-required, completed, failed
GET
A delegation that survives real durations
Model delegation as a task with explicit states and progress updates rather than a request-response call. Handle the input-required state properly — a remote agent may legitimately need a human decision to continue.
Why: Cross-agent work routinely takes minutes. A synchronous call shape forces timeouts, retries and duplicated work when the far side was progressing fine.
06
Instrument across the boundary
TOOL
OpenTelemetry
USE
Propagate trace context through tool and task calls
GET
One trace across agents and tools
Propagate trace context into MCP tool calls and A2A task delegations so a single trace spans the whole interaction, and record which tool or agent was selected for each step.
Why: Multi-agent failures are almost impossible to diagnose from logs alone. A single connected trace is what turns 'the agent did something odd' into a specific step you can inspect.
04
Mistakes worth avoiding
The protocols are young enough that convention is still forming, and most of the pain comes from using them at the wrong layer rather than from the specifications themselves.
Anti-patterns
01
Wrapping a deterministic API as an agent, adding reasoning, latency and variance to something that had none.
02
Exposing one giant do_everything tool, which the model then invokes with the wrong arguments.
03
Running tools under a service account with broader rights than the user who triggered them.
04
Treating A2A delegation as synchronous request-response, then fighting timeouts you created.
05
Advertising capabilities optimistically, so other teams delegate work you cannot complete.
06
No trace propagation across the boundary, leaving multi-agent failures undiagnosable.
05
Reference
Both specifications are readable in an afternoon and worth reading directly — the summaries circulating tend to blur exactly the distinction that matters.
Primary documentation
Model Context Protocol
Concepts, server and client implementations, and the tool/resource/prompt model.
MCP specification
The wire protocol, capability negotiation and transport details.
MCP on GitHub
Reference servers and SDKs across several languages.
Agent2Agent protocol
Agent cards, task lifecycle and the discovery model.
A2A on GitHub
Specification source, examples and SDKs.
Tool use
How tool definitions reach the model, underneath either protocol.
OpenTelemetry
Trace context propagation across process and organisational boundaries.
Key Takeaways
01
MCP is vertical — agent to tools. A2A is horizontal — agent to agent. Most systems use both.
02
If the far side has no reasoning of its own, it is a tool: use MCP and keep it deterministic.
03
Authorise every tool call as the end user, never under a shared service account.
04
Model A2A delegation as a long-running task with states, not as request-response.
PAR2 Labs · Intelligence (AI)
Work With Us