In the age of intelligent agents, every technical decision about how to connect language models with external systems has a direct impact on the efficiency, cost, and quality of solutions. Over the past few months, the MCP protocol has captured the attention of developers and companies as the emerging standard for integrating artificial intelligence with tools and services. However, after in-depth evaluation in real production environments, an uncomfortable truth emerges: the humble CLI is still, in many cases, an extraordinarily more effective option than MCP. This article explores the technical and strategic reasons for this apparent paradox, and proposes a reflection on when it is appropriate to bet on each paradigm, especially in the context of business projects where custom software and agent-oriented architectures are required.
To understand why CLIs can outperform MCPs in certain workflows, it is necessary to analyze an agent's decision cycle. When a language model decides to invoke a tool, it consumes reasoning tokens and generates a structured request. In the case of MCP, each call to a tool is equivalent to a single atomic operation: an inference produces a single invocation. This may seem enough for simple tasks, but in real scenarios – such as mass data querying, file manipulation or the execution of conditional flows – the agent is forced to perform hundreds of consecutive turns, doubling the cost of tokens, increasing latency and multiplying the opportunities for error or hallucination. A CLI, on the other hand, allows the model to generate an entire script in a single iteration, combining loops, filters, redirects, and external API calls without needing to re-infer each step. That ability to compose is what makes CLIs unreasonably effective at tasks that require volume or procedural logic.
From the perspective of the data plane, the advantage is equally remarkable. With a CLI, the agent can read files, filter lines with grep, transform outputs with jq, and only present the debugged output it needs for the next decision to the model. In MCP, by contrast, the tendency is for servers to return large blocks of content directly to the context of the model, cluttering the attention window and forcing the agent to process irrelevant information. While an MCP server could theoretically implement paging and filtering, in practice many do not, resulting in a cost-inflated and unscalable experience. Companies that develop AWS and Azure cloud service solutions know well that data handling efficiency is critical to keeping costs under control, especially when working with next-generation language models.
Another fundamental aspect is the development and iteration loop. When a team needs to build a connector for its AI agents to interact with an internal system—for example, a CRM, document repository, or database—the option to develop a custom CLI is often faster, cheaper, and more flexible than deploying an MCP server. A CLI can expose commands that accept files by reference, perform batch operations, and return outputs formatted for the model, without requiring the agent to have to read and forward large volumes of data on each call. At Q2BSTUDIO, we have accompanied numerous clients in the creation of AI for companies where the choice of interface between the model and legacy systems makes the difference between a slow prototype and a production-ready solution. Our experience shows that a well-designed CLI, accompanied by clear instructions (skills) for the agent, often outperforms an MCP in speed, cost, and maintainability.
However, it would be naïve to claim that MCP lacks virtues. The protocol offers automatic tool discovery, embedded documentation, and a centralized authentication model that is highly attractive to cybersecurity and compliance departments. In fact, the ability to funnel all invocations through an MCP gateway allows you to enforce uniform access policies, log every operation, and prevent agents from acting on unauthorized systems. This is especially relevant in regulated environments, where cybersecurity is a priority and any information leakage can have serious consequences. However, these advantages do not eliminate the fundamental limitations of the paradigm: the cost of each inference and the impossibility of executing complex flows without multiple turns to the model. The key is to understand that MCP is not a universal replacement, but just another tool in the agent engineer's arsenal.
In practice, many organizations are taking a hybrid approach: they use MCPs for short-context tasks where security and discovery are critical—such as querying a support ticket, reading an email, or creating an event on a calendar—and relying on CLIs or scripts for heavy processes such as reporting, data migration, or automating continuous integration flows. This clever combination makes it possible to take advantage of the best of both worlds. In addition, the ecosystem is evolving: new frameworks allow agents themselves to generate and execute scripts in real time, acting like a software engineer writing their own code to solve a task. This brings the vision of autonomous artificial intelligence closer to a level of productivity that would be impossible if every action required a query to the model.
The implications for custom application development are profound. When a company commissions the construction of an agent-based system, it must consider not only which model to use, but how that model will communicate with the outside world. A common misconception is that MCP is the only modern way and that CLIs are obsolete technology. Nothing could be further from the truth. CLIs, especially those that dynamically self-discover (such as gws, which builds its command surface from APIs in real time), offer an agility that is hardly matched by an ecosystem of static MCP servers. In addition, agents can learn how to use a CLI by reading its help or a documented skill, and will only consume tokens when they really need it, rather than loading all the instructions from each MCP tool into every conversation.
In the field of business intelligence services, such as Power BI or analytics tools, the combination of agents with CLIs also proves its effectiveness. Imagine an agent that must extract data from multiple sources, clean it, apply transformations, and finally upload the result to a dashboard. With MCP, each step would require a separate invocation: connect to the database, get the rows, filter, add, and so on. The agent would consume tokens for each intermediate decision. With a CLI that exposes a bulk ingestion command with transformation parameters, the model can generate a single script that executes the entire pipeline, and only present the final summary or errors to the user. Not only does this save costs, but it drastically reduces latency, improving the user experience. At Q2BSTUDIO we have implemented architectures of this type for customers who need power BI powered by intelligent agents, obtaining results up to ten times faster than with purely MCP approaches.
The final decision depends on the context of use. For interactive tasks where a human oversees each step and maximum transparency is needed, MCP may be suitable. But for internal process automation, batch processing or iterative workflows with large volumes of data, the CLI is still the undisputed king. Engineering teams developing custom software for their clients should seriously consider including CLIs in their agent toolbox, and not just get carried away by the MCP craze. Actual efficiency is measured in tokens saved, execution time, and reliability of the result. From our experience in Q2BSTUDIO, we have found that a pragmatic approach—first building a robust CLI and, if security demands it, adding an MCP layer only for the operations that need it—offers the best balance between cost and functionality. In a market where every millisecond and every penny counts, the unreasonable effectiveness of CLIs versus MCPs is not an anecdote, but a lesson that transforms the way we design the next generation of AI agents.
.jpg)
.jpg)
