"MCP is dead" is right about your terminal and wrong about your product | Portkeel
“MCP is dead” is correct about solo developer workflows and wrong about product integrations, and the difference is measurable. The criticism comes from developers running coding agents, where loading a tool schema costs more context than a direct CLI call; one analysis found four common servers consuming over 21,000 tokens before any work. That describes a terminal. It does not describe a SaaS exposing its product to customers who already live in Claude and ChatGPT.
What the critics measured, with the numbers
The strongest version of the argument is real. A prominent CLI-over-MCP post topped Hacker News, Perplexity’s CTO said publicly they were moving away from MCP over context consumption, and Thoughtworks placed naive API-to-MCP conversion in the Hold ring. The token figures are not invented.
Where the argument stops
Every one of those cases is a developer optimising a personal workflow. The person has the CLI, the model, and the terminal, all under their control. Collapse that into a single script and MCP is overhead.
Why product integration is a different case
| Dimension | Solo terminal | Product integration |
|---|---|---|
| Who runs the client | You | Your customer |
| Number of clients | One | Many, unowned |
| Cheaper alternative | A CLI call | None; you do not own their client |
| Verdict | MCP is overhead | MCP is the only path |
Tool search changed the math
The context objection is also getting weaker. Tool-search and deferred loading mean a client no longer pays for every tool schema up front, which cuts the overhead the critics measured. The honest way to show that is a before/after on a real server.
What would actually kill MCP
Not a Hacker News thread. A better standard that more clients adopt would, and none exists yet. Until then, if your customers are in an assistant, the question is not whether MCP is dead but whether you should build the server yourself and what it costs. The numbers are on the pricing page.