MCP vs Bash

In early 2026, a sharp opinion started making the rounds in developer circles: MCP barely works, and almost everything it does could just be a bash script. It came from well-known engineers and it landed hard because it had a ring of truth to it.

So is it true? Should we throw out MCP and go back to shell scripts? The short answer: the criticism is half right. The cost problem it points at is very real. But the conclusion "just use bash" misses where the industry is actually heading. Let's unpack it in plain terms.

First, what are we even comparing?

If you're newer to AI agents, here's the 30-second version.

An AI agent is an LLM that can do things: call APIs, run commands, read/write files etc., not just chat. To do that, it needs tools.

MCP (Model Context Protocol) is a standard from Anthropic for how an agent discovers and calls those tools. Think of it as a universal plug: any tool that speaks MCP can connect to any agent that speaks MCP.

Bash is the other approach: don't build special tool connectors at all. Just give the agent a sandboxed terminal and the command-line tools it already knows: git, curl, jq, aws, kubectl and friends. The model learned these from millions of examples during training, so it's already fluent.

That fluency is bash's superpower. The agent can chain commands into a single pipeline, and it only "pays" to learn a tool's options when it actually runs “--help”. Nothing is loaded until it's needed.

The real complaint: the "context tax"

Here's the heart of the argument.

An LLM has a context window which is its working memory for a conversation. Everything in it costs tokens, and tokens cost money and space. The problem with naive MCP is that it eager-loads: every connected tool's full description gets dumped into that memory up front, whether the agent ends up using it or not.

The numbers are uncomfortable:

Why so bad? Three reasons:

1. Eager loading: every tool definition lands in the prompt by default. Burns many tokens before anyone says hello.
2. Round-tripping: intermediate results flow back through the model instead of staying in a sandbox, the way bash keeps them.
3. Verbose envelopes: the JSON-RPC wrapping inflates even plain text by another 30–50%.

Where MCP actually earns its keep

Here's what the "just use bash" crowd glosses over: some things are genuinely hard to do in pure shell.

Bash shines when you control the environment. But what about an enterprise SaaS app like HR, finance, CRM apps with no public CLI, where the agent acts on behalf of many different users, each with their own OAuth permissions, and where you need audit trails and the ability to revoke access centrally? You can't reasonably rebuild that in a shell script.

The actual answer: bury MCP, don't delete it

So the 2026 consensus isn't "MCP or bash." It's a hybrid, and the trick is the same in every winning pattern: keep MCP, but hide it behind a layer that loads only what's needed.

There's a nice irony here. The engineer who first popularized the "bash is better" line now ships a tool that converts MCP servers back into a single CLI command which is itself a hybrid move.

A simple way to decide:

• Use bash when you control the environment, your users are developers, your tools have CLIs, and it's single-tenant.
• Use MCP when the target has no CLI, you've got multiple users with different OAuth scopes, and audit trails matter.
• Use the hybrid when you're in doubt. Wrap MCP behind a meta-tools gateway, expose it through a CLI surface or a Skill, and let the agent compose it like any other Unix tool.

Reference

Song, W., Zhong, H., Ding, Z., Xue, J., & Li, Y. (2025). Help or hurdle? Rethinking Model Context Protocol-augmented large language models (arXiv:2508.12566). arXiv. https://doi.org/10.48550/arXiv.2508.12566