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:
- The initial
GET /sse request may be handled by Instance A.
- Subsequent
POST /messages requests (with the same sessionId) may land on Instance B, which lacks the in-memory transport state.
- 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:
- Deploy the example MCP SSE server to a serverless platform (e.g., AWS Lambda + API Gateway).
- Connect a client to
/sse.
- Send a message to
/messages?sessionId=<ID>.
→ Expected: Message delivered via SSE.
→ Actual: 400 error unless the request hits the same instance.
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:GET /sserequest may be handled by Instance A.POST /messagesrequests (with the samesessionId) may land on Instance B, which lacks the in-memory transport state.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:
/sse./messages?sessionId=<ID>.→ Expected: Message delivered via SSE.
→ Actual:
400error unless the request hits the same instance.