On second reconnection Inspector errors out

[janswist]

Describe the bug
I have an MCP server that is working locally with Claude Desktop. Now I attempted to make it remote - at first connection Inspector immediately connects and lists all the tools. When I click Reconnect I get Connection Error, is your MCP server running? (v. 0.8.1)

Despite error Express server didn't shut or anything. After I restart Express it's working again.

To Reproduce
Steps to reproduce the behavior:

1. Connect to MCP via SSE transport
2. List tools
3. Click Reconnect (or disconnect and connect again)

Expected behavior
To work as on the first time.

Logs
Console logs (v.0.8.0):

index-D8hlx_TY.js:17656 Failed to connect to MCP Server via the MCP Inspector Proxy: http://localhost:6277/sse?transportType=sse&url=http%3A%2F%2Flocalhost%3A3000%2Fsse: SseError: SSE error: Non-200 status code (500)
    at _eventSource.onerror (index-D8hlx_TY.js:17266:23)
    at EventSource.failConnection_fn (index-D8hlx_TY.js:16881:53)
    at index-D8hlx_TY.js:16723:74
connect @ index-D8hlx_TY.js:17656
await in connect

index-D8hlx_TY.js:17687 SseError: SSE error: Non-200 status code (500)
    at _eventSource.onerror (index-D8hlx_TY.js:17266:23)
    at EventSource.failConnection_fn (index-D8hlx_TY.js:16881:53)
    at index-D8hlx_TY.js:16723:74

Console.logs (v.0.8.1) - they changed slightly after updating Inspector:

index-D8hlx_TY.js:17624 
            
            
          GET http://localhost:6277/sse?transportType=sse&url=http%3A%2F%2Flocalhost%3A3000%2Fsse 500 (Internal Server Error)
fetch @ index-D8hlx_TY.js:17624
connect_fn @ index-D8hlx_TY.js:16851
EventSource @ index-D8hlx_TY.js:16772
(anonymous) @ index-D8hlx_TY.js:17250
_startOrAuth @ index-D8hlx_TY.js:17248
start @ index-D8hlx_TY.js:17306

index-D8hlx_TY.js:17656 Failed to connect to MCP Server via the MCP Inspector Proxy: http://localhost:6277/sse?transportType=sse&url=http%3A%2F%2Flocalhost%3A3000%2Fsse: SseError: SSE error: Non-200 status code (500)
    at _eventSource.onerror (index-D8hlx_TY.js:17266:23)
    at EventSource.failConnection_fn (index-D8hlx_TY.js:16881:53)
    at index-D8hlx_TY.js:16723:74
connect @ index-D8hlx_TY.js:17656
await in connect

index-D8hlx_TY.js:17687 SseError: SSE error: Non-200 status code (500)
    at _eventSource.onerror (index-D8hlx_TY.js:17266:23)
    at EventSource.failConnection_fn (index-D8hlx_TY.js:16881:53)
    at index-D8hlx_TY.js:16723:74

Express.js log:

Listening at port 3000
Error: Tool getLatestProfiles is already registered
    at McpServer.tool (file:///Users/janswist/Developer/my-mcp/node_modules/@modelcontextprotocol/sdk/dist/esm/server/mcp.js:286:19)
    at file:///Users/janswist/Developer/my-mcp/index-sse.js:33:10
    at Layer.handleRequest (/Users/janswist/Developer/my-mcp/node_modules/router/lib/layer.js:152:17)
    at next (/Users/janswist/Developer/my-mcp/node_modules/router/lib/route.js:157:13)
    at Route.dispatch (/Users/janswist/Developer/my-mcp/node_modules/router/lib/route.js:117:3)
    at handle (/Users/janswist/Developer/my-mcp/node_modules/router/index.js:435:11)
    at Layer.handleRequest (/Users/janswist/Developer/my-mcp/node_modules/router/lib/layer.js:152:17)
    at /Users/janswist/Developer/my-mcp/node_modules/router/index.js:295:15
    at processParams (/Users/janswist/Developer/my-mcp/node_modules/router/index.js:582:12)
    at next (/Users/janswist/Developer/my-mcp/node_modules/router/index.js:291:5)

Additional context
Maybe related to #250

[pulkitsharma07]

can confirm, was able to replicate.

[kavinkumar807]

@pulkitsharma07 shall I work on this?

[pulkitsharma07]

Don't have to ask me for permission 😄 , go for it..

[cliffhall]

Hey @kavinkumar807 I usually test the inspector with the server-everything server.

• I just tested by starting it, connecting with the inspector, then clicking reconnect.

• The server died, leading to the Connection Error, is your MCP server running? message.

• Started again, connected inspector, then did disconnect/connect, disconnect/connect over and over, and it works fine.

• The problem is in running the onConnect logic in the client again when Reconnect button is clicked. I don't think that's viable.

• When the server dies, this is the message. Not good.

[kavinkumar807]

@cliffhall started working on this, When the server dies, this is the message. Not good. yeah will improve this message as part of the PR

[cliffhall]

@cliffhall started working on this, When the server dies, this is the message. Not good. yeah will improve this message as part of the PR

@kavinkumar807 I didn't mean the message was bad or needed amending. Its that we are attempting to set headers after sending to the client. Some weeks ago I remember a discussion in a PR or issue (haven't been able to find since) that indicated that we were not allowing WWW-Authenticate headers to come back to the client and talk of sticking them in somewhere. This is what I think may be not good.

Also @janswist upgrade inspector to 0.8.2 and try it, please.

[kavinkumar807]

@cliffhall understood!

[cliffhall]

Also, follow the above steps to repro. With the 0.8.2 inspector.

I tried with two different servers, server-everything and my puzzlebox which have slightly different transport handling. Both
accepted multiple reconnections, issuing a new session id for each and kept running.

They only stopped with protocol.ts throwing not connected error after the sending a subsequent tool list request or resources request.

I believe this is because the call was coming on with an unconnected (previous) sessionId.

When the server gets a new /sse endpoint request as a result of the Reconnect button's click, it happily creates a new transport and sends you on your way to the /message endpoint for further interactions. But the client is not aware of this new connection and so your subsequent tool request goes out with the previous session id in the header. It has to disconnect before attempting to connect again.

I just fixed it. @kavinkumar807 Didn't mean to swoop this, I was already looking at it trying to rule out the server side. Ruling out the server led directly to the solution

[kavinkumar807]

@cliffhall No problem, Glad you’ve fixed it.
Thanks for sharing !

[janswist]

Also @janswist upgrade inspector to 0.8.2 and try it, please.

Unfortunately, the issue persists 😕

[cliffhall]

Also @janswist upgrade inspector to 0.8.2 and try it, please.

Unfortunately, the issue persists 😕

@janswist Subsequent to that suggestion, I fixed the issue. It will be available in a 0.8.3 release shortly after it has been merged. (see above)

[janswist]

I tried new 0.10.2 version of Inspector, but now I can't connect at all and there are no errors from the server as well

Here's the code of my MCP server: https://github.com/janswist/mcp-dexscreener/blob/main/index-sse.js and I run it with node index-sse.js

[cliffhall]

I tried new 0.10.2 version of Inspector, but now I can't connect at all and there are no errors from the server as well

Hi @janswist! I often am running the inspector from the project where I've built it locally.

To test this, I ran it from another project folder, invoking the 0.10.2 from npm. I ran my own sse sever to test it against, and I saw the same problem.

0.10.2 not connecting

Just for kicks, I tried incognito window and it connected.

0.10.2 connecting in incognito

So I cleared the application data with "Clear Site Data".

Clear storage for the app in Chrome devtools

Back in business

0.10.2 now connecting in normal browser tab

[janswist]

Hi @cliffhall thanks for sharing - it didn't worked for me unfortunately. Are you able to run my MCP server tho? It's like one file (the index-sse.js one). At this point I'm not sure if it's maybe something wrong with my code

[cliffhall]

Hi @cliffhall thanks for sharing - it didn't worked for me unfortunately. Are you able to run my MCP server tho? It's like one file (the index-sse.js one). At this point I'm not sure if it's maybe something wrong with my code

@janswist I would suggest testing it against our reference implementation: server-everything. Right now, you'll have to check that repo out, build server-everything, and run one of its scripts depending on transport type. When we get the next release out, you'll be able to just run it with npx and give it the transport type on the command line.

If it works against server-everything, then you can assume it's your server, and possibly the code in the reference implementation will give you a clue about what's going on.