Hermes[^1] sent me a digest summary today:
a Quandri post arguing MCP is dead, and the Hackernews thread it triggered. https://news.ycombinator.com/item?id=48330436, https://www.quandri.io/engineering-blog/mcp-is-dead
Their argument is that MCP uses too much context, is unreliable, and that the CLI is almost always the better choice. Hacker News pushed back hard, although much of the pushback felt surprisingly weak.
Hermes said "MCP is a bad idea."
I would not go that far, but the case against MCP feels much stronger than the case for it. The number of MCP servers being built signals hype, not quality.
the CLI wins in token efficiency
gh --help gives an agent everything it needs in around 600 tokens:
The GitHub MCP server burns 6k+ tokens on tool descriptions alone:
For GitHub's use case, that is a lot of overhead for little benefit. The MCP server GitHub provides does not do anything magical. It is not simpler, more reliable, or faster. It exists because GitHub could build it. Newer MCP versions have Tool Search, but that feels like a band-aid over a flawed architecturehttps://www.anthropic.com/engineering/advanced-tool-use.
even better: CLI + Skill
The winning pattern is CLI + Skill. A compact Skill file tells the agent how to use the tool.
The agent calls the CLI directly. There is no JSON-RPC layer, server process to babysit, or discovery overhead. A skill needs to stay current with a changing CLI, but that seems like less work than maintaining an MCP server.
A heavy structured protocol for a machine that already parses plain text all day, without issue, feels like architecture solving a problem the model no longer has.
but companies are building more MCP servers than ever
Someone from the ChatGPT marketplace team pointed out a market signal:
The reason MCP isn't dead is because practically ~every company on the planet is building an MCP server. I know this because we interact with all of them. Most of these companies don't have a CLI. Many of these companies don't even have an external API! And yet, they're all building MCP servers. https://news.ycombinator.com/item?id=48330710
That is a market signal and a hype indicator, but it is not necessarily a quality signal. AWS builds a service for everything, too. You have probably not heard of 90% of them because you do not need most of them.
The data points in the same direction. At peak hype in mid-2025, there were roughly 25 builders for every actual user, and many early servers became ghost towns. 5,500 MCP servers shows that people built them, not that people kept using themhttps://glama.ai/blog/2026-01-20-mcp-is-not-dead, https://mcpmanager.ai/blog/mcp-adoption-statistics/. At least some of it looks like FDD, FOMO-driven development.
the one exception
You probably know that in the Claude Desktop app, or on Claude.ai, you can ask Claude to "visualize" something, and it will generate a rendered output, like this:
That is MCP. The visualize capability in Claude's chat is MCP-powered, and there is no CLI equivalent.
It is a rendered UI component delivered into the conversation context. This part of MCP is called "MCP Apps", which is a specific subset of MCP that is designed for this use case.
A CLI cannot render interactive UI components. At most, some modern terminals can show images.
Excalidraw MCP belongs in the same category: tools whose primary output is a rendered interface, not data. MCP earns its keep there.
If a tool outputs a rendered UI component and has no CLI path to the same result, MCP can make sense. Otherwise I would reach for CLI + Skill.
The irony of making an anti-MCP argument using an MCP tool is not lost on me.
visualize without MCP?
Yup, I just said CLIs are not particularly good at rendering interactive UI components, but that doesn't mean it's impossible. Actually, there is a pretty smart way to do it. Michael Livshits reverse engineered the Claude Visualize Tool and built a pi extension, that renders the SVG or HTML output of an agent, within the terminal, with Glimpse, a macOS native micro ui, rendering the output in a separate WKWebView window. It's not as seamless as the MCP version, happens not directly inline, but it is pretty close, and it is a great example of how you can achieve similar results with a CLI + Skill approach, without the overhead of MCP. https://michaellivs.com/blog/reverse-engineering-claude-generative-ui/, https://github.com/Michaelliv/pi-generative-ui, https://github.com/hazat/glimpse
This only works on macOS for now. It is straightforward to set up, but the hurdle is much higher than Claude Desktop's built-in MCP solution.
where this leaves us
MCP is not going away. The spec is under the Linux Foundation now, OpenAI and Google both backed it, and it is the default plumbing for anything calling itself an AI assistant in 2026https://www.linuxfoundation.org/press/linux-foundation-announces-the-formation-of-the-agentic-ai-foundation.
But "default plumbing" and "right choice for your agent" are different things.
The split is fairly clean. Tools with a CLI should generally use CLI + Skill. Tools with an API but no CLI should usually be called directly over HTTP. Tools where the output is a rendered interface with no meaningful CLI equivalent are where MCP comes into play.
Most things people are wrapping in MCP fall into the first two buckets. The standardization argument is real, but it does not justify the context overhead when an agent only needs to close a pull request.
The test is simple: does the tool render a UI? If not, use the thinnest integration layer that works. If it does, MCP may be the right tool.
[^1]: Hermes is my personal agent, sending me personal daily briefings, managing my calendars, etc.