MCP or a Shell? How I Decide What to Hand an Agent

"MCP was a mistake. Bash is better."

That line kicked off the biggest AI tooling debate of the year, and I've been arguing about it in one Slack thread or another ever since. It deserves the attention, because the person saying it isn't wrong about the evidence. They're wrong about the conclusion.

Here's the evidence.

The receipt

Connect a GitHub MCP server to an agent and you get 93 tool definitions dumped into the context window. That's roughly 55,000 tokens — spent before you have asked a single question. Every one of those schemas is sitting there whether the task needs it or not.

Now stack the servers the way a real workflow does. GitHub, Jira, a database, Microsoft Graph:

That last row is the one that reframed the problem for me. Not a 20% saving. Not a rounding error you optimize away later. Something like a 275x difference on the plumbing alone — and the plumbing is not the part of the job that produces value.

You feel it in three places at once. The window fills with schemas instead of the codebase. Attention gets spread across 93 tools when the task needed two. And you pay for all of it on every single turn.

Why the CLI wins so comfortably

Once you see the number, the CLI argument stops sounding contrarian and starts sounding obvious:

The model already knows these tools. It was trained on millions of man pages, shell scripts, and Stack Overflow answers. gh pr list --state open needs no schema, because the knowledge of how gh behaves is already in the weights. An MCP tool definition is you re-teaching the model something it knows, at 55,000 tokens a sitting.

Composability is already solved. Unix pipes have had fifty years to get this right. gh pr list --json title,author | jq '.[] | select(...)' is a tool the agent invented for itself, in one line, without anyone shipping a list_prs_filtered_by_author endpoint. MCP servers compose the way REST APIs compose: you get exactly the operations somebody thought to expose.

Auth is solved too. gh auth login, aws sso login, a kubeconfig. Every one of those is a battle-tested credential path with token refresh, scoping, and revocation already handled by people who do this full time.

Debugging is instant. A CLI call that fails prints a non-zero exit code and an error message to stderr. When an MCP call fails you are diagnosing a two-process stdio conversation across a protocol boundary, and the useful part of the error is often the part that didn't survive the trip.

Karpathy made the point better than I can: CLIs are exciting precisely because they're legacy technology. Fifty years of stability is what makes them natively usable by an agent. Nobody has to build the integration, because the integration is thirty years old and in the training data.

The part the CLI camp skips

MCP isn't dead. It's misapplied. Almost every viral takedown I've read is measuring a dev-loop task and generalizing to every context an agent will ever run in — and the contexts are not the same.

Reach for MCP when you need:

• OAuth, audit trails, and scoped permissions. An enterprise needs to answer "who did what, on whose behalf, and under what grant?" A shell command run as your user answers none of that. An MCP server is a real boundary, and boundaries are where you attach governance.
• Multi-tenant access control. Fine-grained, per-tenant permissions have to live in a layer that can actually enforce them. "The agent has a terminal and we trust the prompt" is not an authorization model.
• One implementation across models. If Claude, GPT, and Gemini all need the same tool, MCP gets you one implementation behind one protocol instead of three bespoke integrations drifting apart.

And then the part I'd put in bold on a slide: an AI agent with unrestricted shell access to enterprise systems isn't a productivity tool, it's a pending incident report. On my own machine, in a repo with a clean git history, a shell is a reasonable thing to hand an agent — the blast radius is a git reset wide. Pointed at production infrastructure and customer data, the same capability is an unscoped grant of everything, exercised by a process that can be talked into things by text it reads along the way.

That asymmetry is the whole argument. The token math is about efficiency. The MCP case is about containment. They aren't competing claims, because they aren't answering the same question.

Skills, the option nobody puts on the poster

The framing I've settled on has three tiers, not two — because Skills split the difference in a way that turns out to matter most of the time.

A Skill is instructions loaded on demand. Not 93 schemas resident on every turn: a short document that teaches the agent how this workflow goes, which it reads when the task calls for it and ignores otherwise. Underneath, it invokes the CLI. You get the discoverability that made MCP appealing, at something much closer to CLI cost, and the loading is lazy by construction.

Most of what I reach for MCP to solve turns out to be a discovery problem — how does the agent know this capability exists? — and a Skill answers that for a few hundred tokens instead of fifty thousand.

The rule I actually use

The debate was never CLI versus MCP. It's that we shipped a protocol built for governed, cross-vendor, multi-tenant integration, and then spent a year using it to run git status — paying enterprise overhead for a task with none of the enterprise constraints.

Match the tool to the blast radius. On your laptop, a shell. Across an org, a boundary. In between, a Skill.