Hacker News Reader

Comment by eric-burel | Hacker News Reader

My understanding is that it can upgrade to an SSE connection so a persistent stream. Also for interprocess communication you usually prefer a persistent connection. All that to reduce communication overheads. The rationale also is that an AI agent may trigger more fine-grained calls than a normal program or a UI, as it needs to collect information to observe the situation and decide next move (lot more get requests than usual for instance).

View on HN

This seems like the solution getting ahead of the problem. A series of API requests over HTTP can easily use a persistent connection and will practically default to that with modern client and server implementations. A claim that a more complex approach is needed for efficiency should be accompanied by evidence that the simple approach was problematic.

MCP can use SSE to support notifications (since the protocol embeds a lot of state, you need to be able to tell the client that the state has changed), elicitation (the MCP server asking the user to provide some additional information to complete a tool call) and will likely use it to support long-running tool calls.

Many of these features have unfortunately been specified in the protocol before clear needs for them have been described in detail, and before other alternative approaches to solving the same problems were considered.

I can't agree more, downloading OpenAPI doc for an API and parse it is more than enough to implement the core of MCP. But sadly the buzzword completely took of and for instance all participants to my trainings will ask for MCP, systematically.

Using SSE was far too inconvenient in theory despite that being how nearly all of the MCP that gained traction was working, so instead the spec was switched to being better in theory but very inconvenient in practice:

https://blog.fka.dev/blog/2025-06-06-why-mcp-deprecated-sse-...

There are a million "why don't you _just_ X?" hypothetical responses to all the real issues people have with streamable http as implemented in the spec, but you can't argue your way into a level of ecosystem support that doesn't exist. The exact same screwup with oAuth too, so we can see who is running the show and how they think.

It's hard to tell if there is some material business plan Anthropic has with these changes or if the people in charge of defining the spec are just kind of out of touch, have non-technical bosses, and have managed to politically disincentivize other engineers from pointing out basic realities.

Reply on news.ycombinator.com