MCP Is the Best Protocol for Agent-to-Agent Communication

Every time someone tells me MCP solves agent-to-agent communication, I think about that one friend who insists their Swiss Army knife is a toolbox. It has a blade. It has a screwdriver. It even has that tiny thing nobody knows the purpose of. But you would not build a house with it.

If that sounds right to you, you are in good company. Also, it is wrong.

Quite often when I bring up agent-to-agent communication - in conversations with engineering teams, at conferences, online - the immediate response is "but does not MCP solve that?" It does not.

The pattern looks like this: take an agent, wrap it as an MCP server, and let another agent call it as a tool. The calling agent does not know - or care - that there is an LLM on the other end. It sends a request, gets a response. Teams do this with stateful MCP servers that maintain conversation history across calls, accumulating context and making decisions behind the scenes. From the outside, it looks like agent-to-agent. Architecturally, it is tool use with extra steps.

MCP was designed to solve a specific problem: how an AI agent connects to external systems. Your agent needs to query a database, call an API, read files, interact with a third-party service - MCP gives you a standardized way to do that. You see, AI is such a new concept that OpenAPI was not standard enough and we created its subset, MCP, and asked everyone to wrap their OpenAPIs with a more limited set of OpenAPIs. And along the way the industry set to innovate on the security aspect of MCP since the ones we had for OpenAPI apparently were not standard enough.

And then MCP won. Sort of. In the way that every standard "wins" when enough conference talks mention it. Every platform added support. Thousands of MCP servers appeared. If your landing page did not say "MCP compatible" you were invisible.

Then teams started actually using it at scale. Scalekit ran 75 head-to-head comparisons: MCP costs 10-32x more tokens than CLI equivalents for identical operations. CLI achieved 28% higher task completion and 33% better token efficiency. MCP had a 28% failure rate from connection timeouts; CLI had 100% success rate. In March 2026, Perplexity's CTO publicly announced they were dropping MCP in favor of APIs and CLIs - MCP was consuming up to 72% of the available context window before the agent processed a single user message. It turns out LLMs have been trained on millions of examples of Unix pipe chains. They know grep | sort | head. They have zero training data on MCP composition patterns.

Anthropic - MCP's creator - published an engineering post showing that having agents write code to call tools instead of loading tool definitions directly reduces context from 150,000 tokens to 2,000. A 98.7% reduction. Think about that: the company that built MCP built a pattern specifically to prevent MCP from destroying the context window. The industry is quietly moving toward agents that generate code on the fly, call CLIs directly, and load tool definitions progressively - because the "standard" way of doing it bloats the one resource that matters most.

So MCP did not even definitively win at tool integration, the thing it was actually designed for. And yet - it is still everyone's answer when you mention agent-to-agent.

Put an agent behind an MCP server. What can it do? It can answer when called. That is it. The MCP spec is explicit: the client initiates all communication, the server responds. An agent behind an MCP server cannot start a conversation. It cannot push information proactively. It cannot react to another agent's work unless someone polls it. Outside of an active client request, the server is silent.

"But you can make it stateful!" You can. Teams do. They maintain session state across calls, accumulate context, build conversation history on top of a protocol designed for stateless tool invocation. The MCP team themselves acknowledge this in their 2026 roadmap: stateful sessions "fight with load balancers and horizontal scaling requires workarounds." The foundation you are building on is one the protocol authors are actively trying to redesign.

Here is where we are: the tool protocol is not an agent protocol. The tool protocol itself is being challenged by agents that just write code. And every team that needs two agents to work together is building custom plumbing from scratch.

The question is not how to make MCP do agent-to-agent. It is what agent-to-agent infrastructure actually needs to look like from first principles. I will dig into that over the coming weeks.