Hi,
I've noticed an error with remote MCP servers in the connector.
Consider a remote HTTP based MCP server build from FastMCP. These servers handle sessions by default with an in-memory storage. When such servers are restarted for example, any sessions will be killed which leaves the connector in an unrecoverable state. I could work-around this in our case by enabling stateless mode as we don't rely on sessions (yet).
But in general, I believe this violates the spec under https://modelcontextprotocol.io/specification/2025-11-25/basic/transports#session-management
- The server MAY terminate the session at any time, after which it MUST respond to requests containing that session ID with HTTP 404 Not Found.
- When a client receives HTTP 404 in response to a request containing an MCP-Session-Id, it MUST start a new session by sending a new InitializeRequest without a session ID attached.
This seems to correctly work in Claude Code for example, but the Typingmind connector caches its client based on the config, which in these cases doesn't change so we end up in a situation that any further requests - e.g. to list or call tools - fail because it tries to reuse the same old session id, that the remote side doesn't know about any longer.
Cheers,
Christoph
Hi,
I've noticed an error with remote MCP servers in the connector.
Consider a remote HTTP based MCP server build from FastMCP. These servers handle sessions by default with an in-memory storage. When such servers are restarted for example, any sessions will be killed which leaves the connector in an unrecoverable state. I could work-around this in our case by enabling stateless mode as we don't rely on sessions (yet).
But in general, I believe this violates the spec under https://modelcontextprotocol.io/specification/2025-11-25/basic/transports#session-management
This seems to correctly work in Claude Code for example, but the Typingmind connector caches its client based on the config, which in these cases doesn't change so we end up in a situation that any further requests - e.g. to list or call tools - fail because it tries to reuse the same old session id, that the remote side doesn't know about any longer.
Cheers,
Christoph