Comments
Hacker News
Perfect. The actual tool calls are stateless anyway; when an LLM asks get_my_todos and then asks add_todo it’s not actually holding anything in RAM it’s just text going back into the context window (get_my_todos results) and then another tool call
And even on the server side statefulness is very iffy anyway. How long are you going to hold something in RAM from a client and how long will you hold the connection open
by firasd
To be honest I've completely ignored this feature and 95% of my colleagues at work have not interacted with it at all - we are not an AI pilled company - but this specification now seems mature enough for me to be excited about developing a server, just haven't found a concrete use case yet that isn't already publicly available.
The improvements look great. At the same time I wonder if it is possible to keep using MCP 1.x as well for now. Development is expensive, right? It also looks possible to transition to MCP 2.x by tackling the different improvements one at a time as long as we take stateless core first?
This is the right practice. Why put the burden on the server? It is the job of client to remember, not the server. Server is there to serve requests, not do the remembering. That is how http worked from the beginning and that is why it has been successful.
by osinix
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!
by dend
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 internal use MCP, this is fine for me, but if you are cleaning up semantics: Understanding how we expect clients to act around failure would really help, the story.
by ilc
Excellent improvement. The server-side complexity required to handle sessions has been a large burden both on infrastructure and on educating teams on its characteristics.
by btbuilder
Finally.
I am running an MCP server gateway/registry (some of you may know Glama).
I cannot tell you what portion of our issues/bugs were due to the need to persist server state.
This change will allow us to offer a lot easier way for people to use Open-Source MCP servers.
by punkpeye
Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- Perfect. The actual tool calls are stateless anyway; when an LLM asks get_my_todos and then asks add_todo it’s not actually holding anything in RAM it’s just text going back into the context window (get_my_todos results) and then another tool call
And even on the server side statefulness is very iffy anyway. How long are you going to hold something in RAM from a client and how long will you hold the connection open
by firasd - To be honest I've completely ignored this feature and 95% of my colleagues at work have not interacted with it at all - we are not an AI pilled company - but this specification now seems mature enough for me to be excited about developing a server, just haven't found a concrete use case yet that isn't already publicly available.
- The improvements look great. At the same time I wonder if it is possible to keep using MCP 1.x as well for now. Development is expensive, right? It also looks possible to transition to MCP 2.x by tackling the different improvements one at a time as long as we take stateless core first?
- This is the right practice. Why put the burden on the server? It is the job of client to remember, not the server. Server is there to serve requests, not do the remembering. That is how http worked from the beginning and that is why it has been successful.by osinix
- 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!by dend
- 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 internal use MCP, this is fine for me, but if you are cleaning up semantics: Understanding how we expect clients to act around failure would really help, the story.
by ilc - Excellent improvement. The server-side complexity required to handle sessions has been a large burden both on infrastructure and on educating teams on its characteristics.by btbuilder
- Finally.
I am running an MCP server gateway/registry (some of you may know Glama).
I cannot tell you what portion of our issues/bugs were due to the need to persist server state.
This change will allow us to offer a lot easier way for people to use Open-Source MCP servers.
by punkpeye