I would like to maintain MCP server state persisted (sessionId)

[poornimas-iyer]

Now the session id is maintained in memory in a map. But since I have my MCP server multiple pods running, I would like the state to be persisted in redis or in a DB.

I would like to override the session Validator as a parameter in the HttpServletStreamableServerTransportProvider

Current Behavior

Currently only the session creation can be customised but not maintaining the state fully.

Context

I am not able to implement stateful session in a distributed setup

[amaan75]

@chemicL is this waiting on Stateless MCP #1442
or are we free to raise a PR for this?
Also what is the general guideline for implementation, are we free to use something like Spring data Redis, or is the expectation that the SDK exposes/defines interfaces/contracts while the default implementation creates inMemoryVariants for them while expecting the actual users to implement the Distributed Storage?

What store( i would assume redis (cluster enabled/disabled) is a preferred choice for writing a horizontal adapter, since there would be cases when SSE requests in MCP tie things down to single sever/node and we would want to still make it so that server initiated notifications are going to respond back with the correct SSE channel via the correct server/node/instance.

[amaan75]

@chemicL I read how other sdks are planning to tackle this, turns out instead of a horizontal adapter, which imho will probably also work for websocket assuming that some one does add some kind of a callback for task status update once the task kind completes, but that's beside the point, most sdks are banking on saving whatever state can be serialised in Redis or some store like mongo/redis or something similar and for the pieces where a SSE or some other transport is required, they expect that to be recreated, if its missing against a node. what route will the java sdk take here?
Oh and Btw, what I mean by the horizontal adapter is some kind of a Redis pub/sub model, where instead of directly sending the server Side initiated thing ( like a notification) to the client, we put in some kind of a Redis like system which also keeps using which we will then be able to decide which instance/node/pod needs to act on it.
this is fairly common with systems like soketi, sockudo, which mostly deal with web sockets, in our case SSE, but also have other apis that are http. there is however a slight issue where, we probably need to think about how do we abstract out cases, where some responses can/should be sent in a sync way, but others probably need to go back via SSE,

I could be wrong about this bit

the other complication that I see here is when somebody they'd would like to ditch SSE altogether and purely work with buffered json responses, I read on 1 of the issues that it was a thing not super sure about what's the plan there and how does this impact it, didn't go deep into that yet.

anyway, TLDR; I'd like for you to let me take a stab at this requirement once we agree on what route to take here since our deployment setup is fairly complicated ( just spinning up an NLB and exposing this with a connection based sticky hash is not an option for my stack )and doing sticky sessions reliably will probably also not happen because of the same reasons.
The very least that I expect to get out of this is an event store implementation which gives me resumability.
Also I understand you probably have a lot on your plate, but a response would be appreciated.