I had hoped they’d go with CoAP for the better overall fit with agent systems (natively async, con/non, Observe), but stateless is enough of a win I can’t complain.
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.
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.
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!
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!
Hey I am the one Lead maintainer of the MCP protocol.
I agree and hear you that file uploads are a pain. As the core maintainer group we have deferred the work on this for this release and hope to pick it up soon.
Now is the moment to engage with the respective working group to make your case heard so we can ensure it’s on the roadmap.
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.
The Java SDK is currently a Tier 2 SDK.. As a Tier 2 SDK they have up to 6 months to implement it. I know they are actively working towards support for the specification.
Best to join our community discord [1] and ask the maintainers !
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?
URL Elicitation works well if a human is driving the client. Unfortunately MCP client support is patchy but I expect that will change now the protocol is stateless.
I'm currently working on getting all my MCP tools ported over to HTTP, with a single call_http tool, so I can just call APIs and benefit from a long history of patterns (like stateless-ness) that have already existed there for decades.
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.
Yes. However, using something like MCP encourages many companies to claim that they are "integrating AI" -- and typical MCP implementations burn tokens quite profitably.
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.
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?
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.
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.
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
I don't see the need for MCP for most use cases where it's currently used.
You can get better results with skills SKILL.md + linked .md files with curl commands inside... Just plain HTTP(S). I say this as someone who often prefers the stateful WebSocket protocol for data transport. HTTP stateless request-response model is a natural fit for LLMs.
HTTP is an excellent protocol for this and curl is an excellent, very popular command on which all major coding models are well trained. LLMs are insanely good with curl. Not to mention that it's pre-installed on all major operating systems. The curl command has become the protocol.
Then there is the fact that most tools require some documentation to go along with it anyway (to be used correctly). MCP mostly adds unnecessary work for a lot of cases.
It has its place in backend code environments I guess... But most of these use cases are thin applications trying to be a middleman between the user and the AI. I think ultimately, the AI will be at the front and tools at the back. Hence, curl.
Wedging a platform between the user and AI creates unnecessary constraints and reduces interoperability and integration opportunities.
Oh hey, it's modelcontextprotocol.io , your official source of protocol specifications and definitely not some attacker trying to get curious vibecoders to run their documentation with a prompt like "implement this", and getting it to install their payload via an npm package like '@modelcontextprotocol/server-filesystem' or the uv/pypi mcpcli package.
But sure, you can expend more effort inspecting the source code and documentation than the developers actually spent writing it to verify that it's all safe and well architected.
Ok, end of rant. To be explicit, there's a lot of security issues here, that make it hard to distinguish a malicious actor from a legitimate one:
1- A TLD based in British Indian Ocean territory.
2- A domain name of the product itself, not the entity behind it. (Not how domains work)
3- low value to risk ratio. Some degree of risk is necessary, but if it is done for no benefit, then the acceptable risk becomes lower. It still isn't clear at all what the advantage of mcp is. Maybe when it came out that was my fault, but at this point you have to concede there's a communication or marketing issue, or lack of actual benefit.
4- It's presented as a protocol, but it actually comes with an extensive vibecoded reference implementation, and the code is distributed across multiple repositories, so it's not at all trivial to enumerate where all of the code is, which is a prerequisite to even start static code analysis, leaving one with the only option of runtime analysis, which is a good queue to drop it and not even bother to begin with.
5- The code is vibecoded and auditing would take more time than it takes to actually write it, which is one of the conditions for an amplified DoS attack (on developer attention), the best defense against such attacks is to ignore the packets, so the best path is to ignore content about Model Context Protocol.
I had hoped they’d go with CoAP for the better overall fit with agent systems (natively async, con/non, Observe), but stateless is enough of a win I can’t complain.
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.
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.
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.
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!
Hey I am the one Lead maintainer of the MCP protocol.
I agree and hear you that file uploads are a pain. As the core maintainer group we have deferred the work on this for this release and hope to pick it up soon.
Now is the moment to engage with the respective working group to make your case heard so we can ensure it’s on the roadmap.
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.
Thank you for your work! I was looking forward to the stateless update.
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
When will java sdk come out with latest changes from spec?
The Java SDK is currently a Tier 2 SDK.. As a Tier 2 SDK they have up to 6 months to implement it. I know they are actively working towards support for the specification.
Best to join our community discord [1] and ask the maintainers !
[1] https://modelcontextprotocol.io/community/communication
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?
URL Elicitation works well if a human is driving the client. Unfortunately MCP client support is patchy but I expect that will change now the protocol is stateless.
I'm currently working on getting all my MCP tools ported over to HTTP, with a single call_http tool, so I can just call APIs and benefit from a long history of patterns (like stateless-ness) that have already existed there for decades.
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.
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.
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?
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.
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
I don't see the need for MCP for most use cases where it's currently used.
You can get better results with skills SKILL.md + linked .md files with curl commands inside... Just plain HTTP(S). I say this as someone who often prefers the stateful WebSocket protocol for data transport. HTTP stateless request-response model is a natural fit for LLMs.
HTTP is an excellent protocol for this and curl is an excellent, very popular command on which all major coding models are well trained. LLMs are insanely good with curl. Not to mention that it's pre-installed on all major operating systems. The curl command has become the protocol.
Then there is the fact that most tools require some documentation to go along with it anyway (to be used correctly). MCP mostly adds unnecessary work for a lot of cases.
It has its place in backend code environments I guess... But most of these use cases are thin applications trying to be a middleman between the user and the AI. I think ultimately, the AI will be at the front and tools at the back. Hence, curl.
Wedging a platform between the user and AI creates unnecessary constraints and reduces interoperability and integration opportunities.
Oh hey, it's modelcontextprotocol.io , your official source of protocol specifications and definitely not some attacker trying to get curious vibecoders to run their documentation with a prompt like "implement this", and getting it to install their payload via an npm package like '@modelcontextprotocol/server-filesystem' or the uv/pypi mcpcli package.
https://modelcontextprotocol.io/docs/2026-07-28/develop/conn...
But sure, you can expend more effort inspecting the source code and documentation than the developers actually spent writing it to verify that it's all safe and well architected.
Ok, end of rant. To be explicit, there's a lot of security issues here, that make it hard to distinguish a malicious actor from a legitimate one:
1- A TLD based in British Indian Ocean territory.
2- A domain name of the product itself, not the entity behind it. (Not how domains work)
3- low value to risk ratio. Some degree of risk is necessary, but if it is done for no benefit, then the acceptable risk becomes lower. It still isn't clear at all what the advantage of mcp is. Maybe when it came out that was my fault, but at this point you have to concede there's a communication or marketing issue, or lack of actual benefit.
4- It's presented as a protocol, but it actually comes with an extensive vibecoded reference implementation, and the code is distributed across multiple repositories, so it's not at all trivial to enumerate where all of the code is, which is a prerequisite to even start static code analysis, leaving one with the only option of runtime analysis, which is a good queue to drop it and not even bother to begin with.
5- The code is vibecoded and auditing would take more time than it takes to actually write it, which is one of the conditions for an amplified DoS attack (on developer attention), the best defense against such attacks is to ignore the packets, so the best path is to ignore content about Model Context Protocol.
Goodbye
are they coming up with an alternative? i use them to monitor workflows that takes days and now i have to make some changes
This protocol change doesn't require you to do anything to existing running MCP code - only if you want to take advantage of new capabilities!
Hallelujah.
It's wild ChatGPT doesn't let you use MCP properly (only really works without a useless developer mode thing in Codex, and Claude it works fine).
Are the HTTP headers for method/name etc even needed at this point and just use urls instead?
e.g. mymcpserver.com/tools/call?mcp-method=search