"MCP or A2A?" is the wrong question. It's like asking whether to use HTTP or SMTP. They're both protocols, they both move data, they both involve servers, and picking one over the other is a category error. One connects an agent to a tool. The other connects an agent to another agent. Neither was built for the piece of the job that actually reaches a human: the artifact someone has to open, read, and push back on.
Search volume for the comparison keeps climbing because operators are shopping for a map of a stack nobody has drawn yet. The answer isn't to pick one. These sit in different slots, and once you see the slots, the third empty one is hard to unsee.
MCP gave agents a standard port for tools
MCP, the Model Context Protocol Anthropic published in late 2024, is an agent-to-tool protocol. A host application (Claude, ChatGPT, Cursor, VS Code) runs a client that connects to one or more servers. Each server exposes three things: resources (read-only data the agent can pull), tools (functions the agent can invoke), and prompts (templated workflows the host can offer to the user). The official analogy is USB-C for AI. One port, many peripherals, standard handshake.
It works because the problem it solves is narrow. Give an agent read-write access to your calendar. Expose your database as a resource. Wire up a search endpoint. Attach a code execution sandbox. The agent asks what's available, the server answers, the agent calls what it needs. The ecosystem has converged faster than anyone expected. Dozens of IDEs and chat clients support MCP, and public registries of servers grow weekly.
Multi-agent coordination? MCP has nothing to say about it. Nothing in the spec handles "agent A delegates a sub-task to agent B." Two MCP servers don't know about each other. The host is the orchestrator, and its worldview is limited to whatever tools it has access to right now. If what you want is one agent handing a stateful task to another agent, MCP isn't wrong for the job; it just isn't that job, and it doesn't pretend to be.
The narrowness is the feature. MCP stays small on purpose. Every attempt to stretch it toward agent-to-agent messaging runs into the same wall: the identity model assumes one host, many servers. Flip that topology and you're no longer solving the same problem.
A2A lets agents talk, but only to each other
A2A, short for Agent2Agent, is the something else. Built by Google, donated to the Linux Foundation, and aimed squarely at agent-to-agent communication. Every agent publishes an Agent Card describing who it is and what it can do. Another agent reads that card and opens a task. The two negotiate the task's lifecycle, trading messages and artifacts along the way. Stateful tasks over HTTPS, streaming for long-running work, SDKs in every language you'd expect. Framework boundaries (LangGraph, CrewAI, Semantic Kernel) stop being walls.
The A2A docs are unusually honest about the boundary. An entire topic page exists to explain that A2A and MCP are "distinct but highly complementary." MCP handles tools and resources with "well-defined, structured inputs and outputs" performing "specific, often stateless, functions." A2A handles autonomous systems that "reason, plan, use multiple tools, maintain state" and carry on "complex, multi-turn dialogues." Some overlap is possible (an A2A server could expose a few of its capabilities as MCP-compatible resources), but the real value is stateful collaboration between agents that don't need to share internals.
Where A2A fits: a CrewAI orchestrator handing a specialist task to a LangGraph agent running on a different team's infrastructure. A research agent pulling in a domain expert to answer a niche question. A buyer agent negotiating with a seller agent across organizational lines. This slot is real, and every multi-framework deployment eventually bumps into it.
A2A is not where humans live. The conversation happens between two agents. The artifacts moving across it are written for another agent to read, not for a person scrolling through a dashboard at 9am trying to figure out what got done overnight. Agent Cards enable discovery, but there's no primitive for "a human opens this and edits it." Tasks have lifecycles, sure, but the lifecycle belongs to the two agents. It isn't a reviewer's view. Squint at A2A hoping to get an operator surface out of it and you'll end up writing glue that scrapes task state and artifact streams to guess at what a human wants to see. Several teams have already shipped that glue, called it "the agent dashboard," and discovered they rebuilt a scrollback buffer.
The third layer is the operator's view
The third column isn't a protocol, and it can't be. The thing it standardizes isn't a message shape. It's a surface where an agent publishes something, a human sees it, comments on it, and the agent picks up those comments on its next cycle. Same object, versioned, durable, visible. Tokenrip is one implementation: the agent publishes an artifact at a shareable link, the operator comments inline, and those comments feed the agent's next version at the same URL.
This layer sits next to MCP and A2A rather than against them. An agent can lean on MCP to hit tools, A2A to hand work to a specialist, and a collaboration layer to publish the result for the operator to check. All three compose cleanly because they answer different questions.
The distinction worth drawing is coordination versus collaboration. Coordination is one operator, many agents, shared orchestrator context. That's the CrewAI and LangGraph slot, already crowded. Collaboration is multiple parties with independent contexts working on a shared object. That's the Google Docs slot, except with agents as first-class creators instead of add-ons bolted onto a tool built for humans. Protocols define message shapes between parties. A collaboration layer defines the object those parties both touch.
Three columns, three different jobs
| MCP | A2A | Collaboration layer | |
|---|---|---|---|
| What it connects | Agent ↔ Tool | Agent ↔ Agent | Agent ↔ Artifact ↔ Operator |
| Core primitive | Tool call, resource read | Agent Card, Task, Message | Shared artifact with a durable link |
| Who registers | Tool owner | Agent (via Agent Card) | Agent (by publishing) |
| State model | Stateful session, stateless calls | Stateful task lifecycle | Durable, versioned, long-lived |
| Transport shape | Tool calls over a standard channel | Stateful tasks over HTTP, with streaming | Publish, subscribe, comment |
| Governance | Anthropic + community | Linux Foundation (donated by Google) | Still forming — no standard yet |
| Best for | Giving an agent a capability it doesn't have | Delegating a task across agents or frameworks | Making agent output visible and reviewable |
| Not designed for | Multi-agent handoff | Exposing a calculator to an LLM | Replacing a tool registry or agent registry |
Rows matter more than columns. If your row is "my agent needs a new capability," that's MCP. If it's "my agent needs another agent to do a piece of work," that's A2A. If it's "I can't find what my agent made, and I can't give it feedback," you're in a different row entirely, and no protocol is going to fix it. The problem isn't a message format.
Pick by question, not by protocol
The common failure mode is picking a protocol first and reverse-engineering the question to match. A team reads the A2A press release, thinks "this solves agent stuff," and starts building operator tooling on top of A2A's task lifecycle. They end up piping task state into a custom dashboard, scraping artifacts out of the message stream, and writing glue that approximates versioning. A year later they've reinvented a collaboration layer, poorly, on top of an agent-to-agent substrate that was never meant to be one.
The other version of the mistake is just as common. A team needs agent-to-agent handoff and tries to fake it inside an MCP host by spinning up a second agent as an MCP server. It works for trivial cases, where the second agent really is a stateless tool. It breaks the moment that sub-agent has to maintain state, call back for clarification, or respond over minutes instead of seconds. MCP's stateless-tool assumption doesn't generalize to stateful collaboration.
A better approach is three questions, answered independently:
- Does my agent need access to a capability it doesn't have? If yes, MCP. Nothing else in the stack handles this as cleanly.
- Does my agent need another agent to do a piece of work? If yes, A2A. The alternative is hardcoding endpoints, which is exactly the problem A2A exists to fix.
- Does my operator need to see, review, and steer what the agent produces? If yes, that's a collaboration surface, not a protocol choice. Build one or adopt one.
None of these trade off against each other. Most production agent systems need all three answers. Treating them as a single protocol decision is how teams end up shipping the wrong thing in two of the three, then finding out six months later, when the operator dashboard has hardened around the wrong substrate.
Both protocols assume the other end is a machine
MCP assumes the other end is a tool. A2A assumes the other end is another agent. Neither was designed for the case that shows up in almost every production agent workflow: the other end is a person who has to look at what got made, decide whether it's right, and push something back. The industry has mostly treated that case as a UI problem to solve later. A dashboard somebody will ship. A chat interface somebody will polish.
It isn't a UI problem. It's the third protocol-adjacent layer, and the ecosystem has mostly skipped it. The teams that will ship agent systems people actually trust are the ones treating operator supervision as its own surface, with persistent artifacts, versioning, and comment threads. Not a chat scrollback with better styling.