Strategy for multi instances server without loadbalancer affinity

[ouvreboite]

Pre-submission Checklist

• I have checked that this question would not be more appropriate as an issue in a specific repository
• I have searched existing discussions and documentation for answers

Question Category

• Protocol Specification
• SDK Usage
• Server Implementation
• General Implementation
• Documentation
• Other

Your Question

Currently, using multiple stateless HTTP server instances result in an error each time a client reach another instance (it provides an Mcp-Session-Id that is not known by the other instance).

//In StreamableHttpHandler.cs
else if (HttpServerTransportOptions.Stateless){
     var sessionJson = Protector.Unprotect(sessionId); //This throws

System.Security.Cryptography.CryptographicException: The provided payload cannot be decrypted because it was not protected with this protection provider.

Header-based affinity in the LBs is a possibility, but I think it will still generate errors each time you restart an instance and a client have to switch to a new one (so quite frequently depending on your continuous deployment strategy).

Looking at the code, the stateless servers rely on IDataProtectionProvider to store the session data. By default, this is a local storage.

❓ To implement a distributed stateless server, would using a distributed key storage provider be a good practice? For example using redis to store the session info.

[ouvreboite]

@halter73 given you are the one that added the IDataProtectionProvider, was this the intended usage?

[CharlieDigital]

Came here to try to figure out this same issue. Ideally, there is some mechanism to hook into session management with an interface like an ISessionConnector or the like which would allow externalizing the the session management (e.g. backing state with Redis or Postgres if needed, for example or using HybridCache by default).

A workaround I'm pondering is that the MCP tool itself operates as stdio deployed as a .NET tool and all of the real heavy lift ends up deployed onto a plain .NET web API server which can then be stateless. Ideally, however, it seems like a pluggable option to manage session state backing would solve the issue.