Inconsistent Streamable HTTP reconnect behavior between Inspector proxy and direct connection

[alexmercerpo]

Summary

Using the demo calculator app generated by npx frontmcp create, I’m seeing inconsistent reconnect behavior with Streamable HTTP in the official MCP Inspector depending on whether I connect:

• directly to the FrontMCP server
• or through the Inspector proxy

The main differences are around session termination (DELETE) and what happens when clicking Connect / Reconnect afterward.

Setup

Generated demo app from:

npx frontmcp create

Using Streamable HTTP with the official MCP Inspector.

Observed behavior

1) Direct connection to FrontMCP

From the HAR:

1. initialize succeeds and returns MCP-Session-Id
2. notifications/initialized returns 202
3. SSE listener GET opens successfully
4. logging/setLevel succeeds
5. DELETE returns 204
6. after that, Inspector sends another initialize with the old deleted MCP-Session-Id still attached
7. FrontMCP returns 404 Session not found
8. then Inspector retries with a fresh initialize without session ID
9. new session is created successfully

So in direct mode, it looks like the server deletes the session correctly, but the reconnect flow still tries once with the stale session ID before doing a clean init.

2) Proxy connection through MCP Inspector

From the HAR:

1. initialize succeeds and returns a session ID
2. notifications/initialized returns 202
3. logging/setLevel succeeds
4. DELETE returns 500
5. despite that, reconnect then starts a fresh session and succeeds

So with proxy mode, the reconnect flow eventually works, but the DELETE request itself fails with 500.

Why this looks inconsistent

The same server/setup behaves differently depending on whether Inspector is using proxy mode or direct mode:

• direct mode: DELETE returns 204, but reconnect briefly reuses the deleted session ID and gets 404
• proxy mode: DELETE returns 500, but reconnect still recovers

This makes it unclear whether:

• FrontMCP should handle session termination / reconnect differently for Inspector proxy traffic
• or the Inspector proxy/direct flows are not aligned in how they clear or reuse MCP-Session-Id

Expected behavior

Based on the MCP Streamable HTTP spec:

• clients that no longer need a session should send DELETE with MCP-Session-Id
• after session termination, requests with that session ID should return 404
• when a client receives 404 for a terminated session, it should start a new session by sending a new initialize without a session ID

Because of that, I would expect one consistent behavior:

Expected option A

• DELETE succeeds consistently (for example 204 or 405 if unsupported)
• reconnect clears the old session ID before sending a new initialize

Expected option B

• if Inspector intentionally retries once with the old session, the behavior should still be consistent between direct and proxy paths, and proxy should not return 500 for DELETE

Questions

1. Is DELETE 500 through the Inspector proxy expected here, or is that a FrontMCP interop bug?
2. Should FrontMCP do anything special to make reconnect behavior more compatible with Inspector proxy/direct modes?
3. Is there any case where FrontMCP expects a new initialize to arrive with the previous MCP-Session-Id after a successful DELETE?
4. Should proxy and direct Inspector flows both clear session state before reconnecting?

Reproduction

1. create the demo app with npx frontmcp create

2. run the server with Streamable HTTP

3. connect from official MCP Inspector

4. test both:

   • direct connection to the server
   • connection through Inspector proxy

5. click disconnect / reconnect (or connect again after session termination)

6. observe DELETE, initialize, and MCP-Session-Id behavior in network logs

Attachments

I attached 2 HAR files:

• frontmcp-reconnect-direct.har
• frontmcp-reconnect-proxy.har

Spec reference

https://modelcontextprotocol.io/specification/2025-11-25/basic/transports