A2A vs MCP: Two Agent Protocols, Two Different Jobs
Engineering teams keep asking whether they should pick Anthropic's Model Context Protocol (MCP) or Google's Agent2Agent (A2A) for their multi-agent stack. The framing is wrong.
A2A vs MCP: Two Agent Protocols, Two Different Jobs
Engineering teams keep asking whether they should pick Anthropic’s Model Context Protocol (MCP) or Google’s Agent2Agent (A2A) for their multi-agent stack. The framing is wrong. As of Q3 2026 both specs are stable, both ship reference servers, and both solve problems the other cannot touch.
What each protocol actually does
MCP standardises how a single agent reaches tools, data, and prompts. The agent is the client; a filesystem, a Postgres, a Jira become MCP servers exposing typed capabilities (Anthropic MCP specification). Think of it as USB for LLMs: one plug, many peripherals, no per-vendor glue.
A2A standardises how agents talk to other agents. Each agent publishes an Agent Card describing skills, auth, and streaming support, then peers negotiate a task through structured messages and typed artifacts (Google A2A specification). The unit of exchange is a delegated task, not a tool call.
Different layer, different verbs. MCP calls resources/read, tools/call, prompts/get. A2A calls tasks/send, tasks/get, tasks/cancel. Interchange is not possible without wrapping one inside the other.
# agent-card.json (A2A)
name: "invoice-triage"
url: "https://agents.caitech.eu/invoice-triage"
skills:
- id: "classify_supplier_risk"
inputModes: ["text/plain", "application/pdf"]
outputModes: ["application/json"]
authentication:
schemes: ["oauth2"]
mcp_servers: # this agent uses MCP internally
- postgres://audit-db
- filesystem:///var/invoicesWhen to reach for which
Use MCP when the agent needs deterministic access to a bounded resource: a database, a signing service, a private API. Governance stays inside your perimeter, capabilities are typed, and audit is straightforward — patterns we cover in approval-driven automation.
Use A2A when work must cross agent boundaries: a triage agent asks a legal-review agent to sign off, or a finance agent delegates supplier scoring to a specialist model owned by another team. The protocol carries streaming updates, cancellation, and typed artifacts across trust domains.
Topology matters more than the model, a point our engineering pillar has argued since March.
Where teams get burned
Wrapping A2A inside MCP to “unify the stack” collapses the trust boundary. A prompt injection surfaced through a tool result now propagates as an authenticated agent instruction. NIST’s Generative AI Profile flags exactly this failure mode under control GV-1.3 (NIST AI 600-1). ENISA’s 2025 threat landscape notes the same class of cross-protocol confusion attacks against multi-agent deployments (ENISA Threat Landscape 2025).
The inverse — exposing MCP servers as A2A agents — is worse. You lose the typed schema, gain a natural-language surface, and every read becomes negotiable. OWASP’s LLM Top-10 lists this under LLM06 excessive agency (OWASP LLM Top-10 v2025).
The CAI position
We ship agents where MCP handles the inside and A2A handles the outside, with the boundary enforced by policy, not by convention. Agent Cards are signed. Tool grants are per-task, expiring, and logged to the same evidence store our network detection pipeline writes to. Two protocols, one audit trail.
If you are drafting the interop layer this quarter, our agentic architecture notes walk through the failure modes we have already paid for.