MCP vs A2A: Agent Tools vs Agent-to-Agent

MCP vs A2A is not a contest — they solve different problems and stack. MCP (Model Context Protocol, from Anthropic) connects one agent to tools, data, and prompts. A2A (Agent2Agent, originally from Google) connects separate agents to each other so they can delegate tasks. If you're picking one, you're probably asking the wrong question: nearly every production system starts with MCP, and adds A2A only when it genuinely has multiple independent agents that must coordinate.

This piece is for engineers deciding what to actually build. I'll draw the line between the two protocols, show where they overlap, and tell you what to skip so you don't over-engineer a single-agent app into a distributed mess.

What MCP actually does

MCP is a client-server protocol for giving one agent access to tools and context. Your agent (the MCP client, e.g. Claude, Cursor, or your own app) talks to MCP servers that each expose tools, resources, and prompts. The agent stays in charge; the servers just answer.

The transport is deliberately boring. Roughly 90% of servers run locally over stdio — a subprocess on your machine, no network, no auth dance. Remote servers use HTTP (streamable HTTP or the older SSE). For example, MarkItDown MCP and Chrome DevTools MCP both run over stdio, while Graphiti MCP is HTTP and OpenMemory MCP uses SSE.

A typical MCP config is a few lines:

{
  "mcpServers": {
    "markitdown": {
      "command": "uvx",
      "args": ["markitdown-mcp"]
    }
  }
}

That's the whole model. If you're new to it, what is an MCP server covers the primitives in depth.

What A2A actually does

A2A is a protocol for one agent to hand work to another agent it doesn't control. Instead of exposing tools, an A2A agent publishes an Agent Card — a JSON document at a well-known URL describing its skills, endpoint, and auth. A client agent reads the card, then sends a task and streams back updates.

The key difference: an MCP server is a dumb pipe to a capability. An A2A agent is another decision-maker. It has its own model, its own tools (often its own MCP servers), and it can ask clarifying questions, run long jobs, and return structured artifacts.

A2A is HTTP-first and built for the network. There's no stdio equivalent, because the whole point is crossing a trust and ownership boundary — your billing agent calling a vendor's fraud agent, for instance.

MCP vs A2A: the side-by-side

The fastest way to internalize the split: MCP is vertical (agent to tool), A2A is horizontal (agent to agent).

	MCP	A2A
Connects	One agent → tools/data	Agent → agent
Other side is	A capability (dumb)	An agent (autonomous)
Discovery	Server lists tools	Agent Card (JSON)
Transport	stdio (~90%), HTTP	HTTP only
Runs locally	Usually	Rarely
Origin	Anthropic	Google
State	Mostly stateless calls	Long-running tasks
You reach for it	Almost always	Multi-agent, cross-org

Note the bottom row. MCP is table stakes for any tool-using agent. A2A earns its place only when you have real agent boundaries.

How they stack in one system

The two protocols compose cleanly: an A2A agent uses MCP internally to get its own tools. Picture a travel-planner agent that another agent calls over A2A. Inside, the planner is a normal MCP client — it loads a maps server, a calendar server, a browser server, and does its job.

So the layering is:

• A2A is the front door between agents (task delegation, negotiation, streaming results).
• MCP is the plumbing inside each agent (tools, memory, data access).

A concrete example: a research agent exposed via A2A might use Chrome DevTools MCP to drive a real browser, MarkItDown MCP to turn PDFs and Office docs into clean Markdown, and Graphiti MCP or OpenMemory MCP to keep memory across sessions. The caller never sees any of that — it just gets an answer. Browse the full MCP capabilities map to see what categories exist.

When to use which (and what to skip)

Default to MCP alone; add A2A only when you have genuinely separate agents. For 90% of what people build — a coding assistant, a support bot, an internal research tool — one agent plus a handful of MCP servers is the correct architecture. Reaching for A2A here adds network hops, auth, and failure modes for zero benefit.

Use MCP when:

• You need one agent to read files, hit APIs, drive a browser, or remember things.
• Everything runs under your control and you want low latency.

Add A2A when:

• You have distinct agents owned by different teams or vendors.
• Agents must delegate long-running tasks and negotiate, not just call a function.

What to skip: don't split one app into multiple A2A agents just because "multi-agent" sounds modern. And watch your tool budget — most clients start degrading past ~40 tools, so loading ten MCP servers into one agent hurts before A2A does. If you're already fighting that ceiling, curate hard first (see best MCP servers) rather than distributing prematurely. For the tool-vs-endpoint framing more broadly, MCP vs API is the companion read.