CLI vs MCP: How AI Agents Choose the Right Tool for the Job

TL;DR: CLI wins for tasks where commands map directly to jobs — file ops, git, text processing — because models already know these tools from training data and there’s zero schema overhead. MCP wins when there’s a gap between what the raw tool gives you and what you actually need — JS-rendered pages, OAuth auth, per-user access control. The answer is to use both.

The Debate: CLI or MCP for AI Agents?

Both CLI and MCP let AI agents interact with the outside world. CLI has the agent run terminal commands (ls, cat, grep, curl) — the same commands a developer would type. MCP uses dedicated servers that expose structured tools with names, descriptions, and JSON schemas defining inputs and outputs.

A growing number of developers argue that MCP is unnecessary complexity — that CLI tools can do the same job cheaper. The argument has merit:

AI models are trained on millions of CLI examples from Stack Overflow posts, man pages, and documentation
The model already knows which flags to pass — no schema needed
With MCP, every tool’s schema gets loaded into the context window at conversation start, each costing hundreds of tokens
You’re filling up context before the agent has done anything useful

But is MCP just dead weight? Let’s look at the evidence.

Test 1: File Operations — CLI’s Turf

Task: Read notes.md and search for the word “agent” across multiple markdown files.

CLI approach: The agent used two bash commands — cat notes.md and grep -rn "agent" *.md. It didn’t need to look up any commands or flags. This knowledge was baked into training data.

MCP approach: The agent used read_file and search_files from a filesystem MCP server. Both completed successfully and returned the same information.

Verdict: CLI was more compact. The MCP filesystem server advertises 13 tools with full JSON schemas — a couple thousand tokens of definitions loaded into context just to use two of them. For simple file operations, the MCP overhead is hard to justify.

Test 2: Git Operations — The CLI Camp’s Strongest Argument

CLI approach: git log --oneline -10 and git status — two commands, zero schema overhead. The model knows git from training.

MCP approach: The GitHub MCP server ships 80 different tools. Every tool definition — name, description, full JSON input schema with parameter types and descriptions — gets injected into the context window at conversation start. That’s approximately 55,000 tokens even if you only need one or two tools.

At API pricing, those tokens are real money. They eat directly into the context window space available for actual work. And the model could have done the same git operations with a couple of bash commands.

This is the CLI camp’s strongest argument: for local developer tools, MCP is paying a steep tax for knowledge the model already has.

Test 3: Web Page Fetching — MCP’s Moment

Task: Fetch modelcontextprotocol.io and summarize the main heading and first few paragraphs.

MCP approach: The agent used a single call to a “fetcher” MCP server built on a headless browser. One tool call — fetch_url — and the server launched a browser, loaded the page, waited for JavaScript to render, converted the result to readable text, and returned the content. About 250 tokens, a couple of seconds.

CLI approach: This is where it gets painful.

First attempt: curl -s URL | head -200 — returned almost entirely JavaScript and bundle code because modelcontextprotocol.io is a Next.js application. The server sends a JS app that builds the page in the browser; curl doesn’t run JavaScript.
The agent started improvising — chaining text processing tools to strip HTML tags and filter JavaScript. That didn’t work.
Tried to find page content embedded as JSON inside the source code. Found fragments, not the full page.
Wrote a Python script to reverse-engineer the internal data format that Next.js uses to stream content to the browser.

Reverse engineering a JavaScript framework’s internals just to read a web page. The agent went through several more attempts before finally getting enough content to summarize. Result: several minutes, over 2,000 tokens, plus significant local processing — all to get the same result that MCP delivered in seconds.

Verdict: MCP wins decisively here. When there’s a gap between what the raw tool gives you and what you actually need, MCP bridges it.

Where Each Approach Shines

CLI Wins When

Commands map directly to jobs: file operations, git, text processing, running scripts
The command line has been solving the problem for decades
The model already knows the tools well from training data
CLI tools naturally compose with pipes — chaining commands in a single line, which MCP can’t do since each tool call is independent

MCP Wins When

There’s an abstraction gap — like JS-rendered web pages where curl returns skeleton HTML
Authentication is involved — Slack, Notion, databases with OAuth tokens, channel IDs, token refresh. With CLI, the agent manually manages all of this. With MCP, the server handles it — the agent just says what it wants done
Organization-level governance — per-user access control, non-shared credentials, audit trails. These are hard to bolt onto CLI after the fact, but MCP has them built into the protocol

The Real Answer: Use Both

The pragmatic approach is exactly what most AI agents already do — use CLI and MCP side by side for different tasks:

CLI when commands map to the job
MCP when the abstraction or governance justifies the overhead

The choice is up to the agent and the person prompting it. And if your agent ever starts reverse engineering a JavaScript framework just to read a web page — that’s a good sign it picked the wrong tool.