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

41–50 of 57 posts

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

#42

Post by dmix »

jongjong wrote: post #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 po…

The target audience isn't always people who know what curl or a python script is. It's more like an easy to install plugin you can serve up, which tells Claude which endpoints to use via a user asking a generic question (users who dont really understand how anything works behind the scenes).

It's also different than just an API because they have purpose built "tools" which have relevant names (search_campaign vs /api/v3/campaigns?q=xyz), descriptions, annotations (ie, ask used to confirm in ChatGPT before we run this DELETE).

Skills don't really accomplish that well and are more unreliable when your target audience is a B2B customer or person who forgot they installed a Perplexity MCP when Claude will automatically know to use that without invoking a skill.

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

#44

Post by crooked-v »

jongjong wrote: post #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 po…

Arbitrary OAuth built into the spec across the board is extremely useful. It prevents the many, many friction points that come from needing an agent to separately understand the authentication for many different services, or to even know that authentication is happening at all (it happens entirely at the harness level).

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

#45

Post by ghthor »

jongjong wrote: post #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 po…

MCP is good for isolation / security domain. I don’t what my business analysts to pull down a read only DB credentials and make my DB network accessible to them; but I can proxy into a private DB through MCP and guard the MCP with oauth (or tailscale is what I’m using now)

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

#49

Post by kiranravi1995 »

We built ours stateless before the spec allowed it. No SSE at all and GET just returns 405, everything is a plain POST about 46 tools.

We were betting clients would cope, and most of them did. When one did not, we had to tell the user their client was the problem, which is never a good look.

The surprise for us was auth getting easier. No session means no confusion about when the key was checked. Anyone can list the tools and actually calling one needs a bearer token or you get a 401.

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

#50

Post by dbbk »

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

Because the spec wasn't designed it was vibe coded
Post reply on HN