Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MCP 2026-07-28 Specification: transport going stateless

blog.modelcontextprotocol.io

Post reply on HN
Print view View original

21–30 of 58 posts

Re: MCP 2026-07-28 Specification: transport going stateless

#21

Post by hangrybear666 »

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.

Re: MCP 2026-07-28 Specification: transport going stateless

#22

Post by jgil »

progbits wrote: post #20
osinix wrote: post #17

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.

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. [1] https://news.ycombinator.com/item?id=44016783

Yes. However, using something like MCP encourages many companies to claim that they are "integrating AI" -- and typical MCP implementations burn tokens quite profitably.

Re: MCP 2026-07-28 Specification: transport going stateless

#23

Post by jakobgm »

dend wrote: post #4

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!

Congrats at shipping the new specification!

Any new to share on file upload support? We have shipped a MCP server and it has been really frustrating to observe MCP clients fumbling around with base64-encodings, polluting their context window with binary data. SEP-1306 (Binary Mode Elicitation) was superseded by SEP-2356 (File input support for tools and elicitation), and that was in turn superseded by SEP-2631 (File Objects and Transfer) which is currently left in a draft state with little activity.

Allowing LLM-based agents to shuffle binary data around efficiently and reliably seems like a pretty big gap in the current specification, if you ask me!

Re: MCP 2026-07-28 Specification: transport going stateless

#24

Post by punkpeye »

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.

Re: MCP 2026-07-28 Specification: transport going stateless

#25

Post by colinator »

jakobgm wrote: post #23
dend wrote: post #4

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!

Congrats at shipping the new specification! Any new to share on file upload support? We have shipped a MCP server and it has been really frustrating to observe MCP clients fumbling around with base64-encodings, polluting their context window with binary data. SEP-1306 (Binary Mode Elicitation) was superseded by SEP-2356 (File input support for tools and elicitation), and that was in turn superseded by SEP-2631 (File…

I concur. Most of my MCP pain is dealing with client's differing ability to handle images. Some clients (old codex) would even truncate the base64 data regardless of how it was json-wrapped. And sometimes they just ingest the base64 date directly into their context window. Not sure if this is an MCP thing or a clients-poorly-implementing-MCP thing.

Re: MCP 2026-07-28 Specification: transport going stateless

#27

Post by closetheloopdev »

flowofcontrol wrote: post #19

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?

I just realized that MCP releases do not use semver. It says this is a 2026-07-28 version which is quite unusual and can be quite hard to keep track of, especially when backwards compatibility is of concerns.

There is a one-year-old open GitHub issue asking to use semver instead: https://github.com/modelcontextprotocol/modelcontextprotocol...

Re: MCP 2026-07-28 Specification: transport going stateless

#28

Post by flowofcontrol »

closetheloopdev wrote: post #27
flowofcontrol wrote: post #19

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?

I just realized that MCP releases do not use semver. It says this is a 2026-07-28 version which is quite unusual and can be quite hard to keep track of, especially when backwards compatibility is of concerns. There is a one-year-old open GitHub issue asking to use semver instead: https://github.com/modelcontextprotocol/modelcontextprotocol...

You are right, in my mind the 2026-07-28 version was MCP 2.0 but the article never mentions that. I do remember having read about MCP 2.0 elsewhere. Regardless, we cannot expect this to be the last impactful change and to me it makes sense to indeed semantically version.

Re: MCP 2026-07-28 Specification: transport going stateless

#29

Post by punkpeye »

punkpeye wrote: post #24

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.

Just ran some quick numbers. In our index of 62,726 Open-Source servers, ~18,000 have been pushed to in the last 30 days.

  ┌─────────────────────────────┬────────┬───────────┐
  │ Pushed in last 7 days       │ 6,101  │ 9.9%      │
  ├─────────────────────────────┼────────┼───────────┤
  │ Pushed in last 30 days      │ 18,707 │ 30.2%     │
  ├─────────────────────────────┼────────┼───────────┤
  │ Pushed in last 90 days      │ 30,393 │ 49.1%     │
  ├─────────────────────────────┼────────┼───────────┤
  │ Pushed in last 365 days     │ 54,327 │ 87.8%     │
  └─────────────────────────────┴────────┴───────────┘
So about ~30% are actively maintained. That's a pretty big portion of the community.

However, the new protocol is wire-incompatible in both directions. This means that many of the servers/clients will need to be refactored (not enough to just update the SDK). It will take time and it will be messy (despite SSE deprecation, there are still many servers and clients that are SSE-only). Honestly, a legitimate opportunity for MCP gateways (ours included) to become more valuable by becoming an interoperability layer between protocol incompatible servers/clients.

Post reply on HN