Dust Community Icon

Join the Community

Issues with MCP Server Integration and State Loss in Dust

Wouter De Schuyter

·

·

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.

23 comments

Remi
·
·
Hi Wouter De Schuyter, thanks for your message ! I'll froward it to the tech team to look into it 😊
🙌1
Wouter De Schuyter
·
·
Thanks, much appreciated Remi! Dust looks really cool, would be lovely if our and your users could use our services together!
🚀1
Sébastien Flory
·
·
Yes, we reconnect on every action without keeping the mcp-session-id.
Sébastien Flory
·
·
In Dust environnement, what would be the session lifecycle ?
Sébastien Flory
·
·
The conversation ?
Sébastien Flory
·
·
The answer to the user message ?
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.
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.
Sébastien Flory
·
·
They can decide themselves
Sébastien Flory
·
·
Who's they ?
Wouter De Schuyter
·
·
The MCP server that keeps the session on their end, see quote from the spec above ^
Sébastien Flory
·
·
Ah, I see.
Sébastien Flory
·
·
I feel like it's a sensitive topic. Conversation on dust can last very long (months) and multiple users could interact.
Sébastien Flory
·
·
TBH, it's the first time I see a need for session support on MCP.
Sébastien Flory
·
·
What about making your server non-stateful and pass the state in every interaction ?
Sébastien Flory
·
·
https://developers.tally.so/api-reference/mcp#updating-the-contact-form
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)
Sébastien Flory
·
·
Looking at your doc, I see you return the id of the form somehow.
Sébastien Flory
·
·
Isn't the state retrievable via the form ID ?
Sébastien Flory
·
·
instead of relying on the session itself.
Sébastien Flory
·
·
(i'm probably missing context)
Wouter De Schuyter
·
·
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.
Sébastien Flory
·
·
I see

Issues with MCP Server Integration and State Loss in Dust | Dust Community