Multi-Tenant Client Support (Server-to-Server)

[mbleigh]

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

MCP is currently designed to favor single-tenant clients. That is, it works well if you have a dedicated device or VM for the client that can install and start up servers on demand. Servers are generally built with the assumption that a single client will be communicating with them.

This becomes a problem when we want to make MCP servers available to server-side agents that serve many users. An MCP server configuration (e.g. via command-line startup args) is a singleton, but it is both inefficient and impractical for server-side agents to spin up new MCP server processes for each user.

What is needed is the ability for MCP to provide server configuration such that each request can "reconfigure" the server for its needs.

Note: While this issue is related to the overall "statefulness" of MCP, it is not strictly an issue of statefulness/statelessness. Servers could remain stateful while supporting multi-tenant clients.

The Problem

Let's imagine an MCP server with specialized tools for managing GitHub issues. The tools are designed to always operate in the context of a single repository, e.g. searchIssues(query: string) only searches issues in the configured repository. When I start it up I do something like:

export GITHUB_ACCESS_TOKEN="...";
npx my-github-mcp-server myusername/myrepo

Fundamentally, this server acts as a simple proxy to the GitHub API by providing a tool. All it needs to properly function is an access token and a repo name. I'd argue that the majority of MCP servers in the wild today operate this way today -- most of their logic is stateless, the only "state" comes from the configuration at startup time.

If I'm building a desktop app that orchestrates MCP servers client-side, this is an acceptable state of affairs. But as soon as I'm building a server-side agent that serves many clients, this becomes an impossible bottleneck. I need to be able to spin up and execute potentially thousands of concurrent instances of the same MCP server, one per user, just to perform a simple API proxy operation with two input variables.

There needs to be a way to operate a single instance of an MCP server that can serve many clients. This is not simply a transport issue because even with HTTP transport, MCP servers are currently built to serve individual clients.

Proposed Solution

The base Request and Response interfaces could be enhanced to support multi-tenant clients universally in a way that is compatible with the current "stateful" connection between client and server:

export interface Request {
  method: string;
  params?: {
    _meta?: {
      clientId?: string; // if provided, uniquely identifies a specific user of a multi-tenant client
      clientConfig?: Record<string,unknown>; // configuration specific to this user
    };
    [key: string]: unknown;
  };
}

export interface Result {
  /**
   * This result property is reserved by the protocol to allow clients and servers to attach additional metadata to their responses.
   */
  _meta?: {
    clientId?: string; // the clientId from the request this result is fulfilling
  };
  [key: string]: unknown;
}

export interface ServerCapabilities {
  clientConfig?: {
    schema?: object; // (optional) valid JSON schema describing the accepted clientConfig
  }
}

This relatively simple change opens up multi-tenant clients in a backwards compatible manner. For a server implementor, they just need to take whatever configuration is passed at startup time and make it optionally provided through clientConfig instead.

If my GitHub MCP server from above implemented clientConfig, it would start up like so:

npx my-github-mcp-server # no config arguments

And when queried about its capabilities, it might respond with:

{
  clientConfig: {
    schema: {
      type: "object",
      properties: {
        githubAccessToken: {type: 'string', describe: 'required for private repo'},
        repo: {type: 'string'},
      },
      required: ["repo"],
    }
  }
}

Now when my multi-tenant client calls this MCP server, it can include user metadata:

{
  _meta: {
    clientId: currentUser.id,
    clientConfig: { 
      repo: currentSession.repo,
    }
  }
}

My server implementation will look at the client config for a particular request and adapt its behavior accordingly.

Secrets and Stored Values

The largest potential issue with the above proposal is the potential for proliferating sending sensitive credentials over the wire between MCP multi-tenant client and MCP server. Safety would be significantly enhanced if secrets could be passed either once per client or never at all.

I won't get into specific solutions for this to keep the discussion focused on multi-tenant client support at the more basic level, but there are a few ways this could be done:

1. Allow servers to indicate to the client that certain config values have been "stored".
2. Add explicit support for "secrets" that allow clients and servers to negotiate an out-of-band transfer mechanism.
3. Use public-key cryptography so that the client must encrypt secret values before sending them over the wire. The public key for signing secrets could be discoverable in the server capabilities.

Each of these solutions is more involved than the simple metadata additions proposed above, but for proper multi-client support one of these (or a better idea) would likely need to be pursued.

Conclusion

For MCP to become the universal protocol for adding capabilities to agents, it must evolve to support a multi-tenant client approach. Solving this well would open up a wide world for server-to-server MCP, both multi-tenant clients and multi-tenant servers (an MCP server that can server multi-tenant clients could also reasonably server many single-tenant clients from a hosted URL).

Looking forward to some discussion on the matter!

Scope

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

[GuillaumeDesforges]

In my humble opinion, this is one of the biggest limitations of the MCP.

I would need to be able to provide additional data to tools called that is not decided by the LLM, such as the identity of the user (email, account id, ...). Note that user authentication has already happened at this point, but tools might use this identity to perform some authorization.