This was the easiest call and many like me made it in March[0] among all of the anti-MCP wave of influencers claiming it dead (many, many prominent folks in tech including Garry Tan). Literally every tech influencer in every social feed in March was calling MCP dead and crowning CLI the winner (completely ignoring every reasonable argument around security, observability/telemetry, ease of deployment and operations, etc.)
A direct quote from March, 2026[1]:
> If you’re still not convinced that a lot of this discourse [regarding the death of MCP] lacks nuance and is just hype, congrats on buying into the current AI-influencer FOMO hype cycle; see you in 6 months when the influencers move on to the next revelation of the moment to stay relevant and get your eyeballs and dollars.
It was fairly obvious why MCP would be needed once AI engineering and uptake moved beyond the solo developer and single harness stack of "what works for Me" versus "what works for My Team", particularly in an enterprise context. The key mistake people made was thinking in terms of their own workflows and own local stacks instead of a team's workflow and a team's operational stack. There was also an ignorance of MCP's stateless HTTP mode (yes, it was already a thing in March; the 2026-07-28 revision of the spec just prioritizes it as the primary focus moving forward) versus local `stdio`.
My biggest complaint right now is that OpenAI has still refused to implement the MCP Prompts spec[2] and in general, the major clients have spotty implementation for some of the features in the spec.
Yep, number of new MCP servers this month is on track to be the highest it has ever been: <a href="https://bloomberry.com/data/mcp/" rel="nofollow">https://bloomberry.com/data/mcp/
"MCP" is the new "API" (MCP over streaming HTTP, after all, is just an API with a structured payload wrapper and defined interactions).
It is only going to continue to proliferate in usage and adoption.
With the v2 spec, MCP became a lot closer to APIs by becoming stateless. And there is now a push to use HTTP verbs more extensively to improve caching even better in v3.
MCP is converging into APIs but wit great auth and auditing
I'm not trying to be a dick, but it's pretty hilarious that we made these two posts at the exact same time [0]. I totally get what you're saying, but I don't understand the motivation behind it. A properly designed HTTP API is what Roy Fielding was discussing in his dissertation, but he was obviously talking about HTML pages full of hyperlinks. At the end of the day, does it really matter much if the definition is only 80% correct if the majority of the population understands the basic gist of the conversation?
If you can build the ultimate evolvable client, then you can collapse all UI into a single client.
Basically Roy Fielding told us to build an API that can only be operated by a human like intelligence, nobody could implement that because such an intelligence did not exist (hence the switch to imperfect HTTP APIs), and now that LLMs are a thing, said human like intelligence exists. This means Roy Fielding wasn't wrong, he was 25 years too early and ironically people should be building real REST APIs in the pendantic academic sense from today on and not the "pragmatic" HTTP API.
CharlieDigital · · focus · HN ↗
A direct quote from March, 2026[1]:
It was fairly obvious why MCP would be needed once AI engineering and uptake moved beyond the solo developer and single harness stack of "what works for Me" versus "what works for My Team", particularly in an enterprise context. The key mistake people made was thinking in terms of their own workflows and own local stacks instead of a team's workflow and a team's operational stack. There was also an ignorance of MCP's stateless HTTP mode (yes, it was already a thing in March; the 2026-07-28 revision of the spec just prioritizes it as the primary focus moving forward) versus local `stdio`.My biggest complaint right now is that OpenAI has still refused to implement the MCP Prompts spec[2] and in general, the major clients have spotty implementation for some of the features in the spec.
[0] <a href="https://news.ycombinator.com/item?id=47380270">https://news.ycombinator.com/item?id=47380270
[1] <a href="https://chrlschn.dev/blog/2026/03/mcp-is-dead-long-live-mcp/" rel="nofollow">https://chrlschn.dev/blog/2026/03/mcp-is-dead-long-live-mcp/
[2] <a href="https://github.com/openai/codex/issues/5059" rel="nofollow">https://github.com/openai/codex/issues/5059
AznHisoka · · focus · HN ↗
CharlieDigital · · focus · HN ↗
It is only going to continue to proliferate in usage and adoption.
Eldodi · · focus · HN ↗
Zambyte · · focus · HN ↗
imtringued · · focus · HN ↗
Do you mean the Roy Fielding "REST" or the HTTP API "REST"?
Calling the latter "REST" is wrong. It's like calling a hermit crab a snail.
Edit: I forgot to mention, the former is gaining relevance as the elusive evolvable clients are now a thing.
jazzypants · · focus · HN ↗
[0] <a href="https://news.ycombinator.com/item?id=49908582">https://news.ycombinator.com/item?id=49908582
imtringued · · focus · HN ↗
If you can build the ultimate evolvable client, then you can collapse all UI into a single client.
Basically Roy Fielding told us to build an API that can only be operated by a human like intelligence, nobody could implement that because such an intelligence did not exist (hence the switch to imperfect HTTP APIs), and now that LLMs are a thing, said human like intelligence exists. This means Roy Fielding wasn't wrong, he was 25 years too early and ironically people should be building real REST APIs in the pendantic academic sense from today on and not the "pragmatic" HTTP API.