MCP vs CLI vs API: When to Use Each One

Twitter is fighting a holy war over MCP vs CLI, and both sides are wrong. The "MCP is dead" crowd calls it a bloated abstraction over APIs and CLIs we already had. The "MCP is the future" crowd says it was never about tools, it is about auth, and CLIs are obsolete. The actual answer is a use-case decision: CLI when you want full flexibility and your users are technical, MCP for third-party services and non-technical users, raw API for your own production infrastructure. I use all three, and the skill is knowing when.

Is the "MCP rots your context" argument still true?

It used to be. MCPs dumped every tool schema into your context up front, which is textbook context rot. It is not true anymore: with progressive search, tools load only when needed, and the bloat argument is outdated.

The CLI side does not escape the same problem anyway. A CLI's answer to discovery is a --help flag that explains its commands, which is the same operation as an MCP listing its tools, just relocated. Either way the LLM first finds out what exists, then starts calling things and hoping, including calls that make no sense for the task. The discovery problem moved; it did not disappear.

Where CLIs shine, and where even the GitHub CLI breaks

A CLI is a programming tool. It assumes installation, terminal access, and a developer who knows what they are doing. Inside that assumption it is excellent: Claude Code uses the GitHub CLI on my machine because I already have it, and it works great, helped by the mountain of training data that exists for it.

But even the best case shows the crack: I have watched Claude Code go off the rails between calling GitHub's API and calling the GitHub CLI to do the exact same thing. Give a model multiple ways to do one thing and you have bought extra margin for error.

And for non-technical users the whole premise fails. They will not open a terminal, will not install anything, and will not complete an auth flow that lives in the terminal. Shipping a CLI to end users also means shipping a sandbox around it. An MCP can simply be remote.

When to use a CLI

Full flexibility, technical users. You control the API and want to shape input and output exactly. Your users are developers who already have a terminal open. I also build skills that call APIs directly, which is close to the CLI pattern, just neater; for full control among technical users, this is the lane.

When to use MCP

It has to work for non-developers too. The service is third party and you do not control its API. Auth, discovery and accessibility come in one package, and "add a connector" in Claude is a much cleaner UX than any terminal auth flow. I run connectors for Slack, Gmail and calendar daily. A well-designed MCP also makes it easier for the LLM to pick the right tool at the right time, which is genuinely hard to get from a CLI today.

One honest hedge: in a future where models reason fast enough to re-derive everything from --help on every call and always get it right, CLIs might win this. We are not there.

When to use the raw API

Your own infrastructure, where you do not need the flexibility layers at all. In practice CLI and API are close to interchangeable here; the API is just the version without the wrapper.

The real problem: man with a hammer

The debate annoys me because underneath it are people who know one pattern and apply it everywhere. If you live in MCP, everything becomes a tool call. If you live in the terminal, everything becomes a CLI invocation. The actual skill is matching the mechanism to the context: who the users are, who controls the API, where auth has to live.

When the next round of this discourse crosses your feed, step back and think for yourself. It is mostly noise.