Is your feature request related to a problem? Please describe.
Yes. When building a stateless, multi-pod MCP server using Redis for event storage, the MCP SDK does not provide a way to reliably map the external sessionId (used in HTTP headers and returned to the client) to the internal streamId (used for event storage and replay). The SDK’s event store methods (storeEvent, replayEventsAfter) only receive the streamId, while the onsessioninitialized callback only receives the sessionId. There is no point in the API where both values are available together. This makes it impossible to implement true stateless session resumability across pods or after restarts, since the server cannot look up or reconstruct the correct event stream for a given session.
Describe the solution you'd like
Please provide a way in the SDK to:
- Expose both the
sessionId and the corresponding streamId together (e.g., in onsessioninitialized or a new callback).
- Or, guarantee that
sessionId === streamId for all sessions.
- Or, provide a mapping utility or hook so stateless resumability can be implemented robustly.
Describe alternatives you've considered
- Attempted to use the session ID as the stream ID by passing it to
sessionIdGenerator, but the SDK may still generate its own internal stream ID, breaking this assumption.
- Considered using a global variable or context to temporarily associate the session ID and stream ID during initialization, but this is not safe for concurrent or multi-user environments.
- Currently, the only robust solution is to use in-memory storage, which does not support stateless, cross-pod resumability.
Additional context
Stateless resumability is critical for scalable, production MCP deployments. Without a reliable mapping between session ID and stream ID, it is not possible to resume sessions across pods or after restarts using Redis or any other external event store. This limitation is a blocker for running MCP in a cloud-native, scalable environment.
Is your feature request related to a problem? Please describe.
Yes. When building a stateless, multi-pod MCP server using Redis for event storage, the MCP SDK does not provide a way to reliably map the external
sessionId(used in HTTP headers and returned to the client) to the internalstreamId(used for event storage and replay). The SDK’s event store methods (storeEvent,replayEventsAfter) only receive thestreamId, while theonsessioninitializedcallback only receives thesessionId. There is no point in the API where both values are available together. This makes it impossible to implement true stateless session resumability across pods or after restarts, since the server cannot look up or reconstruct the correct event stream for a given session.Describe the solution you'd like
Please provide a way in the SDK to:
sessionIdand the correspondingstreamIdtogether (e.g., inonsessioninitializedor a new callback).sessionId === streamIdfor all sessions.Describe alternatives you've considered
sessionIdGenerator, but the SDK may still generate its own internal stream ID, breaking this assumption.Additional context
Stateless resumability is critical for scalable, production MCP deployments. Without a reliable mapping between session ID and stream ID, it is not possible to resume sessions across pods or after restarts using Redis or any other external event store. This limitation is a blocker for running MCP in a cloud-native, scalable environment.