[VOTE] Support Stateful Sessions in a Multi-Worker Environment, Using a Shared Session Store

[shahar4499]

This was an issue that was highly requested by the community when SSE transport was the only mode that was supported.

Now that fastapi-mcp supports HTTP transport, we wonder if it's still relevant.

I'm opening this issue to collect upvotes and see if the community is interested in such a feature.

Currently, stateful HTTP / SSE will only work per-instance.

[Edison-A-N]

It is necessary to enable stateless configuration. The MCP Tool Service converted directly from the FastAPI service usually does not handle the mcp-session-id. That is, the FastAPI service is mostly stateless.

[Edison-A-N]

It is necessary to enable stateless configuration. The MCP Tool Service converted directly from the FastAPI service usually does not handle the mcp-session-id. That is, the FastAPI service is mostly stateless.

Now, when I run my FastAPI application using Gunicorn with 4 workers, I encounter an error: "Bad Request: No valid session ID provided". This issue arises because I initially connect to one worker and obtain an mcp-session-id. However, when I subsequently send a request to the server using this mcp-session-id, Gunicorn routes the request to a different worker that does not have this mcp-session-id stored. As a result, the request fails due to the lack of a valid session ID.

[shahar4499]

It is necessary to enable stateless configuration. The MCP Tool Service converted directly from the FastAPI service usually does not handle the mcp-session-id. That is, the FastAPI service is mostly stateless.

Now, when I run my FastAPI application using Gunicorn with 4 workers, I encounter an error: "Bad Request: No valid session ID provided". This issue arises because I initially connect to one worker and obtain an mcp-session-id. However, when I subsequently send a request to the server using this mcp-session-id, Gunicorn routes the request to a different worker that does not have this mcp-session-id stored. As a result, the request fails due to the lack of a valid session ID.

@Edison-A-N Did you try using the latest version (0.4.0) with mount_http?

And yeah, makes sense. Even though session-id is optional in HTTP transport, if you already provide it, it will fail if not found.

In that case, just adding a stateless flag to force stateless HTTP transport would help, right?

Opened a new issue for that: #209

[Edison-A-N]

Hi,

Yes, I've run my app with a SINGLE Gunicorn worker using the latest version (0.4.0) with mount_http. Adding the stateless flag and passing it down to the underlying HTTP transport layer successfully enables stateless behavior, thus avoiding the error.

I have opened a pull request to implement this feature: add stateless http transport support by Edison-A-N · Pull Request #213 · tadata-org/fastapi_mcp.

[TTHNN-ld]

Hi, 嗨，

Yes, I've run my app with a SINGLE Gunicorn worker using the latest version (0.4.0) with mount_http. Adding the stateless flag and passing it down to the underlying HTTP transport layer successfully enables stateless behavior, thus avoiding the error.是的，我已经使用最新版本（0.4.0）的单个Gunicorn工作进程运行了我的应用，并使用了mount_http。添加stateless标志并将其传递到底层HTTP传输层，成功启用了无状态行为，从而避免了该错误。

I have opened a pull request to implement this feature: add stateless http transport support by Edison-A-N · Pull Request #213 · tadata-org/fastapi_mcp.我已经打开了一个拉取请求来实现这个功能：Edison-A-N 添加无状态 HTTP 传输支持 · 拉取请求 #213 · tadata-org/fastapi_mcp。

Hello, it seems that setting stateless=True for StreamableHTTPSessionManager in the http.py file is sufficient, but I received an error on the server side after making the setting, and the client side may have a response

[Edison-A-N]

@TTHNN-ld Hi,

Thanks for reporting the issue.
The root cause is most likely on the MCP side rather than in this project or the changes introduced by the PR.

Please take a look at modelcontextprotocol/python-sdk#1363 – it describes a very similar scenario in full detail.

From what we can see so far, the immediate trigger for the error you’re seeing is an incorrect Accept or Content-Type header from the client—or, more generally, any request element that deviates from the MCP specification. (I did a quick test: plain JSON-RPC bodies that are merely malformed don’t reproduce this particular failure.) Could you double-check those headers and retry?