Skip to content

Streamable HTTP: header Mcp-Session-Id is not set for "notifications/initialized" request #905

Closed as not planned

Description

@ashakirin

Inspector Version

  • 0.17.2

Describe the bug
Connect to MCP server supported Streamable HTTP transport.

  1. MCP Inspector sends initialization request { "method": "initialize", "params": { "protocolVersion": "2025-06-18", "capabilities": { "sampling": {}, "elicitation": {}, "roots": { "listChanged": true } }, "clientInfo": { "name": "inspector-client", "version": "0.17.2" } }, "jsonrpc": "2.0", "id": 0 }
  1. MCP Server responds with capabilities and sends Mcp-Session-Id in header:
    mcp-session-id d29151a7-b085-4e5d-b08e-258dde3c4ffa
    { "jsonrpc": "2.0", "id": 0, "result": { "protocolVersion": "2025-06-18", "capabilities": { "completions": {}, "logging": {}, "prompts": { "listChanged": true }, "resources": { "subscribe": false, "listChanged": true }, "tools": { "listChanged": true } }, "serverInfo": { "name": "mcp-server-weather-streamable", "version": "1.0.0" } } }
  2. Because of some reason, MCP Inspector doesn't send the Mcp-Session-Id header in next request, for initialize notifications:
    accept application/json, text/event-stream accept-encoding gzip, deflate, br, zstd accept-language en-US,en;q=0.9,de-DE;q=0.8,de;q=0.7,ru-RU;q=0.6,ru;q=0.5 authorization Bearer XXX connection keep-alive content-length 54 content-type application/json host localhost:8090 mcp-protocol-version 2025-06-18 origin http://localhost:6274 referer http://localhost:6274/ sec-ch-ua "Google Chrome";v="141", "Not?A_Brand";v="8", "Chromium";v="141" sec-ch-ua-mobile ?0 sec-ch-ua-platform "macOS" sec-fetch-dest empty sec-fetch-mode cors sec-fetch-site same-site user-agent Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/141.0.0.0 Safari/537.36

{method: "notifications/initialized", jsonrpc: "2.0"} jsonrpc : "2.0" method : "notifications/initialized"

To Reproduce

  1. Configure MCP Server supporting stateful Streamable MCP communication
  2. Click on connect
  3. 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.

  • OS: Mac OS
  • Browser Chrome
Image Image

Activity

  1. added
    bugSomething isn't working
    authIssues and PRs related to authorization
    on Nov 9, 2025
  2. zhaoyao commented on Nov 11, 2025

    @zhaoyao

    I also encounter this issue. The server is implemented using spring-ai 1.1.0-RC1.

    spring:
      ai:
        mcp:
          server:
            type: ASYNC
            protocol: STREAMABLE
            streamable-http:
              mcp-endpoint: /mcp
  3. jvanhill commented on Nov 12, 2025

    @jvanhill

    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.

  4. bseddon commented on Nov 14, 2025

    @bseddon

    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.

  5. DocX commented on Nov 20, 2025

    @DocX

    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.

  6. bseddon commented on Nov 20, 2025

    @bseddon

    Great observation, thanks. Yes, it works when the header is added.

  7. embesozzi commented on Dec 18, 2025

    @embesozzi

    Same error in v0.18.0
    I can see the mcp-session-id response header returned from the initial POST request when initializing the connection:

    {"method":"initialize","params":{"protocolVersion":"2025-11-25","capabilities":{"sampling":{},"elicitation":{},"roots":{"listChanged":true}},"clientInfo":{"name":"inspector-client","version":"0.18.0"}},"jsonrpc":"2.0","id":0}
    

    However, the MCP Inspector does not send the mcp-session-id header when posting:

    {"method":"notifications/initialized","jsonrpc":"2.0"}
    

    As a result, the MCP server returns a 400 error with the message "Session ID missing".

  8. pbalint commented on Feb 24, 2026

    @pbalint

    +1 for exposing the "Mcp-Session-Id"-header solving the issue, here's what worked for me:

            this.expressApp.use(
                cors({
                    origin: 'http://localhost:6274',
                    allowedHeaders: ['Content-Type', 'Mcp-Session-Id', 'Mcp-Protocol-Version'],
                    exposedHeaders: ['Mcp-Session-Id', 'Mcp-Protocol-Version'],
                })
            );
  9. AlbertoMonteiro commented on Feb 26, 2026

    @AlbertoMonteiro

    Following @pbalint solution, in .NET I've did

    builder.Services.AddCors(x => x.AddDefaultPolicy(c => c.AllowAnyOrigin().AllowAnyHeader().AllowAnyMethod().WithExposedHeaders("Mcp-Session-Id", "Mcp-Protocol-Version")));
  10. daz10000 commented on Feb 28, 2026

    @daz10000

    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.

  11. pswarts commented on Mar 24, 2026

    @pswarts

    It only works in "Via Proxy" mode and not in "Direct" mode

  12. cliffhall commented on Aug 1, 2026

    @cliffhall
    Member

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    authIssues and PRs related to authorizationbugSomething isn't workingclosed-v1-deprecatedClosed: v1 is deprecated and accepting security fixes onlyv1

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions