Hacker News Is Arguing Whether MCP Is Dead and the Spec Has a Working Group Named Skills Over MCP

On 3 September someone asked Hacker News a deliberately plain question: who is actually using MCP in production? The post noted that the Model Context Protocol "got a lot of attention early on, but I haven't come across many people using it in production."

It collected 106 points and 126 comments, and the answer turned out to be "lots of people, who cannot agree on whether they should be." Put it next to two bigger threads from the previous five weeks, "New MCP Roadmap" on 22 August (270 points, 161 comments) and "Stateless MCP has recaptured my interest" on 1 August (386 points, 225 comments), and you have 512 comments of the same unresolved fight.

We read all three, then went to look at what the people who write the spec are doing about it. That second part is the story.

The argument, both sides at full strength

The pro-MCP case is not "it is a nice standard." It is that a tool surface you control beats an API surface you do not, and that some runtimes have no shell at all.

The anti-MCP case is not "standards are bad." It is that MCP was designed for models that failed at tool calls, those models improved, and what is left is a token tax plus a server to operate.

Both sides brought concrete reasons, which is why nobody won.

The takes

MitziMoto gave the single most load-bearing answer in the Ask HN thread, and it is the one the CLI camp has no reply to:

"We use MCP in production for our customer facing voice agents... Now we can point any voice agent platform we choose, eleven labs, vapi, pipecat, whatever, at our custom MCP server and it instantly has an understanding of the tools available, their inputs, and how to use it. Compared to the alternatives everyone on HN champions, like clis and APIs, this is a no brainer. I'm honestly not even sure what the realistic alternative would even be. Am I supposed to package and distribute a cli to ElevenLabs?"

rcarmo reported the same thing from the enterprise side, where the value is auditing rather than capability:

"I work with corporate customers, and it has become (literally) the new API management layer, to isolate and audit connections between systems and prevent people from developing random API clients."

insin, who works on an internal LLM chat app at a Fortune 100 company, spelled out why the CLI advice does not apply to a browser-based agent: "CLI isn't an option, direct API is out as the agent deliberately doesn't have any tools for hitting arbitrary URLs."

SegmentTree made the security argument with a specific limitation rather than a slogan:

"We use MCP when security and tight capability boundaries are important. For example, even GitHub's fine-grained tokens aren't always fine-grained enough for our use cases... That gives us a much smaller and more explicit attack surface, without having to manually audit every possible GitHub CLI invocation the agent might make."

Then the other side. latchkey opened the bluntest line of the thread: "I don't understand the need to make things easier for a robot. Point them at an API and they can figure it out."

jadar gave the technical version of that, and it is the strongest anti-MCP argument in any of the three threads because it is about mechanics rather than taste:

"I found that it was really inefficient because if I was doing anything with a significant amount of text, it has to shuttle all of that through the model to the MCP invocation. It was way better to work with temporary files and pipe them around CLI tools once you're happy with the contents."

agentdev001 dissented from inside a team that ships MCP servers for other teams, which makes it the most uncomfortable comment in the thread:

"It feels like there is a significant amount of baggage with MCP. It had first mover advantage, coming in at a time when the frontier looked much different. Models were significantly less predictable, would consistently screw up tool calls... Things are much different now, and I'm frustrated to see that new projects on my team still consider MCP as a reasonable first pass solution for getting data in front of a model."

In the roadmap thread, bensyverson read the new spec features as evidence against them:

"Yes, MCP was already overly complicated, and these new features will make it even more unapproachable. If I need to integrate with a third party service, I'm now skipping their MCP entirely and just going straight for the CLI or API, which are usually more full-featured."

And skinfaxi, reacting to the roadmap's progressive discovery plan, described having already routed around it: "Kind of late to the party. I've had to implement lazy loading of mcps in a couple of harnesses now but am moving to implement everything as code mode instead."

The best rebuttal came from danappelxx, answering someone proposing a long-lived token in a secret manager instead of MCP's auth machinery: "You'll likely end up reinventing something pretty close to what MCP is building towards. Authn/authz is one of those things that can be really simple for pointed use cases but gets really complex when you need to support everything."

Where the two venues disagree

Here is the part we went looking for, because a thread is only a thread.

Hacker News is debating whether skills and CLIs make MCP redundant. Over in modelcontextprotocol/modelcontextprotocol, the 9,132-star spec repo, that debate is not a debate. It is a chartered working group with a name that gives the whole thing away: Skills Over MCP.

We pulled its discussions through the GitHub API. It has posted meeting notes since at least 21 April 2026, running through 2 June, 16 June, 30 June, 28 July, 11 August and 25 August. Its output is SEP-2640, a Skills Extension on the Extensions Track. The 25 August notes, posted by co-lead olaservo, list the room: Peter Alexander of Anthropic and a core maintainer, Ola Hungerford of Nordstrom, plus attendees from Microsoft, Adobe, Glean and Slack.

Those notes are also more empirical than either HN thread. Working through per-skill size limits, they record that Peter "surveyed roughly 10,000 popular skills" and that a cap of 512 resource entries and 16 MiB per skill "covered essentially all of them; about two did not fit, one because it shipped a large video file."

The rest of the repo's idea categories tell you where maintainer attention actually sits, and it is not on whether MCP survives. Recent threads include a proposal for standard audit context for AI-initiated tool invocations (33 comments), a permission specification for tool calls (32 comments), a report measuring the auth and capability posture of 13,000 public MCP endpoints, and a finding that readOnlyHint can be enforced at runtime. Security, permissions, identity.

So the two venues are answering different questions. Hacker News asks "should I run an MCP server or a CLI?" The spec repo has moved on to "how do skills get delivered and signed, and how do we stop a host from fetching every file on connect?" One of those is a tooling preference. The other is an ecosystem design problem, and it presumes the answer to the first.

The best comment nobody upvoted

Buried four levels deep in the roadmap thread, after several people declared code mode the obvious successor, rixed asked the only question that would settle any of it:

"Are you aware of any quantitative data to back up the claim that llms are more performant in code mode than mcp mode? Not that i doubt it, but I'm curious about how big of a difference it can make."

Nobody produced any. Across 512 comments we found no benchmark comparing MCP tool calls against equivalent CLI or code-mode execution on the same task: not token counts, not latency, not success rates. The most confident claims in this argument, on both sides, are the least measured, and we are including our own position in that.

Our read

The CLI camp is right about their own machines and wrong about the general case, and they keep making the same slip: describing a workflow where the agent has a shell, a filesystem and a package manager, then generalising it to everyone.

Look at who defended MCP hardest. Voice agents on a third-party platform. A browser-sandboxed agent at a Fortune 100. Enterprise gateways that need to answer who did what, for compliance. Nobody in that group has a shell to fall back on. jadar's file-piping argument is completely correct and completely unavailable to someone shipping to ElevenLabs.

MCP's competitor was never the CLI. It was the shell the CLI runs in, and a large share of MCP's real users do not have one.

That also explains the maintainers' behaviour, which otherwise looks like surrender. If skills are the better way to hand an agent a capability where a filesystem exists, then a protocol whose job is reaching runtimes without one should standardise how skills get delivered, verified and size-bounded. Naming the group Skills Over MCP is not a concession. It is a scope correction.

What would change our mind: the benchmark rixed asked for. If someone measures MCP against code mode on identical tasks and the token difference turns out to be small, the anti-MCP case loses its only mechanical argument and this becomes a plain preference fight. If it is large, the local-dev retreat accelerates and MCP ends up a protocol you never see because it lives inside a vendor's voice platform. We would take the second bet, and we would rather have the numbers.