MCP Connects Agents to Tools. A2A Connects Agents to Each Other. Here's Why That Distinction Matters.
These are genuinely different problems. And they now have genuinely different protocols.
MCP: the agent's hands
Model Context Protocol was released by Anthropic in November 2024 and donated to the Linux Foundation a year later. The simplest way to describe it: USB-C for AI. Before MCP, connecting an agent to an external tool meant writing custom integration code for every tool-agent combination. MCP replaces that with a standard interface. You build an MCP server for your tool once, and any MCP-compatible agent — Claude, ChatGPT, Gemini, Copilot — can use it without additional wiring.
By early 2026, MCP had crossed 97 million monthly SDK downloads and over 10,000 active public servers. OpenAI deprecated its Assistants API in favour of MCP. That's not a marginal adoption signal — that's the industry converging on a standard. If you're still writing bespoke tool-integration layers for your agents, you're accumulating technical debt that MCP already solved.
A2A: how agents talk to each other:
Agent-to-Agent protocol came from Google in April 2025 and was quickly handed to the Linux Foundation as well, with over 100 enterprise partners including Salesforce, SAP, Microsoft, and AWS. Where MCP handles the vertical connection between an agent and its tools, A2A handles the horizontal layer — agent to agent.
The core innovation is something called an Agent Card: a JSON document published at a standard endpoint that describes what an agent can do, what it expects, and how to authenticate with it. Discovery becomes automatic. An orchestrator agent can find a specialist, read its capabilities, delegate a task, and track progress through A2A's built-in task lifecycle — submitted, working, completed, failed — without any of that state management living in custom application code.
A useful analogy is a car repair shop. Each mechanic uses their own tools (MCP layer). But when one mechanic finishes the engine and needs the electrician to take over, that handoff — the communication, the task delegation, the status tracking — is the A2A layer.
The architecture pattern that's settling in production:
The combination is becoming standard: A2A for orchestration between agents, MCP for each agent's tool access. An orchestrator receives a goal, delegates sub-tasks via A2A to specialists, and each specialist independently uses MCP to access whatever it needs — a database, an API, a document store.
What's worth emphasising, though, is the common mistake this surfaces. Not every system needs both. Not every system needs multiple agents at all. A single agent with well-designed MCP tool access handles the majority of enterprise automation use cases cleanly. Multi-agent coordination via A2A earns its complexity when you have genuine reasons for specialisation across separate systems — different domains, different ownership, different failure boundaries. Adding agents to a system that doesn't need them makes it slower, more expensive, and harder to debug.
The protocols are mature. The judgment about when to use them is still the engineering challenge.