You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Streamable HTTP: header Mcp-Session-Id is not set for "notifications/initialized" request #905
Configure MCP Server supporting stateful Streamable MCP communication
Click on connect
See error: Connection Error - Check if your MCP server is running and proxy token is correct
Expected behavior
Send Mcp-Session-Id header in all requests after initialization, like spec requires: If an Mcp-Session-Id is returned by the server during initialization, clients using the Streamable HTTP transport MUST include it in the Mcp-Session-Id header on all of their subsequent HTTP requests.
Yep... I hit this issue as well. A quick look in the code appears to confirm the inspector will save the session ID away, but doesn't use it on any future requests.
I would also expect that disconnect would issue a request to delete the session.
In the hope this adds another clue, I'm seeing the same issue when the MCP server is remote. Same inspector session, same server code but run on localhost (same as the inspector) and the inspector does include the session id in requests so it works. This means in my situation there appears to be a problem when the inspector and the server are not on the same address.
I had the same issue, but then figured out my server was missing CORS header. Adding
Access-Control-Expose-Headers: Mcp-Session-Id
Made it work in mcp-inspector.
Reacted by Glen, Martin Kouba, Mark Zhu, MaYuanyuan, Ananthesh, Abhishek Moondra, Kamal Muradov, Guilherme Pagliarini, chris-ortiz, SunnyChopra and 3 more
Same issue with 0.21.1 once I upgraded to the 1.0.0 of the AspNet MCP libraries but adding in the Cors header support resolved it. i don't think is a bug in the tool, just an evolving requirement on the server side.
Thank you for reporting this, and apologies for the long wait for a response.
v1 will receive security fixes only — this issue describes a functionality, compatibility, or usability problem rather than a vulnerability, so it is being closed against v1. This is not a judgment on whether the problem is real — it's a consequence of the v1 line being frozen. This is happening as part of #1872.
If this still happens in v2, we'd genuinely like to know. v2 is a complete rewrite — three clients over a shared core — so many v1 behaviours no longer exist in the same form. Please open a fresh issue against v2 with steps to reproduce, and we'll look at it. Note that we accept external contributions as issues rather than pull requests; maintainers handle design and implementation through a prompt-driven workflow. See CONTRIBUTING.md.
Activity
zhaoyao commentedon Nov 11, 2025
I also encounter this issue. The server is implemented using spring-ai 1.1.0-RC1.
jvanhill commentedon Nov 12, 2025
Yep... I hit this issue as well. A quick look in the code appears to confirm the inspector will save the session ID away, but doesn't use it on any future requests.
I would also expect that disconnect would issue a request to delete the session.
bseddon commentedon Nov 14, 2025
In the hope this adds another clue, I'm seeing the same issue when the MCP server is remote. Same inspector session, same server code but run on localhost (same as the inspector) and the inspector does include the session id in requests so it works. This means in my situation there appears to be a problem when the inspector and the server are not on the same address.
DocX commentedon Nov 20, 2025
I had the same issue, but then figured out my server was missing CORS header. Adding
Made it work in mcp-inspector.
bseddon commentedon Nov 20, 2025
Great observation, thanks. Yes, it works when the header is added.
embesozzi commentedon Dec 18, 2025
Same error in v0.18.0
I can see the
mcp-session-idresponse header returned from the initial POST request when initializing the connection:However, the MCP Inspector does not send the mcp-session-id header when posting:
As a result, the MCP server returns a 400 error with the message "Session ID missing".
pbalint commentedon Feb 24, 2026
+1 for exposing the "Mcp-Session-Id"-header solving the issue, here's what worked for me:
AlbertoMonteiro commentedon Feb 26, 2026
Following @pbalint solution, in .NET I've did
daz10000 commentedon Feb 28, 2026
Same issue with 0.21.1 once I upgraded to the 1.0.0 of the AspNet MCP libraries but adding in the Cors header support resolved it. i don't think is a bug in the tool, just an evolving requirement on the server side.
pswarts commentedon Mar 24, 2026
It only works in "Via Proxy" mode and not in "Direct" mode
feat: self-hosted MCP gateway -- centralized container deployment (SP…
feat: self-hosted MCP gateway -- centralized container deployment (SP…
cliffhall commentedon Aug 1, 2026
Closing: v1 is deprecated.
Thank you for reporting this, and apologies for the long wait for a response.
v1 will receive security fixes only — this issue describes a functionality, compatibility, or usability problem rather than a vulnerability, so it is being closed against v1. This is not a judgment on whether the problem is real — it's a consequence of the v1 line being frozen. This is happening as part of #1872.
If this still happens in v2, we'd genuinely like to know. v2 is a complete rewrite — three clients over a shared core — so many v1 behaviours no longer exist in the same form. Please open a fresh issue against v2 with steps to reproduce, and we'll look at it. Note that we accept external contributions as issues rather than pull requests; maintainers handle design and implementation through a prompt-driven workflow. See
CONTRIBUTING.md.Thanks for taking the time to report it.