Multiple MCPClients connecting to one MCPServer over Streamable HTTP

[Thomas-Dimos]

Summary

I’m building a multi-user chat web app. For each user session I spawn an MCPClient and connect it to my MCPServer(typescript sdk) using Streamable HTTP as the transport.

I’ve read older issues/feature requests that recommend running one MCP server per client—but those discussions seem specific to SSE transport. I’m trying to understand whether the same constraint applies to Streamable HTTP, or if I’m misusing the transport.

Questions

Is one-server-per-client still required when using Streamable HTTP?

If yes, what’s the intended role of a transports Map keyed by session IDs in server examples/blog posts? (i.e., why maintain multiple transport entries if the server can’t handle parallel transports/sessions?)

If no, what is the correct pattern for handling multiple concurrent clients/sessions over Streamable HTTP to a single server instance?

[evalstate]

You are fine to use multiple Clients to one Streamable HTTP Server.

You can associate an Mcp-Session-Id with each incoming connection to manage per-Client state if you need to (mostly I expect that would be handled by identity).

[Thomas-Dimos]

You are fine to use multiple Clients to one Streamable HTTP Server.

You can associate an Mcp-Session-Id with each incoming connection to manage per-Client state if you need to (mostly I expect that would be handled by identity).

Yes, I’m doing exactly what the provided examples show. However, when a tool call comes from the first client, it isn’t routed back to that client. The second client that connects later works fine. The session ID is correct, and I’m using the proper transport (with the matching session ID) to handle the request. From what I’ve read, the issue seems to lie in the server, which can only connect to one transport at a time. Also, looking at the example here (https://github.com/modelcontextprotocol/typescript-sdk/blob/main/src/examples/server/simpleStreamableHttp.ts), a new server instance is created for each initialization request, so I think this is currently a limitation. The documentation also mentions a 1:1 connection between the client and the server, but the use of multiple transports in the code is a bit confusing.

[evalstate]

OK, I think if you can create a repo with a reproducible case that may help - or consult the code for the "Everything Server" [1] which I've just double-checked does handle multiple clients correctly:

[1] https://github.com/modelcontextprotocol/servers/tree/main/src/everything

[Thomas-Dimos]

OK, I think if you can create a repo with a reproducible case that may help - or consult the code for the "Everything Server" [1] which I've just double-checked does handle multiple clients correctly:

[1] https://github.com/modelcontextprotocol/servers/tree/main/src/everything

I checked the code from the "everything server" and I can see that a new server instance is being created for every new client that connects to it const { server, cleanup, startNotificationIntervals } = createServer(); so that's why it works. In my case a single server instance exists, multiple clients connect to the server and with the use of the different transports (one for each client) i am trying to handle the tool call. I will provide a repo that shows my case. Thanks for the replies!

[evalstate]

No worries. You might also want to check out the https://github.com/evalstate/hf-mcp-server for an example of both stateful (per-instance-server) and stateless deployment (server-per-request).

[Thomas-Dimos]

Here’s the repository I created to demonstrate my case: https://github.com/Thomas-Dimos/MCP. Instructions are included in the repository.