A2A vs MCP: Two Protocols, Two Problems, Zero Overlap
Engineers keep asking whether Anthropic's Model Context Protocol replaces Google's Agent2Agent, or vice versa. It's the wrong question.
A2A vs MCP: Two Protocols, Two Problems, Zero Overlap
Engineers keep asking whether Anthropic’s Model Context Protocol replaces Google’s Agent2Agent, or vice versa. It’s the wrong question. MCP standardises how a single agent reaches tools and data; A2A standardises how peer agents negotiate, delegate, and hand off tasks. Swapping one for the other breaks the design intent — and, in production, breaks the audit trail.
What each protocol actually does
MCP, published by Anthropic in November 2024, is a client-server contract: an agent (the client) opens a JSON-RPC channel to a server that exposes tools, resources, and prompts (Model Context Protocol specification). The unit of work is a tool call. The trust model is vertical: the agent trusts the server it connected to, nothing more.
A2A, released by Google in April 2025 and now stewarded by the Linux Foundation, is a peer contract between agents (A2A protocol overview). Each agent publishes an Agent Card describing its skills, authentication, and streaming modes. Tasks flow between agents as first-class objects with lifecycle states (submitted, working, input-required, completed).
{
"task_id": "t_9f2b",
"state": "input-required",
"from": "invoice-classifier@finance.local",
"to": "vat-validator@tax.local",
"artifacts": [{"kind": "file", "uri": "s3://inv/2026-04/8821.pdf"}]
}Different verbs, different failure modes, different security boundaries.
When to reach for which
Reach for MCP when the agent needs a Postgres query, a Jira ticket read, a filesystem write. Reach for A2A when a triage agent must delegate the classification of a suspicious payload to a malware-analysis agent owned by a different team — possibly a different tenant. The protocols compose: an A2A agent can, and often should, use MCP internally to touch its own tools. We cover the composition pattern in our routing benchmark for agent tool choice.
Why they aren’t interchangeable
Three properties diverge. First, identity: MCP assumes one client, one server; A2A carries agent identity across hops, which matters for GDPR Art. 30 records of processing (EDPB Guidelines 07/2020 on controller and processor concepts). Second, lifecycle: MCP calls are synchronous request-response; A2A tasks can suspend, request input, and resume days later. Third, threat surface: MCP prompt-injection lives inside tool outputs, while A2A opens cross-agent collusion patterns that ENISA has been tracking in its multi-agent AI security work (ENISA AI security topic hub). Our review of topology-first agent safety walks through where each surface breaks first.
For teams building under the EU AI Act’s high-risk provisions, this distinction becomes a logging requirement, not a stylistic choice (Regulation (EU) 2024/1689 Art. 12 on record-keeping).
The CAI position
We build every internal agent with both stacks live: MCP for tool reach, A2A for delegation across trust boundaries. Collapsing them into one transport saves a week of glue code and costs a year of forensics when something goes sideways. If you’re mid-decision on your orchestration layer, start with our Iris engineering notes on agent topology.