MCP vs A2A: agent-to-tool, or agent-to-agent?

MCP (Model Context Protocol, Anthropic) standardizes how an agent connects to and calls tools and data sources — a database, a file system, a search API. It's a client-server protocol between an agent and a capability. A2A (Agent2Agent, originally Google, now Linux Foundation-hosted) standardizes how one autonomous agent discovers, delegates to, and exchanges results with another autonomous agent — potentially built by a different team or vendor entirely.

MCP and A2A aren't competing standards for the same job — a single agent commonly uses both at once. MCP is how that agent reaches its own capabilities (its "hands"): a weather API, a search index, a code sandbox. A2A is how it collaborates with entirely separate agents it doesn't control (its "voice" to peers): handing off a sub-task to a specialized agent and getting a result back, without needing to know how that agent works internally. Notably, the remote agent on the other end of an A2A connection might itself be built using MCP internally — the two protocols compose cleanly because they operate at different layers.

It's reasonable to ask why agent-to-agent collaboration didn't just get bolted onto MCP as another kind of "tool call" — the reason is that MCP's tool-call model is built around a specific shape: a synchronous-feeling, tightly-scoped capability with a fixed schema, where the caller expects a bounded, structured result. Agent-to-agent collaboration needs semantics that shape doesn't fit well: the remote agent is an opaque black box (you can't inspect its internal tool calls the way an MCP server exposes its schema), the task can be genuinely long-running (minutes to hours, not a single request-response), and the interaction may need to stream partial progress or ask clarifying questions mid-task — closer to how you'd delegate work to a competent colleague than how you'd call a function.

A2A's "agent card" discovery mechanism reflects this directly: instead of a fixed tool schema, an agent card advertises capabilities at a higher, more negotiable level — what kinds of tasks this agent can take on — because the exact steps it'll take to complete a task are up to its own internal reasoning, not something the caller specifies in advance the way a tool call's parameters are.

A "plan my trip" super-agent needs to check flight prices and look up weather forecasts — both are simple, well-defined capabilities with fixed inputs and outputs, so it reaches them via MCP: call the flight-search tool, call the weather tool, get structured results back, done. No ongoing reasoning is needed on the other end for either.

The same super-agent also needs to "negotiate a hotel refund for a cancelled booking with the hotel's support system" — this isn't a single tool call, it's a multi-turn, judgment-requiring task (read the cancellation policy, construct an argument, respond to counter-offers) that a specialized customer-service agent is built to handle end-to-end on its own. The super-agent delegates this whole task via A2A, hands over the relevant context, and waits for (or streams) a result — without needing to know or control how that agent conducts the negotiation internally. Using MCP for the first two capabilities and A2A for the delegated task isn't an inconsistency; it's each protocol doing the job it was actually built for.