{"slug": "cli-vs-mcp-i-ran-the-same-task-through-both-one-used-250-tokens-the-other-used", "title": "CLI vs MCP: I Ran the Same Task Through Both. One Used 250 Tokens. The Other Used Over 2,000.", "summary": "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.", "body_md": "CLI and MCP are two different doors thatconnectAI agents to the real world.\n\n**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.\n\n**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.\n\nThere’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.\n\nThe 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.\n\nIn 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.\n\nSo which side is right? Is MCP a useful abstraction, or unnecessary context-window-filling bloat compared to the CLI?\n\nLet 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.\n\nThe 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.\n\nI 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.\n\nFor 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.\n\n```\ncat notes.mdgrep -n \"agent\" *.md\n```\n\nA 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.\n\nThat’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.\n\nWhen 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\".\n\n```\n{  \"tool\": \"read_file\",  \"arguments\": { \"path\": \"notes.md\" }}{  \"tool\": \"search_files\",  \"arguments\": { \"path\": \".\", \"pattern\": \"agent\" }}\n```\n\nBoth 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.\n\nThe 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.\n\nThat’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.\n\nLet’s think about Git, one of the most widely used developer tools on the planet.\n\nAn 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.\n\n```\ngit log -n 10 --pretty=format:\"%h %an %s\"git status\n```\n\nNow 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.\n\nAt 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.\n\nThat is the CLI camp’s strongest argument. For local developer tools, MCP is paying a steep tax for knowledge the model already has.\n\nSo is MCP just dead weight? Let’s try one more experiment.\n\nThis 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.\n\nFirst up was the MCP approach — and yes, we’re using MCP to fetch a page about MCP. A little meta.\n\nThe 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.\n\n```\n{  \"tool\": \"fetch_url\",  \"arguments\": { \"url\": \"https://modelcontextprotocol.io\" }}\n```\n\nThe 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.\n\nThe CLI approach started with the good old simple curl — and this is where it gets painful.\n\nThe agent’s first attempt was to use curl -s <URL> | head -n 200 to fetch the raw HTML and show the first 200 lines. But what came back was almost entirely JavaScript bundle code, because modelcontextprotocol.io is a Next.js application. The server doesn't send a finished HTML page — it sends a JavaScript application that builds the page in the browser, and curl doesn't run JavaScript. So all you end up getting is a skeleton and a pile of framework code.\n\n```\ncurl -s https://modelcontextprotocol.io | head -n 200\n```\n\nAt this point, the agent started improvising. It chained together text processing tools to try to strip the HTML tags and filter out the JavaScript. That didn’t work. Then it tried to find page content embedded as JSON inside the source code. It found fragments, but didn’t find the full page. In my experiment, the agent even wrote a Python script to reverse engineer the internal data format that Next.js uses to stream content to the browser.\n\nReverse engineering a JavaScript framework’s internals just to read a webpage.\n\nWhen I ran this, it went through several more attempts before it finally got enough content to summarize the page. It took several minutes and over 2,000 tokens, plus all that extra local processing on my poor laptop — all to get the same result.\n\nSo what’s the pattern here?\n\nCLI wins when commands map directly to jobs — file operations, Git, text processing, and running scripts. Things where the command line has been solving the problem for decades, and the model already knows the tools well.\n\nCLI tools also naturally compose with pipes, so we can chain commands together in a single line, which is something MCP can’t do because each tool call is independent.\n\nBut we can also make an argument for MCP. MCP wins when there is a gap between what the raw tool gives you and what you actually need, like my Next.js webpage example. And that extends to all sorts of other things.\n\nTake authentication for Slack, Notion, or databases. With CLI, the agent is managing the OAuth tokens, looking up channel IDs, and handling token refresh. All of this is quite manual — the AI agent is doing it, but it’s still doing it manually. With MCP, the server takes care of all of that. It’s server-managed rather than agent-managed. The agent just says what it wants done.\n\nAt an organizational level, MCP has some advantages. When agents act on behalf of different employees, we might need per-user access control. We might need to not share credentials. We may need audit trails so we can track what is being done. Those are hard things to bolt onto CLI after the fact, but MCP has it all built into the protocol.\n\nMCP or CLI? You probably saw this coming, but the answer is to use both.\n\nThe AI agent I tested uses both, after all. It uses CLI and MCP side by side for differing tasks — CLI when the commands map to the job, and MCP when the abstraction or the governance justifies it.\n\nThe choice is up to the agent and the person prompting that agent. And if the agent ever starts reverse engineering a JavaScript framework just to read a webpage — well, that’s a good sign it picked the wrong one!\n\nIf you found this helpful, consider clapping👏 so others can find it too!\n\n[1] Anthropic, Introducing the Model Context Protocol (2024), Official Anthropic Blog, [https://www.anthropic.com/news/model-context-protocol](https://www.anthropic.com/news/model-context-protocol)\n\n[2] Model Context Protocol, What is the Model Context Protocol (MCP)?, Official Documentation, [https://modelcontextprotocol.io/docs/getting-started/intro](https://modelcontextprotocol.io/docs/getting-started/intro)\n\n[3] GitHub, github-mcp-server, [https://github.com/github/github-mcp-server](https://github.com/github/github-mcp-server)\n\n[4] Ravi Madabhushi, MCP is up to 32× more expensive than CLI. Here’s why we still use it (2026), Scalekit, [https://www.scalekit.com/blog/mcp-vs-cli-use](https://www.scalekit.com/blog/mcp-vs-cli-use)\n\n[CLI vs MCP: I Ran the Same Task Through Both. One Used 250 Tokens. The Other Used Over 2,000.](https://pub.towardsai.net/cli-vs-mcp-i-ran-the-same-task-through-both-one-used-250-tokens-the-other-used-over-2-000-c4c460202d52) was originally published in [Towards AI](https://pub.towardsai.net) on Medium, where people are continuing the conversation by highlighting and responding to this story.", "url": "https://wpnews.pro/news/cli-vs-mcp-i-ran-the-same-task-through-both-one-used-250-tokens-the-other-used", "canonical_source": "https://pub.towardsai.net/cli-vs-mcp-i-ran-the-same-task-through-both-one-used-250-tokens-the-other-used-over-2-000-c4c460202d52?source=rss----98111c9905da---4", "published_at": "2026-07-26 16:01:01+00:00", "updated_at": "2026-07-26 16:34:15.036862+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-agents", "ai-tools", "developer-tools"], "entities": ["CLI", "MCP", "filesystem server"], "alternates": {"html": "https://wpnews.pro/news/cli-vs-mcp-i-ran-the-same-task-through-both-one-used-250-tokens-the-other-used", "markdown": "https://wpnews.pro/news/cli-vs-mcp-i-ran-the-same-task-through-both-one-used-250-tokens-the-other-used.md", "text": "https://wpnews.pro/news/cli-vs-mcp-i-ran-the-same-task-through-both-one-used-250-tokens-the-other-used.txt", "jsonld": "https://wpnews.pro/news/cli-vs-mcp-i-ran-the-same-task-through-both-one-used-250-tokens-the-other-used.jsonld"}}