Is MCP Losing Its Shine? Why AI Developers Are Falling Back in Love with CLI

A fascinating trend has emerged in the tech community recently: many AI agent developers, after enthusiastically embracing the MCP protocol for over a year, are starting to rediscover the humble command line (CLI). This isn't a step backward — it's a recalculation of cost versus efficiency that real-world deployment has forced developers to confront.

What Are MCP and CLI, Exactly?

To understand this shift, we need to clarify two concepts.

MCP stands for Model Context Protocol — think of it as a standardized tool interface designed specifically for AI. In the past, whenever an AI needed to interact with a database, file system, or external service, developers had to build custom adapters from scratch: time-consuming and difficult to reuse. MCP aims to solve this through a unified protocol that makes it easier for AI to discover and invoke different tools. At its core, it's an attempt to standardize interfaces.

CLI, on the other hand, is the command-line interface — the black-box terminal that programmers have relied on for decades. You type text commands, the computer executes tasks directly. No fancy protocol wrappers, just simplicity and directness. That's why it has stood the test of time. When developers weigh these two approaches for AI agent development, the scales have started to tip in a subtle but meaningful direction.

MCP was proposed and open-sourced by Anthropic in late 2024, and quickly gained support from OpenAI, Google, and other major AI players. Its core design philosophy borrows from the software engineering concept of the "adapter pattern" — by defining a unified request/response format, it eliminates the need for custom integrations between AI models and external tools. A tool server built to MCP specifications can, in theory, be called directly by any MCP-compatible AI client. That's its biggest draw. Architecturally, MCP has three layers: Host (the AI application), Client (the protocol client), and Server (the tool service). The Server exposes a "tool list" to the AI, where each tool comes with a name, input parameter schema, and functional description. This metadata must be passed to the model at the start of every session — which is one of the primary sources of token consumption.

Token Costs: The Bill MCP Can't Escape

The first core reason developers are revisiting CLI is cost.

When calling a large language model, token count directly determines cost. MCP's approach requires feeding the AI a full set of metadata for each tool: names, parameters, functional descriptions. When an agent needs to connect with many tools, these descriptions alone continuously consume valuable context space.

A fitting analogy: it's like going to a restaurant where the waiter reads you the entire menu from cover to cover before you can order — every single time. The more tools you have, the longer that "menu" gets, and you're paying for it with every conversation.

CLI operates on a completely different logic. It only needs to tell the AI "you can run commands" — the specifics of how to do so come from knowledge the model accumulated during training. This eliminates the need to repeatedly describe tools. In scenarios with a large number of tools, this difference shows up directly on your invoice.

Tokens are the basic unit of measurement for how large language models process and generate text — roughly one to three tokens per Chinese character or English word. Leading commercial models like GPT-4o and Claude 3.5 charge separately for input and output tokens, ranging from a few dollars to tens of dollars per million tokens. In practice, context window token usage breaks down into two parts: actual business content (user instructions, conversation history, task data) and system-level overhead (tool descriptions, format specifications, safety prompts, etc.). When an agent integrates dozens of MCP tools, the tool descriptions alone can occupy thousands to tens of thousands of tokens — and that cost is incurred every single round of conversation. This is why "reducing tool description redundancy" has become an increasingly important engineering optimization challenge in AI application development.

CLI Fits the "Muscle Memory" of Large Language Models

The second reason is that CLI aligns more naturally with how current large language models are built.

Today's LLMs were trained on massive amounts of code, technical documentation, and terminal session logs. They're naturally fluent with git, Linux, Docker, and other classic command-line tools. For an AI, generating a shell command is almost as natural as writing a sentence. This means calling CLI requires no additional learning — the model draws directly from existing knowledge.

More importantly, CLI natively supports command composition. The output of one command can pipe directly into the next, letting the AI work like a real programmer — chaining multiple steps to complete complex tasks. MCP, by contrast, is more standardized but can introduce unnecessary invocation overhead for simple tasks, like using a sledgehammer to crack a nut.

The pipe (|) is an inter-process communication mechanism in Unix/Linux systems. It passes the standard output of one command directly as the standard input of the next, without needing intermediate files. For example, cat log.txt | grep ERROR | wc -l accomplishes three operations in one line: read file → filter keywords → count lines. This composability gives CLI natural pipeline processing capabilities that align closely with how AI agents decompose subtasks and execute them step by step. Because large models were repeatedly exposed to these kinds of command combinations in open-source code and technical blog training data, they can reliably generate shell scripts that match semantic intent — not just individual commands. This "training data advantage" remains a key competitive strength of the CLI approach for the foreseeable future.

MCP Isn't Going Away

It's important to be clear: CLI's lightweight efficiency doesn't mean MCP is being shown the door. The right use cases for each are actually quite distinct.

CLI is better suited for individual development, local automation, and developer tooling scenarios — where flexibility and low cost are the priority. MCP, on the other hand, remains indispensable in enterprise applications, multi-user shared environments, and situations requiring strict permission controls.

Security is the defining dividing line. Giving an AI direct access to a terminal means it can theoretically execute any system command — an enormous risk in production environments. MCP, through its structured interface, can precisely constrain which operations the AI can perform and which resources it can access, keeping permissions within a controlled boundary. For enterprises, controllability often matters more than efficiency.

At Its Core, This Is a Rebalancing of Engineering Trade-offs

The swing back from MCP toward CLI isn't really about one replacing the other — it's a recalibration of tool choices as AI development matures in the real world.

Over the past year, the industry chased the appealing vision of a unified protocol. But once technology actually meets production, cost, efficiency, and security are the three real factors that drive technology decisions. The vision is grand; the invoice is blunt.

It's easy to imagine that mature AI agents of the future won't choose one or the other — they'll combine both approaches depending on the scenario: using CLI for flexibility and low cost, using MCP to ensure reliability and security boundaries. Giving AI both the hands-on capability of a programmer and the guardrails of controlled permissions — that's the optimal engineering solution.

For developers, rather than agonizing over "MCP or CLI," the better question is: what does this specific task demand in terms of cost, complexity, and security? No tool is inherently superior — only more or less suited to the job at hand.