[bug] GET /api/mcp does not return HTTP response when valid session ID is provided (Streamable HTTP transport violation)

[DANIILSKRIPCHENKO]

Describe the bug

Summary

The MCP endpoint (/api/mcp) does not correctly implement the GET method as required by the MCP Streamable HTTP transport specification. When a GET request is sent with a valid mcp-session-id, the server accepts the TCP connection but never sends back any HTTP response — no status line, no headers, no body. The connection hangs indefinitely until the client times out.

To reproduce

Steps to Reproduce

Step 1 — Initialize a session via POST:

 SESSION_ID=$(curl -s -D - -X POST http://localhost:3000/api/mcp \
 -H "Content-Type: application/json" \
 -H "Accept: application/json, text/event-stream" \
 -d '{
 "jsonrpc": "2.0",
 "id": 1,
 "method": "initialize",
 "params": {
 "protocolVersion": "2024-11-05",
 "capabilities": {},
 "clientInfo": { "name": "test", "version": "1.0" }
 }
 }' | grep "mcp-session-id" | awk '{print $2}' | tr -d '\r')

 echo "Session: $SESSION_ID"

✅ Returns 200 OK with mcp-session-id header and a valid initialize result over SSE.

Step 2 — Open SSE channel via GET using the obtained session ID:

 curl -i --max-time 5 http://localhost:3000/api/mcp \
 -H "Accept: application/json, text/event-stream" \
 -H "mcp-session-id: $SESSION_ID"

Actual Behavior

curl: (28) Operation timed out after 5000 milliseconds with 0 bytes received

The server accepts the TCP connection but sends zero bytes — no HTTP status line,
no headers, no body, no SSE events. The connection hangs until the client times out.

Sourcebot deployment information

Environment

• Sourcebot version: v4.16.0
• Transport: Streamable HTTP (/api/mcp)
• Protocol version: 2024-11-05
• Tested directly on the sourcebot container (no reverse proxy in front)

Additional information

No response

[brendan-kellam]

Hey @DANIILSKRIPCHENKO - this is valid & I was able to repro. I think the expected behaviour here is that the server returns a Content-Type: text/event-stream immediately.

However, since we don't actually use server sent messages, I think it makes sense for this endpoint to return a 405:

The server MUST either return Content-Type: text/event-stream in response to this HTTP GET, or else return HTTP 405 Method Not Allowed, indicating that the server does not offer an SSE stream at this endpoint.