Metabase MCP server rejects the initial initialize request with "Missing Mcp-Session-Id header"

1

Title: MCP server rejects the initial initialize request with "Missing Mcp-Session-Id header"

Environment:

Summary:
The MCP server's initialize endpoint rejects the very first handshake request with a 400 error requiring an Mcp-Session-Id header — but this is the request that is supposed to establish a new session and issue that header in its response. No prior session exists at this point, so there is no session ID a client could possibly attach. This makes it impossible for any MCP client (including Claude.ai's Metabase connector) to ever successfully open a session.

Steps to reproduce:

  1. Generate a Metabase API key with admin permissions.
  2. Send a POST request to /api/metabase-mcp with the standard MCP initialize payload and a valid X-Api-Key header, e.g.:

curl -i -X POST https://reports.ammosquared.com/api/metabase-mcp -H "Content-Type: application/json" -H "Accept: application/json, text/event-stream" -H "X-Api-Key: " -d "{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"manual-test","version":"1.0.0"}}}"

Actual result:
{"jsonrpc":"2.0","id":null,"error":{"code":-32600,"message":"Missing Mcp-Session-Id header"}}

Expected result:
The initialize request should succeed and the response should include a new Mcp-Session-Id header that the client can use for all subsequent requests, per the MCP Streamable HTTP transport spec.

Additional context:
This also breaks Claude.ai's hosted Metabase connector, which fails every connection attempt with "Your account was authorized, but Metabase returned an error when connecting." Server-side request logs confirm the same pattern there: OAuth completes successfully (POST /oauth/token 200), immediately followed by GET /api/mcp 400 with the same "Missing Mcp-Session-Id header" error.

We've ruled out configuration issues on our end: Site URL is correctly set with no trailing slash, the MCP server feature is enabled, and there's no client allowlist in this version to worry about. This appears to be a bug in the MCP server's session-handling logic itself.

Happy to provide full logs or run further tests if useful.