McpServer can be connected only to one StreamableHTTPServerTransport

[MilanRiccardo03]

Is your feature request related to a problem? Please describe.
Currently an instance of MCP server can be connected only to an httpstreamable transport, resulting the others to overwrite the first one:

1. when I connect a client to the server for a specific MCP server, it handle the request creating a new transport and connecting the server to that transport.
2. Then another request by a different client for the same MCP server can be handled by a different transport and the MCP server is connected to that new transport
3. Another request from the first client will result in connection timeout, because the MCP server is now connected with to the transport that handles the second client

Describe the solution you'd like
It would be cool if an instance of MCP server could handle more than one transport, so that it can handle multiple sessions.

Describe alternatives you've considered
The workaround I'm using is to create a new mcp server for each transport, so for each client who connects to my service.

[chipgpt]

@MilanRiccardo03 I am currently creating a McpServer instance for each transport like you are. I'm curious to learn more about this approach. What would be the key benefits of using a shared McpServer instance?

[MilanRiccardo03]

@MilanRiccardo03 I am currently creating a McpServer instance for each transport like you are. I'm curious to learn more about this approach. What would be the key benefits of using a shared McpServer instance?

hi @chipgpt , the key benefit of using a shared McpServer instance would be the ability to persist the server state across multiple clients.
For example, if a user is connected from both a mobile app and a desktop client, a shared MCP server could maintain consistent state between them. With per-transport instances, each client has its own isolated state, which can make synchronization more complex. A shared instance would simplify this and also reduce the overhead of creating multiple server instances.

[chipgpt]

@MilanRiccardo03 Thanks for the explanation.

For example, if a user is connected from both a mobile app and a desktop client

How are you currently tying the mobile and desktop clients to the same state? Are you doing it per authenticated user?

With per-transport instances, each client has its own isolated state, which can make synchronization more complex. A shared instance would simplify this

It seems like it would be an easy way to share state within a single process, but would not be scalable beyond a single process, correct?

My 2 cents: I would not rely on 1:many server-to-transport relationship to manage shared state. I would keep using a 1:1 relationship and would store state in a redis-like cache layer that any server instance can initialize into. This will make your server horizontally scalable and more resilient to restarts.

That all being said, I don't think MCP is designed for multi-client states like you are doing. For example, let's say client A and client B are both connected to server instance A. If client A calls a tool that triggers a list_changed notification, would the expectation be that the notification is sent back to client A and client B?