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.