-
Notifications
You must be signed in to change notification settings - Fork 1.5k
Description
There are still three examples that don't create a fresh McpServer instance for every client/transport:
The rest of the examples correctly wrap the McpServer construction inside of a getServer function, to get a fresh McpServer for every Transport instance. Or they're STDIO examples, where this doesn't seem to matter.
#820 makes it sound like it's safe to reuse McpServer instances, but as clarified in #343, that PR only solved a particularly bad side-effect. It didn't eliminate the fact that there's a single _transport field that gets clobbered every time McpServer.connect is called.
#980 briefly seemed to give official blessing to McpServer sharing, removing guidance to "create a new instance of transport and server for each request," replacing it with guidance to "create a new transport for each request" instead. Thankfully the entire README has already been streamlined to defer to the examples, so that text no longer exists at all. But still, I mention it because it's an example of confusion that still persists.
Recommended solution:
- Update the three examples above.
- Explain in no uncertain terms, ideally in the README or docs, that McpServer is meant to be 1:1 for each Transport, and shouldn't be reused for multiple simultaneous clients.
- I'm less familiar with the STDIO details, so perhaps some elaboration on how STDIO differs from HTTP in this aspect would be useful as well. I suspect it doesn't matter for STDIO just because the client will kill the server as soon as it's done, so there'd never be a second client to worry about.