[flagged]
MCP 2026-07-28 Specification: transport going stateless
11–20 of 58 posts
Re: MCP 2026-07-28 Specification: transport going stateless
#12Hey 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!
Great work! Any word on when to expect support across claude clients?
Re: MCP 2026-07-28 Specification: transport going stateless
#13[dead]
Re: MCP 2026-07-28 Specification: transport going stateless
#14I'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.
Re: MCP 2026-07-28 Specification: transport going stateless
#15Hey 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!
[dead]
Re: MCP 2026-07-28 Specification: transport going stateless
#16Excellent improvement. The server-side complexity required to handle sessions has been a large burden both on infrastructure and on educating teams on its characteristics.
Re: MCP 2026-07-28 Specification: transport going stateless
#17This 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.
Re: MCP 2026-07-28 Specification: transport going stateless
#18Hey 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!
Great work! Any word on when to expect support across claude clients?
We are actively working on this - the support is rolling out across the ecosystem: https://claude.com/blog/bringing-mcp-2026-07-28-to-claude
Re: MCP 2026-07-28 Specification: transport going stateless
#19The 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?
Re: MCP 2026-07-28 Specification: transport going stateless
#20This 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.
It was clear from the start (to anyone who ever designed a protocol [1]) that MCP was a pile anti-patterns. They are slowly undoing the mistakes one by one. Maybe next years version will finally be something usable that it could have been from v1.