Live data from Hacker News

MCP 2026-07-28 Specification: transport going stateless

blog.modelcontextprotocol.io

31–40 of 58 posts

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

#31
post #23
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…

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.

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

#32
post #9
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!

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

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

#36
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

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

#38
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.

Post reply on HN