CLI vs MCP: I Ran the Same Task Through Both. One Used 250 Tokens. The Other Used Over 2,000. A comparison of CLI and MCP approaches for AI agents shows CLI using 250 tokens versus MCP consuming over 2,000 tokens for the same file operation task, according to an experiment run by the author. The CLI approach used two bash commands (cat and grep) while MCP required two tool calls (read_file and search_files) from a filesystem server that advertises 13 tools with full JSON schemas, loading unused tool definitions into the context window. CLI and MCP are two different doors thatconnectAI agents to the real world. CLI Command Line Interface lets an AI agent execute shell commands directly through the terminal, just like a developer would. It can run familiar commands such as ls, cat, grep, and curl to interact with files, search text, retrieve data, and perform other command-line tasks. MCP Model Context Protocol , on the other hand, is a standardized protocol where dedicated servers expose structured tools. Examples include read file and search files. Each tool has a name, a description in simple English explaining what the tool does, and a JSON schema that defines exactly what inputs it expects. There’s a growing number of developers saying that MCP is unnecessary complexity, and that CLI tools can do the same job cheaper. And they have the numbers to back it up. The argument goes like this: AI models have been trained on millions of CLI examples from sources like Stack Overflow posts and man pages. So the model already knows how to use these commands and many more besides, such as git and docker. It doesn't need a schema to tell it what flags to pass. That knowledge is baked in from training. In many current implementations, tool schemas are provided to the model as part of the conversation context. Depending on the framework, this may mean dozens of tool definitions are included before any work begins. We’re filling up a context window before the agent has even done anything useful. So which side is right? Is MCP a useful abstraction, or unnecessary context-window-filling bloat compared to the CLI? Let me show you two examples I ran with an AI coding agent to illustrate the difference, where the same operation was performed using CLI and MCP. You can try these very same experiments with the AI agent of your choice. The first experiment is simple file operations. We have a folder with some markdown files, and the agent has to do two things: read one of the files, notes.md, and then search both of them to find a specific word. I put in two separate requests to an AI coding agent, one requesting it to use the CLI and the other requesting it to use MCP. For the CLI approach, the agent ended up using two bash commands. The first was cat on notes.md to dump the contents of the file to standard output. The second used grep to search for the word "agent" across both markdown files. cat notes.mdgrep -n "agent" .md A quick sidebar on these commands if you’re not a CLI person: cat is short for concatenate, and here it's being used to print a single file. grep scans files line by line and spits out every line that matches the pattern, and the -n flag adds line numbers. That’s how the agent handled the CLI, and it’s worth pointing out that the agent didn’t need to look anything up to figure out which commands and flags to use. This was built into its training data. When the agent adopted the MCP approach, it ended up using two tool calls from a particular MCP server called the filesystem server. The two tools it used were read file for reading notes.md, and search files, where we provided the string of the word we wanted to search — "agent". { "tool": "read file", "arguments": { "path": "notes.md" }}{ "tool": "search files", "arguments": { "path": ".", "pattern": "agent" }} Both approaches completed the task successfully and returned the same information, but the CLI commands were a bit more compact, and the model didn’t need to know any schema to know that grep -n was the right flag combination. The filesystem MCP server advertises 13 tools, and I only used two. There were 11 more that weren’t used, and each one comes with a full JSON schema. That’s a couple of thousand tokens of tool definitions loaded into the context window just so the agent could use two of them. That’s where some of the “MCP is unnecessary complexity” commentary comes from. But honestly, either would be fine in something this simple. It’s when things scale up that the difference gets more notable. Let’s think about Git, one of the most widely used developer tools on the planet. An AI agent with Bash can run a bunch of Git commands. For example, it could run a command to show the last 10 commits or git status to check the working tree. The model knows Git cold — it knows the flags, it knows format strings, all from its training data. git log -n 10 --pretty=format:"%h %an %s"git status Now consider the MCP alternative, which in this case is the GitHub MCP server. That doesn’t ship 13 tools — it ships 80 different tools at the time of writing . Every one of those tool definitions — the name, the description, the full JSON input schema with parameter types and descriptions — all of it gets injected into the model’s context window at the start of the conversation. That adds up to tens of thousands of tokens, even if you only need one or two of those 80 tools. At API pricing, those tokens are actual money. They eat directly into the context window space available for actual work, and the model could have done those same Git operations with a couple of bash commands instead. That is the CLI camp’s strongest argument. For local developer tools, MCP is paying a steep tax for knowledge the model already has. So is MCP just dead weight? Let’s try one more experiment. This time, the task is to fetch a webpage at modelcontextprotocol.io, tell me what the main heading says, plus a summary of the first few paragraphs. First up was the MCP approach — and yes, we’re using MCP to fetch a page about MCP. A little meta. The agent used a single call to an MCP server called Fetcher. This is an MCP server built on a headless browser, so it can render JavaScript. It made a single request using one tool that Fetcher has available, calledfetch url, with a link to the webpage modelcontextprotocol.io. { "tool": "fetch url", "arguments": { "url": "https://modelcontextprotocol.io" }} The server launched a browser, loaded the page, waited for it to render, converted the result to readable text, and handed back the content. That used about 250 tokens and took just a couple of seconds. The CLI approach started with the good old simple curl — and this is where it gets painful. The agent’s first attempt was to use curl -s