Guidance for building servers that act as proxy clients to many servers

[ggoodman]

Pre-submission Checklist

• I have verified this would not be more appropriate as a feature request in a specific repository
• I have searched existing discussions to avoid duplicates

Your Idea

I think there is lots of potential for an MCP server to act as a single point of configuration for many other MCP servers. This would benefit apps looking to act as MCP clients as they could thereby offload all of this management logic to an MCP proxy app.

Here is a straw man for a CLI experience:

• mcp setup claude -- Install mcp run --scope claude as a binary in claude.json.
• mcp server search github -- Search the list of known MCP servers for ones that have the keyword, GitHub.
• mcp server install --scope claude @namespace/mcp-server -- Install an MCP server locally, scoped to claude.
• mcp server install @namespace2/mcp-server-2 -- Install another MCP server locally for all scopes (clients).
• mcp run --scope <scope> -- The entrypoint for the binary to act as a stdio MCP server.

Note

In a world where some form of local service discovery is added to the protocol (or becomes a community convention), step 1 might even be skipped. It would be enough to install the binary and have it start on login and listen in whatever way works with local service discovery.

This sort of UX would allow many clients to benefit from a single local experience for configuring LLM context providers. It would be a perfect place for users to authenticate themselves to 3rd party services without every MCP client needing to re-implement this logic over and over. It might even allow the protocol to remain agnostic to this sort of bearer credential. The protocol could limit itself to the mutual authentication between client and server.

Spec changes

To help support this sort of hypothetical setup, I think the spec might benefit from some extra level of namespacing. Here are some area that I can think of based on the parts of the spec I've interacted with:

1. Server InitializeResult -- This assumes that: 1) the Server is a single, homogenous entity; 2) that a single set of instructions can govern the entire server; and 3) that a single version of the protocol is adequate. Of these, I think (2) is the thing that is most likely going to be problematic. The server could act as a homogenous veneer over a heterogeneous set of other servers and could expose a single protocol version to its clients.
2. Named entities such as Prompt -- The protocol assumes that named entities live in a collision-free namespace. In an MCP proxy world, Tools, Prompts, and any other 'named' entities could have conflicting names between servers. This is also true today where multiple servers are free to declare the same tool. It's not clear how a client would resolve ambiguity in such a situation. A server could transparently add some namespacing or the protocol could be extended with some form of support.
3. list_changed notifications -- These notifications would invalidate the whole namespace when finer-grained invalidation might be more efficient. If a namespacing concept were to be introduced, these notifications could be augmented to limit their applicability to zero or more namespaces.

As I haven't implemented anywhere close to 100% of the spec, the above is almost certainly not an exhaustive list. But hopefully it offers some inspiration for some potential future directions in the spec.

Scope

• Protocol Specification
• SDK Features
• Documentation
• Developer Experience
• Other

[jspahrsummers]

Thanks for flagging this! These are great points to think about.

Regarding your specific list:

1. Server InitializeResult -- This assumes that: 1) the Server is a single, homogenous entity; 2) that a single set of instructions can govern the entire server; and 3) that a single version of the protocol is adequate. Of these, I think (2) is the thing that is most likely going to be problematic. The server could act as a homogenous veneer over a heterogeneous set of other servers and could expose a single protocol version to its clients.

Can you share more about the concern you think exists with (2)? If "instructions" refer to "how to use all the tools that the server provides" (for example), a server-of-servers seems like it could get most of the way by just naively concatenating the instructions from all its child servers. I'm curious if that seems inadequate, though!

2. Named entities such as Prompt -- The protocol assumes that named entities live in a collision-free namespace. In an MCP proxy world, Tools, Prompts, and any other 'named' entities could have conflicting names between servers. This is also true today where multiple servers are free to declare the same tool. It's not clear how a client would resolve ambiguity in such a situation. A server could transparently add some namespacing or the protocol could be extended with some form of support.

I think it's probably reasonable for clients to automatically namespace everything per-server (and this could apply to the server-of-servers with its children servers as well). There might be problems with this I'm not seeing, though. We certainly need to give more thought here.

3. list_changed notifications -- These notifications would invalidate the whole namespace when finer-grained invalidation might be more efficient. If a namespacing concept were to be introduced, these notifications could be augmented to limit their applicability to zero or more namespaces.

We probably want to extend these notifications to support delta updates regardless ("these things were added, these were deleted"), which might solve this problem too.

[ggoodman]

Can you share more about the concern you think exists with (2)? If "instructions" refer to "how to use all the tools that the server provides" (for example), a server-of-servers seems like it could get most of the way by just naively concatenating the instructions from all its child servers. I'm curious if that seems inadequate, though!

@jspahrsummers, I think it's not adequate because I envision the set of configured servers changing over time. Even within the life-cycle of a single session. Maybe the tool allows servers to be dynamically installed? In this case, the instructions will be invalidated and the server will have no mechanism to inform clients.

[ondrsh]

Servers acting as aggregators can work with the existing protocol by implementing their own namespacing. Some aggregators may not even want to expose their child servers directly; they can combine multiple low-level servers (e.g., filesystem, database) into a high-level, domain-specific API. The idea of having a server with the main purpose of reducing repeated logic in client applications is interesting, but I'd argue that libraries/SDKs are the ones that should take care of that. Very possible I'm missing something.

That said, building tree-like MCP applications does raise many questions. For example, imagine a leaf server requesting sampling from a root LLM through a few middle layers. It might help to have standard guidelines for forwarding requests and handling notifications, so each node doesn’t need to invent its own pass-through logic. Same goes for the other direction, i.e. notifying a downstream branch.

It's hard to speculate at this stage, we'll know more in a month or two when different patterns emerge.

[allenporter]

This sounds to me like a problem to solve at the discovery level. That is, say you have an server that exports a discovery endpoint like https://github.com/orgs/modelcontextprotocol/discussions/84 you can define separate MCP server endpoints for serving. That is, you can use http urls as the namespace.

I think you'll continue to run into a set of things that break when trying to treat separate MCP servers as a single server (e.g. oauth with a proxy of numerous MCP subservers with their own oauth endpoints for each subset of the server sounds complicated). This may be fine for aggregating simple public servers -- but when trying to generalize further there will probably continue to be a number of things like this where trying to add more isolation within the MCP protocol will be complex for clients to adopt.