AI
Second-Order MCP Servers: Why They Don’t Exist
Swannack described MCP servers that could exist but do not. Agent servers would spin up sub-agents with access to the client’s other MCPs. Code mode servers would let the model call tools programmatically through a runtime. Attachment processors would handle files without base64 encoding. None of these are built because the current protocol makes them too hard to implement.
The Cursed Implementation Gap
Building those servers today spreads complexity everywhere. Authentication tokens must be shared across servers, forcing per-app OAuth flows. File uploads require base64 strings that bloat the context window. Tool selection for context reduction is duplicated in every client. The result is a fragmented ecosystem with poor composability.
Symmetric MCP: Clients Become Tool Providers
Swannack’s idea: let clients expose tools, resources, prompts, and sampling to MCP servers. The client becomes a switchboard that routes tool calls between servers. Trust centralizes in the client, eliminating token sprawl. Only four primitives need symmetry, and Swannack estimates that covers 90% of the value. A prototype implemented code mode and agent routing through a single client.
How Symmetry Unlocks the Missing Servers
With symmetry, an agent MCP server receives a list of tools from the client. When the agent calls a tool, the client routes it to the right backend. Code mode works the same way: a runtime server calls tools programmatically through the client. Attachment processors use resources instead of base64, mounted directly into the runtime or file system. Composability starts to resemble Unix pipes.
Why Symmetric MCP Is Not In the Protocol Yet
Swannack said the team was busy with other fires. Extending the protocol requires easier message type additions. The bidirectionality introduces scaling pain. But embedding a full runtime into every client is harder than building a switchboard. The alternative of spreading OAuth tokens across servers is less secure. Swannack believes symmetry makes clients more complex but the overall system simpler.
Q&A
What about SignalR? Swannack was not familiar; it is a proprietary Microsoft protocol for bidirectional streaming. ▶ Watch (18:24)
How does sampling interact with symmetric MCP? Sampling should be a pure inference API without agent awareness; tools are provided by the server, and symmetric MCP lets servers populate that list cleanly. ▶ Watch (19:07)
How many hops did the prototype chain? Two hops: the agent called a run‑code tool routed to the code mode server, and code mode invocations were routed back through the client to final MCP servers. ▶ Watch (21:22)
Notable Quotes
It’s kind of crazy that software is this easy to produce. Jerome Swannack · ▶ Watch (15:30)
We just don’t do these second order MCPS today because they’re too complex. Jerome Swannack · ▶ Watch (17:37)
You can really start composing stuff and kind of allowing the ecosystem to provide parts of this LLM OS. Jerome Swannack · ▶ Watch (12:10)
I think that symmetric MCP allows the MCP server to populate that list of tools in a very clean way. Jerome Swannack · ▶ Watch (20:23)
Key Takeaways
- Symmetric MCP lets clients expose tools to servers, enabling pluggable agent harnesses.
- It centralizes authentication in the client, replacing per-server OAuth flows.
- A prototype with two-hop routing showed composability similar to Unix pipes.
About the Speaker
Jerome Swannack is a member of technical staff at Anthropic. He was one of the first three engineers to work on MCP alongside David and Justin, handling most of the core AI plumbing for tool calling. Originally from New Zealand, he moved to London two years ago for Anthropic. Before AI, he built rockets in New Zealand.