Jerome Swannack’s talk at MCP Dev Summit North America 2026. TLDR: MCP servers can call tools, but clients cannot expose them back to servers. Jerome Swannack, one of MCP’s original architects, explains how client-to-server tool sharing could unlock more modular, pluggable MCP systems.
When Jerome Swannack was building MCP, he recognized a critical protocol gap that he calls “second-order” MCP servers. A typical (or first-order) MCP server connects an AI client to a system of record to execute something, like reading content, posting content, or taking actions. A second-order server is different. Instead of connecting a client to an external system, it connects a client to its other MCP servers, operating on the MCP layer itself.
In practice, second-order servers show up around familiar problems. A research agent needs access to your Slack, email, calendar, and document MCP servers. A tool-search layer needs to decide which tools to show the model without flooding the context window. A code-mode server needs a runtime that can call tools programmatically. An attachment processor needs to move files between servers without base64-encoding documents into the prompt.
Pieces of this already exist in various clients, frameworks, and custom agent stacks. Or users might ask a browser-based AI tools to flip across tabs and collect data from different live web aps. However, the missing part is the MCP-native version – a standard way to package these capabilities as reusable servers that can compose with the rest of the ecosystem.
Why building second-order serversis painful today #
Take the agent server use case. You have an MCP client, a set of MCP servers, and an agent server you want to spin up to do research across them. The agent needs access to those other servers. The only ways to wire that up require spreading authentication tokens across multiple services, doing separate OAuth flows for each one, or embedding API keys directly into the agent server. Trust ends up distributed across the system rather than centralized, and the UX for the user is a sequence of auth prompts that make the whole process feel fragile and cumbersome. Automatic mode solves some of this but shifting the glue to the UX layer is not a scalable solution.
The code mode case offers similar challenges. To give a model a runtime that can call your other MCP tools programmatically, you end up replicating the same auth sprawl. The complexity that belongs in the client gets distributed across the servers instead.
The attachment case has its own pain. The informal standard that’s emerged is passing files as base64-encoded parameters in tool calls. This works, technically, but it inflates the context window and creates brittle, finicky integrations.
The primary friction across all three cases is the same. MCP today is asymmetric. Servers can be called but clients cannot.
What symmetric MCP would change #
In his talk, Jerome proposed to give MCP clients the ability to expose tool lists and accept tool calls from servers, the same way servers currently do for clients. With that in place, the client becomes a switchboard. An agent server doesn’t need tokens for every downstream MCP server. It makes tool calls, the client routes them to the right server, the client handles auth, and the results come back. The chain of trust stays centralized. The OAuth problem disappears because the client already has the credentials.
The code mode server gets simpler too. It exposes a run_code tool, the client routes any tool invocations from within that runtime to the appropriate servers, and you get pluggable programmatic tool calling without embedding a JavaScript or Linux VM into each client individually.
For attachments, the client can list files as resources directly accessible to servers, eliminating the base64 workaround entirely. To demonstrate his vision, Jerome built a Docker-based VM with CLI tools calling MCP servers over symmetric transport, with a permission UI where you could specify which servers each second-order server was allowed to reach. The agent server had access to code mode. Code mode had access to everything else. Essentially, this was a multi-agent, code-mode-enabled system built out of composable MCP servers, with the client doing the routing.
Why two-way MCP streets don’t exist yet #
he short answer is that MCP was built to solve a more immediate problem: connecting AI clients to external systems. Second-order servers were not the first priority.
Jerome did build an early prototype, but the protocol was not easy to extend in this direction at the time. That is part of why the newer MCP extension work matters. It gives developers more room to test patterns like this without forcing every idea into the core spec.
The harder issue is that symmetric MCP changes the role of the client. Today, the client mostly calls servers. In Jerome’s model, the client also becomes a router and permission layer. It decides which servers can call which other servers, where requests should go, and which credentials are allowed to be used.
That adds complexity. But Jerome’s point is that the complexity already exists. Without symmetry, it just gets pushed into the wrong places. Servers end up holding tokens they should not hold. Each agent or runtime rebuilds its own routing logic. File handling becomes ad hoc. Permissions become harder to audit.
A symmetric model does not remove all risk. A badly configured client could still expose too much. But it puts the trust boundary in one place instead of scattering it across a dozen services. That makes the system easier to reason about and easier to secure.
What becomes possible when second-order MCP is standardized #
Once the client is a routing layer, the MCP ecosystem can provide parts of what Andrej Karpathy described as the LLM OS without each client having to build everything from scratch. Tool search becomes a pluggable server. Retry logic and rate limiting become pluggable servers. Agent communication becomes something that emerges naturally from MCP servers that are also clients.This providest composability, the kind that Unix pipes gave shell users, where small tools with well-defined interfaces combine into things their authors didn’t specifically plan for. Stay tuned for upcoming MCP releases as this gap is likely to be filled in the near future, with the MCP Draft spec (RC 2026-07-28) already making significant architectural moves in that direction.
Jerome is a software engineer at Anthropic. The Agentic AI Foundation is the home of open agentic standards and open source infrastructure. To learn more about MCP and connect with engineers thinking through these problems, visit aaif.io, join the conversation in the AAIF Discord, or join us at an upcoming AAIF event.