2026-05-30

Why This "MCP Is Dead" Take Matters for Claude Code Users

For Claude and Claude Code developers, this article hits a nerve because it’s not arguing against tool use itself — it’s arguing against a specific way of packaging tools that can be expensive in context, brittle in practice, and awkward to debug. That’s a useful distinction: if you care about building real workflows for Claude, the question is less “MCP or not?” and more “what’s the lightest reliable interface for this job?”

Key Points

The Quandri engineering team tested MCP on their own stack and concluded that MCP has three main problems:
- it consumes a lot of context window,
- it can be unreliable operationally,
- and it often overlaps with existing CLI/API options.
They note an important update: Claude Code’s Tool Search with Deferred Loading reduces MCP tool-schema context usage by 85%+, which addresses much of the context-bloat problem they measured. The other issues, they say, still remain.
Their measurements showed that with 4 MCP servers connected, tool definitions alone used about 10.5% of a Claude 200K context window and about 16.5% of a GPT-4o 128K window.
Linear was the biggest offender in their environment, with 42 tools and roughly 12,807 tokens of tool definitions.
They argue the operational downsides are real: init failures, repeated re-auth, slower responses, mid-session server crashes, and opaque permissions.
The article cites prior benchmarking that found Jira MCP was 3x slower per call than the REST API, and 9.4x slower on the first call including initialization.
A central argument is that CLI/API access is often a better fit because it is:
- the same interface humans already use,
- easier to compose with pipes, jq, and grep,
- easier to debug in the terminal,
- and already familiar to models from docs and public examples.
Their token comparison is stark: looking up a Linear issue via MCP cost roughly 65x more tokens than doing it with curl against the API, mostly because MCP loads tool definitions upfront.
They propose two alternatives:
- a CLI-first strategy, where LLMs use CLI/API/docs directly,
- and Skills, where instructions for a workflow are loaded only when needed.
Their example Linear Skill wraps the API and curl instructions so the model only gets those details on demand rather than carrying every MCP tool definition all the time.
They don’t call MCP completely useless. They still see value when:
- no CLI exists,
- the target user is non-technical,
- or real-time bidirectional communication is required.
For databases, they take a nuanced stance:
- local dev and personal DBs: Skills + CLI are usually enough,
- production or shared team DBs: MCP can be worth it because it can enforce read-only behavior and protect credentials at the server level.
Their actual practice at Quandri is hybrid:
- Bash + CLI for tools like gh, psql, aws,
- Skills for repeatable workflows like commit drafting and PR reviews,
- MCP for Slack, Linear, Notion, and cases where team auth or permission scoping matters.
Their conclusion is pragmatic: teach well, load only what you need, and keep debugging in the terminal when possible.

My Take

What strikes me is that this is not really an anti-agent argument at all — it’s a strong “don’t make the model carry unnecessary baggage” argument. I think that’s a much healthier framing for Claude Code users than the usual protocol-vs-protocol tribalism, because in practice the best developer experience is the one that gets out of the way and fails visibly.

I also think the context-window critique is the most immediately convincing part, even though Claude Code’s newer deferred-loading behavior seems to blunt it quite a bit. The article still makes a broader point that matters: even if you fix the token cost, you haven’t automatically fixed reliability, process overhead, or the pain of debugging something that only exists inside a chat session. That part feels very real.

What I’d actually do, as a Claude user, is pretty close to their hybrid setup. I’d use CLI first whenever the tool already exists and the workflow is simple enough to express cleanly in a skill. I’d reach for MCP when I need server-side guardrails, shared auth, or a service that would otherwise be awkward to script safely. That seems more honest than pretending one abstraction should win everywhere.

I’m a little skeptical of the “MCP is dead” headline — that feels deliberately spicy — but the underlying critique is fair. If anything, the more interesting takeaway is that Claude-native workflows are maturing: not just “connect everything,” but “load less, explain better, and keep the real operations surface where developers can inspect it.”

The bottom line: MCP is still useful, but this article makes a strong case that it should be the exception, not the default. For Claude Code builders, the real win is choosing the smallest reliable interface for the task — and sometimes that’s just bash, curl, and a well-written skill.