Stateless Mode with Scaling Not Working

[sr-auto]

Describe the bug
We have an MCP server using the C# SDK and the latest iteration of the code with the latest spec changes.

Utilizing stateless mode with this MCP server does not work as intended.

• When using a single instance, the MCP server works as intended.
• When using multiple instances, the MCP server instances are backed by a L4 load balancer, no session affinity, the connection works intermittently, giving 500 response codes and connection errors most of the time, due to a subsequent request (tools/list) landing on a different machine than the first request (initialize).

To Reproduce
Steps to reproduce the behavior:

1. Create MCP server
2. Scale MCP server to more than one instance
3. Try to connect to the server from a client

Expected behavior
The MCP server correctly handles stateless behavior by routing requests without session affinity and successfully connecting to the MCP server 100% of the time regardless of which server was hit.

Logs

2025-08-06 12:40:06.005 [info] Starting server MCPServer
2025-08-06 12:40:06.005 [info] Connection state: Starting
2025-08-06 12:40:06.009 [info] Starting server from LocalProcess extension host
2025-08-06 12:40:06.009 [info] Connection state: Running
2025-08-06 12:40:06.009 [debug] [editor -> server] {"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{"roots":{"listChanged":true},"sampling":{},"elicitation":{}},"clientInfo":{"name":"Visual Studio Code","version":"1.102.1"}}}
2025-08-06 12:40:07.608 [debug] [server -> editor] {"result":{"protocolVersion":"2024-11-05","capabilities":{"logging":{},"tools":{"listChanged":true}},"serverInfo":{"name":"MCPServer","version":"1.0.0"}},"id":1,"jsonrpc":"2.0"}
2025-08-06 12:40:07.608 [debug] [editor -> server] {"method":"notifications/initialized","jsonrpc":"2.0"}
2025-08-06 12:40:07.608 [debug] [editor -> server] {"jsonrpc":"2.0","id":2,"method":"tools/list","params":{}}
2025-08-06 12:40:07.950 [info] Connection state: Error 500 status sending message to https://your_mcp_server.com/:

[hoffe86]

We're hitting the same issue when deploying our MCP server on AKS with two PODs. It looks like going stateless or moving session handling outside the app might help avoid errors like "sessionId not found" that we're currently dealing with.

[halter73]

If you turn on ASP.NET Core logging that should give you some insight into the cause of the 500 errors which are generally caused by uncaught exceptions. In development mode the exception details would be written to the response body, but that's disabled in production for security reasons. That's just for future reference though. Based on your scenario, I'm almost sure you're running into the following error:

System.Security.Cryptography.CryptographicException: The key {59baa26c-5757-494e-bc99-c7a2d3331425} was not found in the key ring. For more information go to https://aka.ms/aspnet/dataprotectionwarning

The stateless option relies on ASP.NET Core Data Protection which requires configuring a mechanism to share private keys if you do not have sticky sessions. There are a bunch of ways to configure Data Protection to share keys described in https://learn.microsoft.com/aspnet/core/security/data-protection/configuration/overview. Sharing Data Protection keys is already common requirement for ASP.NET Core apps that use authentication cookies or implement anti-xsrf/antiforgery protections.

#484 has some more context about what exactly we use data protection for in stateless mode (mainly to prevent the session from getting hijacked by another user) and what we could do to remove this requirement.

Based on the amount of feedback we've gotten about this being an issue, I think we'll probably introduce a new completely "Sessionless" mode that doesn't rely on state or Data Protection and possibly get rid of the "Stateless" mode. As of right now, all that stateless mode adds on top of a sessionless mode is that it generates a session ID and populates IMcpServer.ClientInfo with details from the initialize request when handling subsequent requests for things like tool calls.