Wouter De Schuyter

Commented on Issues with MCP Server Integration and State Loss...·Posted inFeedback

We considered it but it makes things quite a bit more complicated and slower on our side, while the stateful MCP is described in the spec makes perfect sense for our use-case. It just removes a lot of overhead / back and forth between DB, API & MCP.

Commented on Issues with MCP Server Integration and State Loss...·Posted inFeedback

Wouter De Schuyter

That wouldn't really be an issue if they can exist for months, they can continue the conversation if a session expired in a new session (on which the MCP would load the existing form and users would be able to continue iterating)

Commented on Issues with MCP Server Integration and State Loss...·Posted inFeedback

Wouter De Schuyter

The MCP server that keeps the session on their end, see quote from the spec above ^

Commented on Issues with MCP Server Integration and State Loss...·Posted inFeedback

Wouter De Schuyter

They can decide themselves when they want to cycle through a session id and might not keep sessions active forever.

3. 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. 4. 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.

Commented on Issues with MCP Server Integration and State Loss...·Posted inFeedback

Wouter De Schuyter

Yes, I think that makes sense to keep it the same on a conversation level as long as it respects the returned Mcp-Session-Id from the MCP server.

Commented on Issues with MCP Server Integration and State Loss...·Posted inFeedback

Wouter De Schuyter

Thanks, much appreciated Remi! Dust looks really cool, would be lovely if our and your users could use our services together!

Posted in Feedback·

Wouter De Schuyter

Issues with MCP Server Integration and State Loss in Dust

Hi, Wouter from Tally here 👋 We had some users reach out that they're having trouble getting our MCP server to work with Dust. However, after investigating, I see that state gets lost because for some reason Dust tries to re-initialize after every tool call. Since our MCP server is stateful (form building, you iterate on a form) it will indeed fail to build a form and save it eventually. What we see is that after it successfully made a tool call with POST /mcp the request still included the Mcp-Session-Id. Then it does a GET /mcp call – which still includes the Mcp-Session-Id, and then it will make a POST /mcp call without the Mcp-Session-Id and freshly initialize (and get a new Mcp-Session-Id back) – while we return the Mcp-Session-Id on every request made. Can someone shed some light on this? Don't know if there's a better channel for discussing technical / integration topics. I've looked at your docs page but I don't see anything mentioned about state. For your reference, the MCP spec about session management.

23Comments