Why engineers are ditching MCP servers — and the three things they use instead

Two videos shipped in November 2025 with directly opposing framings of the same protocol. On November 10, IndyDevDan published “Why are top engineers DITCHING MCP Servers?” — arguing that MCP servers bleed context tokens before your agent even starts working and presenting three alternatives. Eleven days later, on November 21, Christian Lempa published “MCP Tutorial: Connect AI to your HomeLab” — a clean walkthrough of using MCP to connect AI to GitHub, Cloudflare, n8n, and self-hosted services.

Both are right. The reconciliation is the more interesting story than either video alone.

This piece works through what IndyDevDan’s video actually says, why his three alternatives matter, when Lempa’s adoption framing is correct, and how to think about MCP in November 2025 as a working engineer.

What IndyDevDan’s video actually argues

The viral framing — “engineers are ditching MCP” — is sharper than the substance. Dan’s actual argument is more nuanced:

“Your MCP server is BLEEDING context tokens before your AI agent even starts working. There’s a better way — three proven alternatives that companies like Anthropic and leading agentic coding engineers use every day to maintain control and preserve context.”

The mechanism is the context tax. When you load an MCP server into Claude Code (or any agent), the server registers its tools, schemas, and metadata into the agent’s available-tools context. This is non-trivial — a single MCP server with 30 tools can eat several thousand tokens just from the registration. Load 5-10 MCP servers and you’ve spent 20-50% of your context window before the agent has read a line of your code.

For interactive sessions where the user knows which servers they’ll need, this is acceptable overhead. For background agents running in sandboxes with a fixed budget, it’s a meaningful tax. Dan’s three alternatives:

1. CLI as Tools. Make the functionality available as command-line invocations the agent can shell out to. Build once, use everywhere — humans, agents, scripts. No MCP server needed; the agent calls gh pr list directly via its bash tool. Context cost is the prompt to “use the gh CLI” not the entire schema registration.
2. Scripts as Tools (progressive disclosure). A small script that the agent reads on demand only when it needs the functionality. The script contains the schema, the implementation, and the example usage all in one file. Agent reads the script when it needs the tool, ignores it otherwise. Context cost is zero until invocation.
3. Claude Agent Skills. A Claude-specific evolution where capabilities are packaged as composable “skills” that load when the agent recognizes the relevant task. Dan’s companion video on Agent Skills goes deeper on the patterns. Context cost is registration overhead that’s much lighter than an equivalent MCP server.

The Mario Zechner blog post Dan links — “What if you don’t need MCP Server?” published November 2 — makes the same argument in more academic form. The pattern is genuinely emerging, and Dan’s “top engineers” framing isn’t marketing puff. Anthropic themselves published a Code execution with MCP engineering post that effectively recommends the “CLI as Tools” pattern over heavy MCP server stacks for specific use cases.

What Christian Lempa’s tutorial gets right

Eleven days later, Lempa published an MCP tutorial that’s the polar opposite framing. Connect AI to your HomeLab, your DevOps workflows, your external tools using MCP — including practical examples with GitHub, Cloudflare, n8n. Watch this video and you’d think MCP was the obvious right answer.

Lempa isn’t wrong. The use cases he demonstrates — connecting AI to discrete, well-defined external services with stable APIs where the user wants persistent access from any session — are exactly what MCP is good at. The GitHub MCP server. The Cloudflare MCP server. The n8n MCP server connecting to thousands of pre-built workflow integrations. For a homelab user who wants their Claude or Codex CLI to reliably access their self-hosted services across many sessions, MCP is the right primitive.

The audience for Lempa’s tutorial — homelab enthusiasts integrating AI with their personal infrastructure — is genuinely different from the audience for Dan’s video — agentic coding engineers running sandboxed agents on context budgets.

Lempa’s audience: I’m a human who wants to reach my services from my AI tools. Set up once, use forever. MCP is correct.

Dan’s audience: I’m an engineer running 15 parallel sandboxed agents and every context token costs me a real dollar in API spend. MCP is overkill for any tool I’m not using this session.

The reconciliation isn’t “one of them is wrong.” It’s that MCP is a tool with specific tradeoffs, and which side of those tradeoffs matters depends on whether your bottleneck is convenience or context economy.

The Reddit reality: messier than either framing

The 4393-upvote December r/ClaudeAI thread on Anthropic donating MCP to the Linux Foundation captured the bigger context. The community sees MCP as legitimately important enough to standardize. Top comment: “I’mma be real — I am sure they have self interested reasons — but this is a likely win for AI consumers. More standards detached from the AI vendors themselves, the better.”

But the more interesting comment came in at 54 upvotes:

“The only reason they are doing this is basically they’ve concluded it’s a dead end. Claude being trained to search for skills made it obsolete for context efficiency. MCPs have a very specific use case with establishing server to server context retrieval, devices or services.”

That’s the same critique Dan is making, voiced by a Reddit user weeks earlier. The narrative of “MCP is the future” and the narrative of “MCP is being eclipsed by Skills” are both alive in the same community at the same time.

Meanwhile, the 51-upvote r/ChatGPTCoding thread “Built my own MCP server for my app and was pleasantly shocked by how good it is” — published October 19, just before the “ditching MCP” framing went viral — captures yet another reality. Engineers building MCP servers for their own apps are actively delighted with the protocol. The OP describes hooking a custom MCP server into their genealogy app and being shocked by how well Claude integrated with it. The skeptics in the comments — “What functionality did MCP bring to this project, since Codex CLI can directly run web searches?” — are making the same point Dan made in his video, but the original poster’s experience is genuine. MCP solved a real problem for them.

The three states MCP is in

The clean way to think about MCP in November 2025:

MCP is well-suited for:

• Long-running connections to external services with stable APIs (GitHub, Cloudflare, n8n, Linear, Notion)
• Cases where multiple unrelated agents need the same external integration
• Use cases where the integration logic is non-trivial (auth flows, OAuth, pagination, rate-limit handling) and you don’t want every agent script to reimplement it
• Homelab and DevOps integrations where set-up-once-use-forever is the right tradeoff
• Anything Lempa demos in his tutorial

MCP is overkill for:

• One-off tools the agent only needs occasionally
• CLI utilities that already exist and the agent can shell out to
• Project-local scripts that bake in your project’s specific knowledge
• Sandboxed parallel agents with tight context budgets
• Most of what Dan demonstrates as alternatives

MCP is contested for:

• Mid-frequency tools you use sometimes but not always
• Internal company tools where you control both ends
• Anything where Claude Agent Skills can do the same job with less context overhead

The trend through November 2025 is for the third category — “contested” — to shrink as Agent Skills and CLI-based tooling mature. But the first category — “well-suited” — is durable. Anthropic donating MCP to the Linux Foundation isn’t a concession; it’s a recognition that the protocol has a real and persistent role even as Skills emerges as the lighter-weight alternative for specific cases.

What this means for your stack

If you’re running Claude Code or Codex CLI as your daily driver in November 2025:

• Keep MCP servers for the integrations where they earn their keep. GitHub MCP, Cloudflare MCP, Linear MCP — these are net positive.
• Audit your ~/.claude/settings.json for MCP servers you don’t use this session. Each one is taxing your context. Disable or remove the ones you only need occasionally.
• Adopt the CLI-as-Tools pattern for project-local work. Write a ./scripts/deploy.sh and tell the agent to use it. Don’t build an MCP server for one-project-one-script use cases.
• Try Claude Agent Skills as the middle ground. Lighter than MCP, more discoverable than scripts. Dan’s Claude Agent Skills video is the cleanest walkthrough of when to reach for them.
• For sandboxed parallel agents, default to scripts and CLI tools. Reserve MCP for the cases where the convenience pays off.

The honest framing: MCP isn’t dying. It’s settling into the role it was always going to occupy — the protocol for stable external integrations, not the universal “every tool is an MCP server” pattern that the early hype implied. The engineers ditching MCP are ditching the over-application of MCP. They’re not ditching the protocol itself.

The YouTube vs Reddit gap on this one

YouTube creators in mid-November mostly split into “MCP is overhyped, here’s what to use instead” (Dan’s framing) or “MCP is awesome, here’s how to use it” (Lempa’s framing). Reddit’s response was messier and more useful: both framings are correct for their respective audiences, MCP is genuinely a real and useful protocol, and most experienced engineers are doing a mix of all the patterns rather than picking one.

The reconciliation matters because the YouTube extremes will pull novice engineers in opposite directions. Watch Dan to understand context economy. Watch Lempa to understand what MCP is genuinely good for. Read the Reddit threads for the lived experience. The settled-state engineer in 2026 will run 2-4 MCP servers for the integrations that earn their context cost, plus CLI tools and Skills for everything else.

The lesson from Anthropic donating MCP to the Linux Foundation in December isn’t that MCP is in trouble. It’s that MCP is important enough to be standardized, and standardization usually happens after the initial-hype period burns out and the real use cases become clear. We’re in that phase now. The “engineers ditching MCP” narrative is the visible tip of the protocol finding its sustainable shape.