Allow multiple instances of the Inspector to connect to the same MCP server #428
Conversation
…ue server tranpsort for each web app transport.
* In server/src/index.ts
- add serverTransports map
- remove backingServerTransport var
- in /mcp POST handler, when a new connection is being made
- create a server transport
- map the server transport using the session id from the web app connection
- pass serverTransport to the mcpProxy instead of backingServerTransport
- in /stdio GET handler, when a new connection is being made
- create a server transport
- map the server transport using the session id from the web app connection
- pass serverTransport to the mcpProxy instead of backingServerTransport
- in /sse GET handler, when a new connection is being made
- create a server transport
- map the server transport using the session id from the web app connection
- pass serverTransport to the mcpProxy instead of backingServerTransport
olaservo
left a comment
olaservo
left a comment
There was a problem hiding this comment.
Had a couple clarifying questions and suggestions. TBH the terminology and architecture sometimes throws me for a loop here, since almost everything involved is a 'server' or 'client' of some kind but not always referring to a MCP Server or Client.
|
@tadasant @evalstate - @olaservo has approved but if one or both of you could also give this a once over, it'd be nice. The companion PR for the Everything server is merged, so it can be used to test against since it now supports multiple connections properly. |
I'll have a look this evening. This is exactly the scenario I have been working with with 2 separate Servers this week. qq @cliffhall - does this one include the /delete on disconnect? |
cliff.mp4Hi Cliff -- initial impressions look good, this is the inspector connected 2* to to a Server which requests sampling and you can see the request pops up in the right inspector window 👍. I'll carry on testing. |
Excellent test, @evalstate |
@evalstate No, it doesn't, but after looking into it, I think it would be better handled in a separate PR. The client should send the DELETE when |
@evalstate There is now a draft PR #470 for handling the DELETE on disconnect, but since it is somewhat tangential to what's in this one, separating them seemed the wisest course. That one is a branch of this one, so after this one is merged, I'll take that one off draft status and we can get it reviewed and merged. |
3 participants
add serverTransports map
remove backingServerTransport var
in /mcp POST handler, when a new connection is being made
in /stdio GET handler, when a new connection is being made
in /sse GET handler, when a new connection is being made
Motivation and Context
Some servers are meant to share resources among multiple clients. The current version of the Inspector cannot manage this.
While it does require an appropriate implementation on the server itself, the proxy server for the Inspector also requires a few changes to support this properly. Currently, a single server transport is bound to every client transport, and that causes problems when new connections are made ore broken. Instead, each client transport needs to be paired with its own server transport.
How Has This Been Tested?
This video shows me first connecting to a properly implemented server with multiple instances of the current Inspector to demonstrate the problem, then with the changes in this PR to show how it should work.
In the video, I show connections using SSE, but I've also fixed the StreamableHttp handling as well.
Note that I have another PR for server-everything (now merged), which allows multiple connections, so that this capability is testable entirely with in-project assets.
Breaking Changes
Nope.
Types of changes
Checklist
Additional context