MCP is dead! Long live MCP
Perplexity's CTO walked away from MCP and the obituaries started. Token waste is real — but so is the need for a contract when LLMs talk to custom APIs. MCP is not default for every case. It is not dead either.
Perplexity's CTO announces dropping MCP and everyone announces its death (MCP's, that is).
I will not claim you should put MCP everywhere, all the time. I myself replaced all of my MCP servers with CLI tools on Claude Code.
Going to the opposite extreme and claiming you should put CLI everywhere does not seem acceptable either.
The pragmatic argument: tokens
The first argument, the most pragmatic one: MCP wastes a lot of tokens.
That is true. But I see two distinct things:
First, it is an architecture problem. Should an MCP server expose one tool per endpoint, or encapsulate a broader business capability?
Second, nothing stops MCP from evolving and fixing the problem, taking cues from what Cloudflare just published.
Pull the thread: why not curl?
Pull the yarn a bit. No need for MCP after all, there is curl:
- Why don't we call curl directly in our apps instead of using HTTP libraries? Same reasoning — use the CLI.
- How do you handle observability on the CLI? Security? Errors?
"LLMs know how to use APIs"
The other argument is that LLMs are very good at using APIs directly:
- How can the LLM know how to use your API?
- Do you give it the OpenAPI?
- Do you split it to give the LLM the input arguments?
- Wouldn't that be... MCP?
Unless the API is in the LLM's training data, I struggle to see how you avoid the same problem by calling APIs directly.
Where each fits
For coding agents, CLI works well because we use standard tools on our machine.
MCP servers are, I think, a better fit for web-facing agents that serve many clients of a service — often custom and unknown to the LLMs.
MCP is not dead in my humble opinion. It is no longer the default answer for every use case, and that is a good thing.
