The "MCP Is Dead" Fight Is a Category Error

Skills win the solo dev. MCP wins exactly one thing. Here’s the line.

I had the headline before I had the post.

“API + Skills Is a Poor Man’s MCP” — except I was going to argue the inversion: that MCP is the rich man’s overcomplication, a server process you stood up to wrap calls your agent could already make, and the lean move was always a skill plus a CLI. Spicy. Contrarian. The kind of take that does numbers in a feed.

Then I made the tactical error of fact-checking myself, and the post fell apart in my hands. What follows is the wreckage, reassembled into something truer than the dunk I wanted to write.

TL;DR: Skills and MCP aren’t competitors — comparing them is a category error. A skill is a recipe that runs in your runtime; MCP is a connection to a hosted service. For a solo dev wiring up their own workflow on a coding agent, skill + CLI wins on every axis that used to favor MCP — the context-bloat and cross-vendor arguments both got quietly erased in late 2025/early 2026. MCP earns its keep in exactly one situation: you’re a provider exposing a live, OAuth’d service to assistants you don’t own. The rule that falls out: consuming an API → skill + CLI. Providing a service → MCP.

The category error I was about to commit

The first crack: “API + skills vs MCP” quietly assumes the two live on the same shelf. They don’t.

A skill is knowledge. A markdown recipe — plus maybe a script — that teaches the agent how to do something, running in your runtime, on your machine, with tools you already have.

MCP is a connection to a running service. A server, behind a protocol, that the model talks to.

Comparing them is apples to orchards. One is “here’s how, go do it.” The other is “here’s a thing that’s already running, call it.” Most of the internet argues about them as if they’re competing products. They’re not even the same noun.

So the honest question isn’t “which wins.” It’s “when does a hosted service behind a contract beat a recipe you run yourself?” That’s a real question. I just assumed I knew the answer.

The two arguments that died before I finished typing

My case against MCP rested on two pillars. Both had already collapsed, and I hadn’t noticed.

Pillar one: context bloat. Every MCP server dumps all its tool schemas into the context window — a seven-server setup could eat 67K tokens before you typed a word, and the context window is the one resource your agent can’t buy back. Damning. Except in January 2026 Anthropic shipped tool search and defer_loading: now the model sees a search tool plus a couple of always-on tools, and pulls the rest on demand. Reported reductions of 85–95%. My killer stat became a “this used to be true.”

Pillar two: cross-vendor reach is MCP’s moat. Wrong by a different calendar. In December 2025, Agent Skills shipped as an open standard, and within 48 hours Microsoft put it in VS Code and OpenAI added it to ChatGPT and Codex. By spring, ~40 tools — Gemini CLI, JetBrains, Kiro, Goose — read the same SKILL.md. Skills are as universal as MCP now. The moat drained while I was sharpening my knives.

Fine. Two pillars down. The dunk still had three legs, I figured.

Watching the rest fall

Security? I’d claimed MCP gives you a safety edge. It doesn’t. If I want read-only GitHub access, I hand a read-only token to the skill or the MCP server — identical. The token scope is the gate, enforced at the API boundary, available to both. There’s no protocol-level security advantage. Gone.

Tokens? This one inverts, which delighted me until I realized it cut against my own thesis too. People assume MCP is token-cheap because the call — list_pull_requests(owner, repo) — is tidy. But the call isn’t the cost. The result is. The GitHub API returns fat JSON, and a raw MCP tool call dumps the whole blob into context. A skill that runs code can filter in the sandbox and return five lines. So code-that-filters wins on tokens — and a skill is code-that-filters by birth. But that’s an argument for skills, not against MCP-the-idea.

Auto-orchestration? “MCP composes calls for you.” No, it doesn’t. The protocol is transport — it has no “run this sequence, give me only the end” primitive. Either the model loops (every intermediate result round-trips through context — expensive) or a human pre-bakes a coarse server tool (effort). Automatic, token-cheap stacking only happens when you call tools from code — which is, once again, the skill model.

Every road kept leading back to the same place. I started to feel like the universe was trying to tell me something(sounds dramatic, I know).

The litmus test that almost saved the dunk

So I built a concrete test: “Fetch all open PRs, give me a gist of the modules they touch, merge only the ones tagged auth.”

Fetch and gist are reads — data-heavy aggregation, the code-that-filters sweet spot. Skill wins, easily. But merge is a write, and a dangerous one, and writes are where I figured MCP’s permission policy — pause and confirm each merge — would finally earn its keep.

Then a reader on the thread that became this post pointed out the obvious: gating decomposes into three questions, and only one is even arguably MCP’s.

• Capability — can a merge happen at all? The token scope answers that. Available to both. API-enforced.
• Selection — which PRs get merged? Your filtering code answers that. That’s the skill’s script.
• Confirmation — do you approve each one? You, in the loop on a coding agent — or a --confirm flag — or MCP’s native prompt.

Only the third row is MCP’s, and even there it’s matched by you-watching-bash or a confirm flag. On a coding agent with you present, skill plus the gh CLI wins the whole task. The merge didn’t flip it. You’re the permission policy.

That was the moment the dunk officially died. I went looking on Reddit to see who else had buried it.

What Reddit already knew

Turns out, everyone. The threads are a graveyard with two opposing headstones.

“Will MCP be dead soon?” — 406 comments. “I cannot, for the life of me, understand the value of MCPs” — 305 comments. “A eulogy for MCP (RIP).” “CLI > MCP?” Someone even shipped a tool that converts MCP servers into CLI + skill files and “cut ~97% token overhead.”

The auto-generated TL;DR of that 305-comment thread is, embarrassingly, the post I’d spent a day reverse-engineering: “You’re looking at this from a solo dev’s perspective, and you’re not wrong — Skills or telling Claude to use a CLI is often more efficient. MCP’s real value isn’t for your individual coding session, but for the broader ecosystem.”

So the solo-dev case is settled. But the people defending MCP weren’t demo-app tourists. They were running it in production, and they landed one punch I couldn’t slip.

The punch I couldn’t slip, and the one real win

From the eulogy thread, top comment: “People who claim there’s no need for MCP will, if they build projects of growing complexity, sooner or later reinvent everything MCP provides — but bespoke and non-standardized.” And a sharper one: “CLI + skills are great for solo dev vibes. But the second you need an LLM to orchestrate across multiple platforms with real auth and governance? You’re either using MCP or rebuilding it badly.”

That’s the one thing that survived every round. Not context, not security, not reach, not tokens. Distribution — of a specific kind.

Here’s the case, and it’s narrower than the hype and realer than my dunk: you’re a provider. You host a live service and you want it to show up as a one-click, OAuth’d connector inside every AI assistant your customers already use — Claude’s Connectors Directory (200+ integrations), ChatGPT Apps, all of it. Notion, Linear, and Stripe ship official remote MCP servers for exactly this. You build once; it lights up everywhere; the credentials and compute stay on your side.

A skill — even a universal one — cannot be that. A skill is a copy that runs in the consumer’s runtime, and that’s the whole limitation: it can only do what that runtime can do. Flip that around and you get the same win seen from the client’s side. Claude Desktop runs skills and has a code sandbox — but the sandbox can’t reach the open internet, so a skill that tries to curl GitHub dies at the egress wall, while an MCP server, running outside the box, reaches it fine. Same task, opposite answer, deciding variable is network egress. It’s not a second reason to use MCP. It’s the first reason wearing a different hat: when the consumer’s runtime can’t reach the thing, you need a service that can.

The rule: when to use MCP vs a skill + CLI

So, do you need MCP? Ask one question: are you consuming an API, or providing a service?

Wiring your own agent to someone’s existing API, on a coding tool with a shell — skill plus a CLI, every time. You will not “reinvent MCP badly,” because you need none of what MCP provides: no OAuth dance, no dynamic discovery, no cross-client reach. The CLI is complete, not a degenerate clone.

Exposing your own live service to assistants you don’t own, with auth and governance, across vendors — that’s MCP, and a CLI genuinely can’t do it.

MCP isn’t the poor man’s anything. It’s the platform’s protocol. You reach for it the moment you stop consuming APIs and start being an app inside other people’s assistants.

I know which side I’m on this week. I shipped ThreadHQ’s MCP server as a top-of-funnel for a reason — that’s the provider play, done on purpose. (ThreadHQ is one of the products I built solo with Claude Code; the MCP server is its distribution edge, not its plumbing.) But for the GitHub task on my own machine? I’m still just typing gh. The dunk was wrong. The honest version is sharper anyway.