Why CLIs Beat MCPs and APIs for Claude Code Agents

In one benchmark, routing the same task through an MCP server burned 35 times more tokens than the CLI alternative, and task reliability dropped from 100 percent to 72 percent as complexity increased. Those two numbers, cost and reliability moving in the wrong direction simultaneously, describe the hidden problem that is limiting the practical value of most business AI workflows right now.

I am Madhuranjan Kumar, and the argument I want to make in this piece is specific: the interface between an agent and the tools it calls is where most of the unnecessary cost and most of the unexplained failures in business AI are hiding. The agent itself gets most of the attention. The model gets most of the credit or blame. But the connection layer, how the agent actually calls a service, how much data comes back, how that data is handled before the agent acts on it, determines whether the workflow is economical and reliable in practice. Choose the wrong interface type and you pay too much and fail too often, even with a capable model.

APIs were designed for software, MCPs were designed for discovery, CLIs were designed for agents

This framing is the cleanest summary of a distinction that matters practically. APIs were designed for software written by human developers. The design assumes the calling code knows exactly which endpoint to call, handles the JSON response deterministically in a parsing loop, manages pagination headers, and deals with authentication token renewal. That is a reasonable design for a developer writing an integration once and maintaining it. It is a painful design for an agent that pays per token consumed and needs to make sense of a large raw JSON response in its context window with no deterministic parser to offload the work to.

MCP servers improved tool discovery. A single server can expose many tools and the agent can find them without hard-coding endpoint details. That is a real improvement over raw API integration in the right context. The problem is the overhead at the session level. An MCP server loads all of its tool descriptions into the agent's context at startup, whether or not the agent ever uses most of those tools in a given session. Run the slash-context command in a fresh Claude Code session after loading a substantial MCP server and you can watch the token count climb before a single useful instruction has been given. The 35x comparison came from exactly this overhead accumulating across every step of a multi-step task.

CLIs were designed for agents in four specific ways that make them the better interface for repetitive, cost-sensitive work. First, they use lazy discovery rather than loading everything upfront, so only the tool the agent actually calls in a given step contributes any overhead to that step. Second, they return pre-formatted, human-readable text rather than raw JSON, which is significantly cheaper to process and much easier for the agent to act on accurately. Third, they compose together as sequential commands exactly the way agents naturally think through multi-step problems. Fourth, they handle authentication internally rather than requiring the agent to manage token headers on every individual call. The credentials live in the tool, not in the context.

The 35x token gap is not a theoretical number, it shows up in the monthly bill

When a task costs 35 times more tokens through an MCP interface than through a CLI, and that task runs multiple times per day across multiple team members or across an agent workflow that fires automatically, the cost difference is not a rounding error. It is the difference between a workflow that costs ten dollars per month to run and one that costs three hundred and fifty dollars for the same functional output.

The reliability drop compounds the cost problem. Going from 100 percent task completion on the CLI to 72 percent on MCP means roughly one in four complex tasks fails and requires either a retry, a human intervention, or both. In a workflow that is supposed to reduce the need for human intervention, a 28 percent failure rate on complex tasks negates much of the automation benefit. The retry costs more tokens. The human intervention costs staff time. The overall reliability of the system is lower than the individual tool quality would suggest, because the interface is introducing its own failure modes on top of whatever the model contributes.

For any team running AI agents against business tools as part of a production workflow, whether that is CRM and website stack integrations, data pulls, automated reporting, or customer-facing logic, these numbers matter immediately. The choice of interface type for the most frequently called services is one of the highest-leverage decisions in the architecture of a business AI workflow.

Lazy discovery and output routing are the two structural advantages that explain the gap

The token math is not hard to follow once you understand the two mechanisms that drive the CLI advantage.

Lazy discovery means the agent only loads information about a tool at the moment it decides to call that tool. Compare this to an MCP server that loads the descriptions of all 50 exposed tools into the session context whether the agent needs all 50 or only 3 of them in any given run. Every one of those unused tool descriptions is tokens that cost money and reduce the available context for actual task reasoning. In a session where the agent calls 4 specific tools from a server that exposes 50, roughly 46 tool descriptions were loaded and paid for with no return. Multiply that overhead by every step of a multi-step task and you see where the 35x figure comes from.

Output routing is the capability that prevents large API responses from flooding the agent's context. The Skool community example makes this concrete. When the agent called the Skool CLI to pull data from a community, the underlying request returned approximately 132,000 tokens of raw data. The CLI summarized that data and returned roughly 2,000 tokens of clean, relevant output to the agent's context. The 130,000-token difference never touched the context window at all. It was processed by the CLI and left behind. That routing is the reason the agent's context stays clear across a long multi-step task rather than filling up after three or four steps and losing track of earlier information.

Both of these properties, lazy loading and output routing, are structural. They are not features that depend on writing clever prompts or tuning the model. They come automatically from using the CLI interface, and they disappear when you switch to MCP or raw API integration.

Printing Press makes this practical: 50 prebuilt CLIs and a factory for everything else

A tool called Printing Press was built specifically to address this problem and make the CLI approach accessible without requiring a team to build each CLI from scratch. It ships a library of approximately 50 prebuilt CLIs covering common services, including several that have no public API at all. The library covers ESPN, Craigslist, Domino's, and Skool for services with no clean public API, while sites that actively block scrapers can be driven through a real Chrome session so the agent sees the same content a logged-in user would. Coverage includes the full range of data sources a business research workflow typically needs.

The factory feature is the headline for any business whose most important tools are not in the prebuilt library. You point Claude Code at the Printing Press factory and the target service, describe what you need from it, and Claude Code researches the service, catalogs what actions and data are available, and generates a small, focused command-line tool that the agent can call reliably. In the live demonstration, a Hacker News CLI was built in under five minutes, notably faster than the estimated one hour, and a Skool CLI was built in approximately ten minutes despite the absence of any public API documentation to reference. Claude Code reverse-engineered Skool's endpoints from scratch and produced a working CLI that returned clean, summarized output to the context instead of the raw 132,000-token payload.

The decision order that comes out of this is clear: when building agent workflows, try a CLI first. Fall back to a direct API integration if no CLI exists and the service has a clean public API with manageable response sizes. Treat MCP server integration as a last resort for cases where discovery across many tools in a single session is the primary requirement and per-step token cost is not the binding constraint.

The Skool CLI built without a public API is the proof of concept for any closed platform

The Skool example deserves its own treatment because it answers the objection most teams raise when the CLI approach is proposed: what about the services that have no API to wrap? The assumption is that without an official API, a service cannot be integrated into an agent workflow without manual scraping that violates terms of service. The Skool build demonstrates that this assumption is wrong.

Claude Code examined Skool's network traffic, identified the endpoints the platform uses internally, and wrote a CLI that calls those endpoints with appropriate authentication. The result is a working integration with a platform that publicly exposes no API, built in approximately ten minutes, producing clean summarized output rather than raw data. The same approach applies to any service that an agent needs to interact with but that does not provide a formal API.

For a business running SEO and organic content research, competitor monitoring, or any workflow that depends on data from platforms without APIs, this is a significant practical expansion of what can be automated reliably. The only hard limits are platform rate limits and authentication requirements, both of which apply equally to any integration approach. The CLI does not bypass a platform's access controls. It just calls the same endpoints a browser session would, with authentication credentials stored in the local .env file rather than embedded in the CLI code.

Authentication handling is one point that requires explicit attention regardless of which services are being wrapped. API keys, OAuth tokens, and session cookies all go into the .env file and are referenced by the CLI by environment variable name. They never appear in the CLI code itself, because CLI code often gets packaged into a shared repository that team members clone. Credentials embedded in shared code are a security incident. Credentials in environment variables are a standard, safe pattern. This one habit, credentials in .env rather than in code, is the difference between a shareable, team-ready CLI library and a tool that cannot leave the original developer's machine without leaking access.

The broader conclusion is that the interface layer between an agent and its tools is as important a design decision as which model to use or how to structure the prompt. The right interface keeps context clean, keeps costs predictable, and keeps task completion rates high. The wrong interface burns tokens on overhead, fills the context with data the agent does not need, and produces failure rates that make the workflow unreliable enough to require human babysitting. Building CLIs for your most frequently called services is the single highest-leverage improvement available to most teams running production AI agents today. Printing Press makes the build fast. The savings show up immediately on the next session that runs.

The session-level habit that cements these savings is running the slash-context command in any Claude Code session where you suspect context bloat. The output shows exactly which tool descriptions and which data are consuming context tokens. For most teams, the first time they run this check after installing several MCP servers, the number is surprising. Tool descriptions for services the agent never called in that session are sitting in context, paid for and doing nothing. Identifying those and replacing the heaviest MCP integrations with CLIs is the concrete action that turns the theoretical 35x saving into a real reduction on the next API invoice. The principle transfers across any stack: the less the agent has to carry in context to do its work, the cheaper, faster, and more reliable every task it runs becomes.