The “MCP is dead” take has been circulating for a while: agents are getting good enough at using ordinary command-line tools that standing up a Model Context Protocol server for them looks like ceremony. Paul Iusztin pushed back on it this week, and his framing is the one I want to keep: the technology is not defunct, it is being evaluated against the wrong problem.
I think that is right, and I think the reason it is right is more specific than “enterprise needs governance.”
The argument, compressed
For one engineer on one laptop, a CLI genuinely wins. There is no process to run, no
transport to debug, no auth to configure, no schema to keep in sync with the function it
describes. The agent discovers the interface by reading --help, the same way I would.
Connecting a model to Obsidian or Readwise this way is a twenty-minute job, and an MCP server
for the same thing is not twenty minutes.
The counter-argument, in Iusztin's words, is to “try scaling that across a company deploying thousands of AI agents.” That is where the CLI answer stops being obviously cheaper.
What the CLI answer quietly assumes
Every argument for the CLI is load-bearing on four assumptions that hold on a laptop and fail in an organisation:
- One machine, which you administer. Installing a tool is
brew install, not a fleet rollout. - One identity. The tool inherits your credentials, and your credentials are the right ones.
- Updates propagate because you pull. There is exactly one copy of the logic, and you are looking at it.
- A wrong tool costs you an afternoon, not a compliance incident across every team that happened to install it.
None of those survive contact with a thousand agents and several hundred people. The question stops being how does a model invoke this function and becomes where does the one true definition of this function live, and who is allowed to change it.
The real axis: who owns the tool definition
| One laptop | One organisation | |
|---|---|---|
| Install | you, once | every machine, forever |
| Update path | git pull | redeploy one server, everyone moves |
| Credentials | yours, already on disk | held centrally, never handed to the agent |
| Audit | shell history | a request log with an identity attached |
| Blast radius of a bad change | your afternoon | every agent that calls it |
Read that way, MCP is not a smarter calling convention. It is a distribution boundary —
the same reason companies expose an internal service instead of letting every team write its
own query against the production database. Nobody argues that HTTP APIs are dead because
psql exists on your laptop. The laptop was never the case the API was built for.
The protocol question is downstream of an ownership question: how many people have to agree when this tool changes?
If the answer is one, write the CLI. If the answer is four teams and a security review, you are going to build the server eventually, and doing it late is more expensive than doing it early.
Where I would push back on both sides
Both camps are arguing about invocation. Neither is arguing about verification, which is the part I actually spend my time on.
Whether the model reaches a function through a subprocess or a JSON-RPC session,
nothing in either path tells you whether calling it was the right decision. A tool call that
returns 200 is not a tool call that should have happened. The failure mode I keep
seeing is not a broken transport; it is an agent confidently selecting the wrong tool, or the
right tool with the wrong arguments, and the plumbing dutifully reporting success.
That is a measurement problem, and it looks a lot like the offline-evaluation problems I work on elsewhere: the system scores well on the traffic it was demonstrated against and behaves differently on the traffic it did not choose.
What I would want to measure
- Selection accuracy against surface area. Does tool-choice accuracy degrade as one server exposes 10, 30, 60 tools? I would expect it to, and I have not seen a number I trust.
- Cost of discovery. Schemas in context every turn, versus
--helpread once — which is actually cheaper across a long session? - Version skew. When the server updates and an agent's cached idea of the interface does not, does it fail loudly or quietly? Quietly is the expensive answer.
Open questions, not conclusions. This is a first draft of a thought, written the day I read the post that provoked it.