TL;DR: “MCP is dead” is overstated. The context-bloat complaint was real and big names piled on, but Anthropic’s code execution approach (98.7% fewer tokens in one published workflow), Cloudflare’s Code Mode, and deferred tool loading address much of the original complaint. CLI wins for anything in the model’s training data. MCP still wins for no-CLI services, team auth, and DB guardrails. Pick per job instead of picking a side.
Background:
MCP (Model Context Protocol) is the standard Anthropic launched in November 2024 to plug LLMs into outside tools like GitHub, Linear, Slack, and Notion. It got called the USB-C of AI, every SaaS slapped “MCP supported” on its landing page, and then the backlash started.
The actual complaint: context bloat
When you connect MCP servers, every tool definition loads into the context window up front, used or not. The numbers people throw around are real:
| Claim | What was measured | Source |
|---|---|---|
| 3x slower per call, 9.4x slower on first call | Jira MCP vs hitting the REST API directly | Eric Holmes (Feb 2026) |
| 143K of 200K tokens eaten before the model reads anything | 3 servers (GitHub, Slack, Sentry), ~40 tools | Apideck |
| 4x to 32x more tokens than CLI | MCP vs equivalent CLI calls | Scalekit |
Two interesting bits the internet keeps getting wrong:
- That viral “72% of context” stat came from Apideck, not Perplexity, even though it keeps getting pinned on Perplexity.
- Perplexity only moved internal systems off MCP toward APIs and CLIs (per CTO Denis Yarats). They still run a public MCP server. It’s an optimization, not a cancellation.
Why the CLI argument is strong:
A tool like gh or psql costs almost nothing in context, because the model already learned it from man pages and StackOverflow. Same lookup, wildly different price:
# CLI approach: a couple hundred tokens total.
The model already knows this syntax, nothing preloaded.
gh issue view 1234 —json title,state,assignees
MCP approach for the same lookup: the single tool call is tiny, but the server’s tool definitions sit in context up front whether you use them or not. Quandri measured Linear’s 42 tools at ~12,800 tokens loaded every turn, even when you only call one of them.
Plus you get the same interface for you and the agent, you can pipe through grep and jq, and you can reproduce a bug straight in the terminal. For anything already in the model’s training data, CLI usually wins.
The part the “dead” crowd skips: it already got fixed
In November 2025 Anthropic published “code execution with MCP.” Instead of dumping every tool definition into context, the agent browses tools as code files and loads only what it needs:
servers/ ├── google-drive/ │ ├── getDocument.ts │ └── index.ts └── salesforce/ ├── updateRecord.ts └── index.ts
// The agent writes code, data stays in the sandbox, // only the result comes back to the model. import * as gdrive from ’./servers/google-drive’; import * as salesforce from ’./servers/salesforce’;
const transcript = (await gdrive.getDocument({ documentId: ‘abc123’ })).content; await salesforce.updateRecord({ objectType: ‘SalesMeeting’, recordId: ‘00Q…’, data: { Notes: transcript } });
Result: one workflow went from 150,000 tokens to 2,000, a 98.7% cut, per Anthropic’s own engineering blog. Cloudflare reached the same idea independently and called it Code Mode. Claude Code also shipped tool search with deferred loading that reportedly trims MCP context use by 85% or more.
So when do you use what?
| Use this | When |
|---|---|
| CLI | A real CLI exists and the model already knows it (gh, psql, aws). Lightest, fully composable, debugs in the terminal. |
| Skills (CLI baked in) | Repeatable multi-step workflows. Loaded only when invoked, not every turn. |
| MCP | Web-only SaaS with no CLI, teams needing shared auth and permission scoping, or production DBs where a server enforces read-only and blocks a stray DROP TABLE. |
Bottom line:
It was never really MCP vs CLI. It’s load only what you need, when you need it. The naive “load everything up front” version of MCP is dying, and that’s healthy. The protocol isn’t dead, it’s evolving. The headline is clickbait. The real shift, from connecting everything to teaching the agent to fetch tools on demand, is the actual story.
Comments
Big_River_ · 2026-05-31 · 4 points
people that say MCP is dead are daft - the state of the technology is currently taking two steps back into
special narrow expert exploration ala cursor and other shiny distractions - the state of the art is multitasking multimodal tool augmented fence test master key filing - I am confident MCP has a place in final optimized solution for use cases like anime pron and the other 5% of generative AI use cases are still waiting TBDStrict_Sound_3387 · 2026-06-01 · 2 points
Agreed. The “two steps back into narrow exploration” phase is exactly where I’ve
been living — building small, focused data MCPs rather than trying to do everything.
They’re cheap to run and easy to reason about. Feels less like a step back and more
like figuring out what the protocol is actually good at.
ShilpaMitra · 2026-06-01 · 2 points
You’re right that MCP solves a real problem (standardized tool integration), and it’ll probably stick around for that. Although CLI and similar tools aren’t distracting from MCP, they’re solving a different layer. MCP handles how an AI talks to tools; CLI handles how a human talks to an AI that uses tools. IMO, both can coexist.
tracagnotto · 2026-05-31 · 1 points
I hope so
Strict_Sound_3387 · 2026-06-01 · 1 points
Great breakdown. Worth noting the bloat problem is really a tool-heavy problem —
I’ve built 5 read-only data MCPs with only ~4-5 tools each, and the context cost is
negligible. A narrow single-purpose MCP is already “load only what you need” by design.
SanBaro20 · 2026-06-01 · 1 points
I found that the best time to use CLIs is for fast, local tasks where you own the credentials and MCPs for structured access to external SaaS systems.
You should also build custom wrappers for specific systems. Like for example I’ve cloned the DataForSeo MCP and implemented Code mode from Cloudflare) so that it uses way less tokens for tools discovery.
I mean they have 57 endpoints, so if I were to use their MCP or CLI I would basically be wasting tons of context and tokens.
I hate to self promote but I did write an article exactly on this subject https://vibestacklab.substack.com/p/when-to-use-mcps-clis-or-your-own
ShilpaMitra · 2026-06-01 · 1 points
Hey! I gave it a read, nice write-up. Self-promotion is totally fine once in a while, but I’d also love to see some original posts from you in the sub too 😄
HairyAd9106 · 2026-06-01 · 1 points
ok slightly off-topic, but I used your post to test my own CLI + MCP server. Fed the thread into it and it spat out a slide deck:
https://mcp-is-dead.dropthis.app/
Then I published the same deck twice (once via the CLI, once via the MCP tool) because a “pick per job, not per side” deck deserved to ship both ways 😄
bigbutso · 2026-06-02 · 1 points
If you dont want portability, use CLI