IndyDevDan — Why are top engineers DITCHING MCP Servers? (3 PROVEN Solutions)

Why this is in the vault

Dan’s November 10 video is the practitioner-side counterpoint to the “everything-is-a-skill” reflex: a structured tradeoff analysis of when MCP, CLI, scripts, and skills each win — and when they each lose. It’s vault-worthy because:

1. It quantifies a context-budget claim that has been hand-wavy. A “small” MCP server burns 10K tokens before the agent does anything. Stack 2-3 and 20%+ of context is gone. RDCO runs many MCP servers (Notion, Gmail, Calendar, Discord, iMessage, Playwright, qmd, monarch, ElevenLabs, Vercel, Firebase, Figma, Canva, Slack, xMCP, Xcode, claude-in-chrome). The implicit assumption — “MCP cost is fine, we have a million-token window” — has not been measured. Dan’s framing makes it cheap to measure and easy to act on.
2. It introduces “raw code as tools” as a vocabulary the vault didn’t have. The pattern of priming an agent with a prime prompt that points to a readme + CLI is concretely better than the current “let me search for the right MCP tool” reflex for one-off ingestion work. Dan’s 25-line prime prompt template is directly portable to RDCO skills.
3. It explicitly names skills as Claude-ecosystem lock-in. This is a load-bearing observation that the standing “skills over commands” RDCO memory glosses over. Dan’s recommendation framework — when to use what — gives RDCO a defensible answer to “why didn’t you ship this as a skill?” instead of having to defend the default.

Core argument

Use raw code as tools by default. Reach for MCP when you don’t own the integration; reach for skills only when context preservation is the binding constraint.

The four approaches:

The “prime” prompt pattern for CLI/scripts: a 25-line slash command that reads a readme + the CLI source, learns the tools by reading their --help, and forbids reading any other code. This gets you 80% of MCP’s value at 5-10% of the context cost.

Dan’s recommendation framework — for accessing EXTERNAL tools (you don’t own):

• 80% MCP — don’t reinvent the wheel
• 15% CLI — when you need to control tools/context tightly
• 5% scripts/skills — only if context preservation is binding

For accessing NEW tools (you’re building):

• 80% CLI first — works for you, your team, AND your agents
• 10% wrap CLI in MCP server — when you need many agents at scale and don’t want to manage context manually (the MCP server’s tools just call into your CLI underneath)
• 10% scripts/skills — when context preservation is binding

The composition pattern Dan endorses: build CLI first → if you need MCP later, the wrapper is one decorator over each CLI command. You get interoperability for free.

The most underweighted line: “Even before context comes prompt engineering. This is still THE critical skill for engineers in 2025 and beyond.” Dan is pushing back against the “context engineering” hype cycle by reminding us that the prompt is what decides what enters context in the first place.

Mapping against Ray Data Co

• The implicit MCP-cost assumption in RDCO has never been measured. With 17+ MCP servers configured, every fresh autonomous-loop session may be paying 100K+ tokens before any work begins. We don’t know the actual number. Concrete delta: at the start of a fresh session, run /context and capture the baseline. Then disable each MCP server one at a time and re-measure. Output: a per-MCP context cost ledger. Estimated 30 minutes. Surprisingly cheap, surprisingly high signal.
• The “prime prompt + CLI” pattern is directly applicable to RDCO’s tool surface. Many RDCO operations don’t need MCP-level wiring: they need a Python script the agent can call. Examples: imessage-send-file.sh, imessage-attach-copy.sh, vtt-to-text.py are already in ~/.claude/scripts/. They’re CLI tools without MCP wrappers and they work fine. The pattern Dan is describing IS RDCO’s existing pattern — but it’s undocumented and not propagated. Concrete delta: write a ~/.claude/scripts/README.md that follows Dan’s “prime prompt” pattern, plus a /prime-scripts slash command that reads it. Lets future autonomous-loop sessions discover and use the script library cheaply.
• The “skills are Claude ecosystem lock-in” callout matters for RDCO’s portability story. RDCO has 60+ skills, all locked to Claude Code. If we ever want to fan out to OpenAI Agents, Codex, or self-hosted runners, every skill is a rewrite. CLIs port. Concrete delta: when creating new tooling, ask “could this be a CLI under ~/.claude/scripts/ instead?” first. Demote skills that are really just one-off CLI invocations dressed up as skills (cross-references the IDD-cracked-skills audit follow-up from earlier today).
• Validates the existing process-youtube and process-newsletter architecture. Both skills compose CLI tools (yt-dlp, vtt-to-text.py) and progressive disclosure (one sub-agent per item, isolated context). Dan’s framework explicitly endorses this: skill at the top, scripts/CLI underneath, progressive disclosure throughout. RDCO is already doing it; the framework gives vocabulary to defend it.
• The “build CLI first, wrap in MCP later” pattern should be the RDCO default for new internal integrations. When the founder asked us to add a Squarely API integration, the reflex was “let’s build an MCP server.” The Dan default would be: build a CLI in ~/.claude/scripts/squarely/ first (works for the founder, his team, his agents), then wrap in MCP only if multi-agent scaling demands it.
• A concrete Sanity Check angle: “We have 17 MCP servers. Here’s what they cost us.” Run the measurement, publish the per-server context cost ledger, draw the conclusion that most operators are over-rotating on MCP. Strong because it’s grounded in our own production setup, contrarian without being obnoxious, and ends in a directly-actionable framework (Dan’s 80/15/5 split).
• The “prompt engineering before context engineering” line is a useful editorial position. The RDCO skill library is heavy on context management; light on explicit prompt engineering of the entry-point prompts. Worth a one-pass review of the 60+ skills to ask “is the entry prompt doing its job, or are we relying on the agent to figure it out?”

Open follow-ups

• Run the per-MCP context-cost ledger. Fresh session, /context baseline, disable each MCP one at a time, re-measure. Ledger output to ~/rdco-vault/06-reference/2026-04-19-rdco-mcp-context-cost-ledger.md. Cheapest, highest-signal follow-up from this video. Estimated 30 minutes.
• Write ~/.claude/scripts/README.md + /prime-scripts slash command. Inventories the existing script library, follows Dan’s prime-prompt pattern, gives the autonomous loop cheap discovery of pre-built CLI tools instead of re-implementing them. Estimated 1 hour.
• Audit the 60+ skills for “should this be a CLI under ~/.claude/scripts/ instead?” Cross-references the audit follow-up from earlier today’s IDD-cracked-skills ingestion. The two audits should be merged into a single skill-architecture review pass. Estimated 3 hours combined.
• Add a “build CLI first” reflex to skill-creator. When the founder asks for a new tool, skill-creator should ask: “is this a one-off CLI you’d run from a slash command, or is this a recurring problem space that needs a skill?” Mirrors the Dan/IDD-cracked-skills heuristic.
• Sanity Check angle: “Your MCP servers are eating your context budget.” Grounded in measured per-server costs from RDCO’s own setup, contrarian to the “MCP-everywhere” reflex, ends in Dan’s 80/15/5 framework. Strong piece if the measurement holds.
• Concept page: “The Core Four — context, model, prompt, tools.” Dan invokes this in every video. The vault should have a single canonical concept page so future ingestions can link to it instead of restating it. Probably 200 words.

Related

• ~/rdco-vault/06-reference/transcripts/2026-04-19-indydevdan-ditching-mcp-servers-transcript.md — raw transcript
• ~/rdco-vault/06-reference/2026-04-19-indydevdan-cracked-claude-agent-skills.md — Dan’s earlier “skills decision tree” piece; this MCP-tradeoff video is the natural sequel that completes the picture
• ~/rdco-vault/06-reference/2026-04-04-anthropic-skills-internally.md — Anthropic’s own framing on internal skill use; pairs with Dan’s external-tools framework
• ~/rdco-vault/06-reference/2026-04-04-xcodebuildmcp.md — concrete example of an external MCP server RDCO consumes; useful test case for the per-MCP cost ledger
• ~/rdco-vault/06-reference/2026-04-11-garry-tan-thin-harness-fat-skills.md — Tan’s “fat skills” framing; Dan’s “thin tool layer” is the same architectural verdict from the tools-side
• ~/rdco-vault/06-reference/2026-04-13-every-folder-is-the-agent.md — Every’s “every folder is the agent”; the file-system-as-agent argument that Dan’s “raw code as tools” instantiates