51–58 of 58 posts
Hey folks - one of the Lead Maintainers for MCP. Happy that we got this release out the door today, this is an exciting change for those that wanted to roll out remove MCP servers into serverless hosts. There is, of course, more good stuff packed, so if you have questions or feedback - our team is here to help!
We built ours stateless before the spec allowed it. No SSE at all and GET just returns 405, everything is a plain POST about 46 tools. We were betting clients would cope, and most of them did. When one did not, we had to tell the user their client was the problem, which is never a good look. The surprise for us was auth getting easier. No session means no confusion about when the key was checked. Anyone can list the…
are they coming up with an alternative? i use them to monitor workflows that takes days and now i have to make some changes
I'd made the shift to HTTP/Stateless from MCP a few months ago. It's the right thing to do IMHO. Reliability up, problems down. TOON support is natural, if desired, etc. My only question is how do you handle channels in the architecture now. From what I saw in Claude Code, shifting to a totally http world has some timeout issues if a server drops out and comes back. Because of that I'm stuck writing stubs for my inte…
Hey folks - one of the Lead Maintainers for MCP. Happy that we got this release out the door today, this is an exciting change for those that wanted to roll out remove MCP servers into serverless hosts. There is, of course, more good stuff packed, so if you have questions or feedback - our team is here to help!
Thank you! What’s the best practice for tools where the upstream API only supports basic auth (username/password) and there’s no OBO option? In my case the login returns a token that’s only valid for an hour, so the user has to re-auth after that. Do you stash the credentials on the MCP server and silently refresh, or is there a nicer pattern people are using?
Hey folks - one of the Lead Maintainers for MCP. Happy that we got this release out the door today, this is an exciting change for those that wanted to roll out remove MCP servers into serverless hosts. There is, of course, more good stuff packed, so if you have questions or feedback - our team is here to help!
The workaround proposed is to have the model pass in an ID which is a waste of tokens if this could have been injected by the client.
Stateful tools make sense for long running conversations, where knowledge of previous tool results can improve the result OR where you want to use ephemeral conversation scoped IDs for entities referred to in the chat (for instance referring to search results as r1/r2/r3 rather than a UUID. Or for chaining together tool calls so that the results of a 'search' tool can be passed into a batch edit tool without the need to pass in a 100 strong list of UUIDs or have unneccesary duplicated arguments.
Will there be optional support for stateful tool calling? As with it removed it has made engineering easier, but performance and flexibility lower.
In the situation where we use MCP we already have a stateful AI assistant, and with this change we will have to support a seperate server just for MCP (rather than one that is the same as our AI assistant tools) that will never have performance parity with the assistant on our platform where we can guarentee state is maintained.
I would say that most people at the moment are still building simpler stateless MCP servers and AI assistants. As we as a field get better at doing this, stateful will become the standard as it is a superset of stateless and more performant.