Description
Sourcebot's MCP endpoint at /api/mcp only handles POST. GET /api/mcp returns 405 Method Not Allowed. Per the MCP streamable-HTTP transport spec, the server should also handle GET on the same path to expose an SSE channel that delivers server-initiated messages (e.g. notifications/listChanged, log notifications).
Repro
$ curl -i -X GET http://localhost:3000/api/mcp
HTTP/1.1 405 Method Not Allowed
$ curl -i -X GET -H 'accept: text/event-stream' http://localhost:3000/api/mcp
HTTP/1.1 405 Method Not Allowed
POST /api/mcp works fine, including session continuity via Mcp-Session-Id headers (verified end-to-end with initialize → tools/list).
Impact
This breaks integration with strictly-spec-compliant MCP clients and proxies that try to open the optional listen channel after initialize succeeds.
Concrete example: Teleport's tsh mcp connect (v18.7.4) opens a GET listen channel against the upstream MCP server. On 405 it logs
ERROR: server does not support listening
then emits a malformed empty notification ({"jsonrpc":"2.0","method":""}) on its stdio bridge, after which the session is closed before any in-flight request (e.g. tools/list) completes. Downstream MCP clients hang waiting for tool discovery.
A complementary issue filed against Teleport at gravitational/teleport#66505 for graceful 405 handling on the client side — both fixes are independently valid.
Versions
- Sourcebot:
v4.16.15
- Reproduced via:
tsh mcp connect v18.7.4, plus direct curl
Suggested fix
Add a GET handler to packages/web/src/app/api/(server)/mcp/route.ts that opens the streamable-HTTP SSE listen channel. Even a minimal handler that establishes the SSE stream and keeps it open (without emitting any server-initiated notifications, if none are needed) would satisfy the spec and unblock spec-compliant clients.
Description
Sourcebot's MCP endpoint at
/api/mcponly handlesPOST.GET /api/mcpreturns405 Method Not Allowed. Per the MCP streamable-HTTP transport spec, the server should also handleGETon the same path to expose an SSE channel that delivers server-initiated messages (e.g.notifications/listChanged, log notifications).Repro
$ curl -i -X GET http://localhost:3000/api/mcp HTTP/1.1 405 Method Not Allowed $ curl -i -X GET -H 'accept: text/event-stream' http://localhost:3000/api/mcp HTTP/1.1 405 Method Not AllowedPOST /api/mcpworks fine, including session continuity viaMcp-Session-Idheaders (verified end-to-end withinitialize→tools/list).Impact
This breaks integration with strictly-spec-compliant MCP clients and proxies that try to open the optional listen channel after
initializesucceeds.Concrete example: Teleport's
tsh mcp connect(v18.7.4) opens aGETlisten channel against the upstream MCP server. On 405 it logsthen emits a malformed empty notification (
{"jsonrpc":"2.0","method":""}) on its stdio bridge, after which the session is closed before any in-flight request (e.g.tools/list) completes. Downstream MCP clients hang waiting for tool discovery.A complementary issue filed against Teleport at gravitational/teleport#66505 for graceful 405 handling on the client side — both fixes are independently valid.
Versions
v4.16.15tsh mcp connectv18.7.4, plus directcurlSuggested fix
Add a
GEThandler topackages/web/src/app/api/(server)/mcp/route.tsthat opens the streamable-HTTP SSE listen channel. Even a minimal handler that establishes the SSE stream and keeps it open (without emitting any server-initiated notifications, if none are needed) would satisfy the spec and unblock spec-compliant clients.