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.
It's annoying, but that's been pretty common for the last decade. It's just like how everyone uses "REST" to mean "JSON RPC". In the end, we all basically know what the other ones are talking about, so it's pretty pointless to get bogged down in semantics.
It's common when talking about web services, where the kind of API is generally unambiguous. The problem here is we're discussing different kinds of APIs (shell commands, MCP, REST / JSON RPC) and so calling one of those kinds of APIs "API" is very confusing.
Exactly. It's confusing to talk about MCP vs API when "API" describes the whole class of possible values, of which "MCP" is one of them.
MCP is not strictly an API; it's a protocol shape (thus the "P" for Protocol) for delivering an API.
The API surface exists in the MCP payload.
Whereas application teams previously would have focused on APIs for external access, they now have to focus on MCP entry points (often to those same APIs, but with a different shape).
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.
jazzypants · · focus · HN ↗
Zambyte · · focus · HN ↗
natpalmer1776 · · focus · HN ↗
leptons · · focus · HN ↗
Zambyte · · focus · HN ↗
CharlieDigital · · focus · HN ↗
The API surface exists in the MCP payload.
Whereas application teams previously would have focused on APIs for external access, they now have to focus on MCP entry points (often to those same APIs, but with a different shape).