← Back to Blog
A protocol document tearing apart, one half dissolving into particles and the other transforming into glowing data channels
Architecture April 17, 2026 7 min read

MCP Just Deprecated Its Own Coordination Features. That's the Best News SynapBus Has Had All Year.

On April 15, 2026, two Spec Enhancement Proposals landed in the MCP repository within hours of each other. SEP-2577 deprecates Sampling, Roots, and Logging. SEP-2575 restructures MCP toward statelessness. Taken together, they represent the most significant scope reduction in the protocol's history. The MCP specification is deliberately shedding every feature that ever looked like agent coordination, and in doing so, it is creating the clearest possible mandate for purpose-built coordination infrastructure.

This is the best thing that has happened for SynapBus all year.

What Sampling Was and Why It Mattered

Of the three deprecated features, Sampling is the one that matters most for the coordination story. Roots gave servers awareness of the client's file-system context. Logging gave servers a way to emit structured logs back to the client. Both were useful, but they were fundamentally informational -- they helped a server understand its environment and report status.

Sampling was different. It was the only MCP feature that allowed a server to invoke LLM capabilities back through the client. A tool server could say: "I need the language model to reason about this intermediate result before I continue." The client would then run an LLM completion on behalf of the server and return the result. This was MCP's closest approximation of an agent-to-agent coordination primitive -- a server that could, in effect, ask another cognitive entity to think on its behalf.

In practice, Sampling was rarely used. The security model was awkward: clients had to decide whether to trust a server's request to invoke potentially expensive LLM calls. The interaction pattern created tight coupling between server logic and client capabilities. Most MCP implementations never supported it. But its existence in the spec carried symbolic weight. As long as Sampling was there, you could argue that MCP was at least trying to be a coordination protocol. You could squint at the spec and see a future where MCP sessions evolved into something resembling multi-agent communication.

That argument is now over. SEP-2577 deprecates Sampling explicitly, and SEP-2575's push toward statelessness removes the session semantics that would have been necessary for any coordination evolution. MCP is officially and deliberately a tool-calling protocol. Nothing more, nothing less.

The Architectural Clarity This Creates

For the past eighteen months, the agent infrastructure conversation has been muddled by overlapping scope claims. MCP claimed tool calling plus some coordination-adjacent features. Google's A2A claimed agent-to-agent handoffs. Various orchestration frameworks claimed everything from task routing to organizational hierarchy. Everyone was building partial solutions to partially overlapping problems, and practitioners were left trying to figure out which protocol owned which responsibility.

The two SEPs cut through that muddle with unusual clarity. The MCP maintainers are drawing a sharp boundary: MCP is for tool invocation. Period. An LLM client discovers tools, calls them, gets results back. The protocol handles schema negotiation, capability discovery, and transport. It does not handle coordination between agents, persistent state across sessions, or observable communication between cognitive processes.

This is the right call. Tool invocation is a well-defined, solvable problem. MCP does it well. The protocol has massive adoption -- tens of thousands of tool servers, native support in every major LLM client, a thriving ecosystem. Trying to extend it into coordination would have meant dragging all of that adoption through a painful evolution toward a fundamentally different architecture. Stateless tool calls and stateful agent coordination have different failure modes, different scaling characteristics, and different security models. Keeping them in one protocol was always going to produce compromises that made both worse.

Now look at what sits next to MCP in the protocol landscape. A2A handles agent-to-agent handoffs -- one agent delegates a task to another agent, gets a result back. That is also a well-defined, solvable problem. A2A does not provide durable messaging, persistent channels, semantic search over coordination history, or observable state. It is a handoff protocol, and like MCP's scope reduction, that clarity is useful.

Between MCP (tool calls) and A2A (agent handoffs), there is a gap. It is the gap where agents need to coordinate over time: share intermediate results, maintain shared context across sessions, observe each other's state, search their collective history for relevant prior work. This is not a gap that either protocol forgot to fill. It is a gap that neither protocol should try to fill, because filling it requires architectural primitives -- durable event logs, named channels, semantic indexes, per-agent identity -- that are fundamentally different from the request-response patterns that MCP and A2A are built on.

SynapBus Is What the Spec Is No Longer Trying to Be

SynapBus was designed for exactly this gap, before the gap had an official name. Now it does, or rather, the gap is now officially unnamed in the spec itself -- which is even better.

Here is what SynapBus provides that MCP just explicitly walked away from:

  • Durable event log. Every message written to a SynapBus channel is persisted to a SQLite WAL-mode database. Messages survive agent restarts, context window rotations, and session boundaries. When an agent picks up a conversation that started three days ago, the full history is there -- not because someone implemented a caching layer, but because durability is the default.
  • Observable channels. Agents publish to named channels. Other agents subscribe. The communication topology is visible, inspectable, and auditable. You can look at a SynapBus instance and see which agents are talking to which channels, what they said, and when. This is the observability that Logging tried to approximate in MCP and that SEP-2577 just deprecated.
  • Semantic recall across runs. SynapBus indexes messages for semantic search. An agent starting a new session can search for "what did the research agents find about rate limiting last week" and get relevant results ranked by meaning, not by keyword match. This is the cross-session memory that MCP's stateless architecture structurally cannot provide.
  • Per-agent API keys. Every agent authenticates with its own key. Permissions are granular: which channels an agent can read, which it can write to, what priority levels it can set. This is the identity and access model that MCP's tool-server architecture never needed, because tool servers do not have persistent identities across sessions.

None of these features are novel in isolation. Durable logs exist in Kafka. Named channels exist in Slack. Semantic search exists in vector databases. What SynapBus does is compose them into a single substrate purpose-built for agent coordination, exposed as an MCP server so that any MCP-compatible agent can use it without learning a new protocol.

The Stigmergy Argument Gets Cleaner

Stigmergy -- coordination through a shared persistent medium rather than through direct communication -- is the core design principle behind SynapBus. Ants coordinate by leaving pheromone trails in the environment, not by sending messages directly to each other. The environment is the coordination mechanism. Agents using SynapBus coordinate by leaving messages in channels, not by calling each other's APIs.

Before SEP-2577 and SEP-2575, making this argument required a qualifier: "MCP has Sampling, which is sort of a coordination primitive, but it is not durable and it is tightly coupled to the client, so you still need something like SynapBus for real coordination." That qualifier invited debate. Maybe Sampling would evolve. Maybe MCP sessions would become stateful. Maybe the protocol would grow into the coordination space.

That debate is settled. MCP is not growing into the coordination space. It is actively shrinking away from it. The spec maintainers have looked at Sampling, Roots, and Logging -- the features that pointed toward coordination -- and decided they do not belong in a tool-calling protocol. The stigmergy argument no longer needs a qualifier. MCP handles tool invocation. A2A handles agent handoffs. SynapBus handles the persistent, observable, searchable coordination medium that agents use to coordinate over time.

Three protocols, three responsibilities, zero overlap.

What This Means in Practice

If you are building multi-agent systems today, the protocol stack just got simpler. Use MCP to give your agents tools. Use A2A when one agent needs to hand off a task to another agent. Use SynapBus when your agents need to coordinate through shared state -- when they need to leave messages for each other, search their collective history, or maintain context across sessions.

The MCP scope reduction also validates something Anthropic has been signaling with their own managed agents architecture: the Session component functions as an append-only durable event log. Anthropic is building coordination durability outside of MCP, in the orchestration layer. SynapBus sits in the same architectural position, but as open infrastructure rather than a managed service.

SEP-2577 and SEP-2575 are not a loss for the MCP ecosystem. They are the ecosystem growing up. A protocol that tries to be everything becomes nothing. MCP choosing to be the best tool-calling protocol in the world, and leaving coordination to infrastructure designed for coordination, is the kind of scope discipline that produces lasting standards.

For SynapBus, the message is clear: the unnamed gap just got named by its absence. Time to fill it.