SSE Transport Statefulness Breaks in Serverless Deployments

[Vinlic]

Describe the bug
The current SSE transport implementation (SSEServerTransport) is stateful—it relies on in-memory session storage (transports: {[sessionId: string]: SSEServerTransport}). This creates a critical issue in serverless environments (AWS Lambda, Cloudflare Workers, etc.) where:

1. The initial GET /sse request may be handled by Instance A.
2. Subsequent POST /messages requests (with the same sessionId) may land on Instance B, which lacks the in-memory transport state.
3. Result: 400: No transport found for sessionId, breaking the SSE workflow.

Additionally, this also renders load balancing completely unusable in the SSE Server.

To Reproduce
Steps to reproduce the behavior:

1. Deploy the example MCP SSE server to a serverless platform (e.g., AWS Lambda + API Gateway).
2. Connect a client to /sse.
3. Send a message to /messages?sessionId=<ID>.
   → Expected: Message delivered via SSE.
   → Actual: 400 error unless the request hits the same instance.

[Vinlic]

Perhaps WebSocket would be a better choice for the underlying protocol? I don't understand why SSE was chosen.

Let's reopen this PR: #232

[kentcdodds]

SSE has been replaced by Streamable HTTP in the spec and this was recently merged: #266

This is in part to support serverless architecture better.

[fantasy-lotus]

these days i depoly my mcp server on aws lambda, the same problem happens ! I do not understand why mcp sse need two controllers,it bring trouble in serverless environment.Additionnally，transport from mcp sdk can not be persistenced in db like dynamo because maybe it does not support serializable. At last, i use original http to realize sse mcp server with session persistence by dynamodb, it's troublesome

[felixweinberger]

Hi @Vinlic thanks for reporting this - checking in whether this is still an issue for you with StreamableHTTP? There have been changes to introduce stateless mode https://github.com/modelcontextprotocol/typescript-sdk?tab=readme-ov-file#without-session-management-recommended

Would that solve your usecase?