The first time I connected an AI agent to real tools, I thought the hard part would be the AI. It was not. The hard part was choosing the plumbing. There are three common ways an agent can reach your software, and the choice quietly decides your costs, your reliability, and how much of the model’s brain is left for actual thinking.
One number sold me on taking this seriously: in one widely shared report, the tool descriptions an agent loaded at startup consumed 72 percent of its context window before it had done any work at all. The agent showed up to the job with most of its working memory already spent.
The bridge decides the bill
An AI model on its own can only produce text. To do anything real, like reading a file, querying a database, or creating an issue in a project tracker, it needs a bridge to other software. Three bridges dominate right now, and they get mixed up constantly because they can all end up triggering the same action.
A restaurant makes the difference easier to hold in your head. An API is ordering by menu number: rigid, fast, and nothing gets lost in translation. A CLI is leaning into the kitchen and speaking the kitchen’s own shorthand: powerful if you know the lingo, and the AI happens to know it fluently. MCP is a standard menu format that any waiter from any restaurant can read out to you: flexible, but somebody has to read you the whole menu before you order anything.
- An API (application programming interface) is the menu of requests a piece of software accepts from other software. “Give me user 42” or “create this order”, sent over the web, answered in a structured format.
- A CLI (command line interface) is the text-command version of a program, the kind
you type in a terminal:
git commit,ls,npm install. - MCP (Model Context Protocol) is the newest of the three and the only one invented for AI. It is a standard way for a tool to describe itself to a model: “here is what I can do, here is what each action needs”, so any compatible agent can discover and call it.
The three bridges
The same intent, “create an issue titled Bug in login”, can travel any of the three bridges. What differs is who needs to know what, and what it costs.
flowchart LR A[AI agent] --> C[CLI bridge] A --> P[API bridge] A --> M[MCP bridge] C --> S[Your software] P --> S M --> S
With an API, a developer writes ordinary code that calls the service, and the agent either triggers that code or is not involved at all. This is the right bridge when the step is predictable and needs no judgment. It is the cheapest and fastest option because no model has to reason about it.
With a CLI, the agent types commands the way a person would. This works surprisingly well for one reason: models were trained on decades of public documentation, tutorials, and forum posts about tools like git and docker. The knowledge is already inside the model, so nothing extra has to be loaded. In one benchmark, a CLI approach used a couple of hundred tokens per command while the equivalent MCP setup carried tens of thousands of tokens of overhead, a 4 to 32 times difference in cost. The same tests found the CLI path completed its runs reliably while the MCP path succeeded 72 percent of the time.
NOTE
A token is the unit AI models read and bill in, roughly a short word. The context window is the model’s working memory, measured in tokens. Anything you load into it, including tool descriptions, competes with the actual task.
With MCP, every tool publishes a description of itself, and those descriptions ride along in the agent’s context. That is the overhead in the numbers above, but it buys things the other two bridges cannot:
- It works for software that has no CLI at all, which is most SaaS products.
- Each user can log in as themselves (per-user OAuth, the “sign in with” flow), and access can be revoked per person. An agent typing commands runs as whoever owns the terminal.
- One MCP server works across different AI providers, so the integration is built once.
IMPORTANT
MCP’s cost is not a one-time fee. The tool descriptions are sent with every request, on every run, whether the tools get used or not. Ten connected servers you rarely use are a tax on every single conversation. Connect what you need, disconnect what you do not.
Side by side, the trade looks like this:
| API | CLI | MCP | |
|---|---|---|---|
| In one line | Code calls the service | The agent types commands | Tools describe themselves to the AI |
| Token cost per use | None (no AI involved) | Low (~hundreds) | High (tens of thousands) |
| Reliability | As reliable as your code | Very high (well trained) | Varies by server quality |
| Login / access | One shared key in your code | Whoever owns the terminal | Each user signs in as themselves |
| Best for | Predictable, repeated steps | Local, mature, documented tools | Remote SaaS, multi-user, no CLI |
Choosing a bridge
After reading far too many comparison posts, the decision pattern that keeps showing up is stage-based, not ideological. As a flow, it is short:
flowchart TD
Q1{Does the step need
AI judgment at all?} -->|no| API[Call the API from code]
Q1 -->|yes| Q2{Is the tool local and
well documented?}
Q2 -->|yes| CLI[Let the agent use the CLI]
Q2 -->|no| Q3{Remote service, or
per-user login needed?}
Q3 -->|yes| MCP[Connect it over MCP]
Q3 -->|no| CLI
The same flow in words: deterministic steps go straight to the API in ordinary code, because a model should not reason about something a function can do. Local, mature tools like git and package managers go through the CLI, cheap and already known to the model. Remote services, per-user logins, and tools with no CLI go through MCP. And in production, real systems mix them: the pattern I keep seeing described is CLI for the local development loop and MCP for the remote integrations, running side by side.
TIP
A decent default for a solo builder: start with direct API calls in code, add CLI access when the agent needs to drive local tools, and reach for MCP only when a remote service gives you no other door. You can promote a tool up the ladder later.
Going deeper: why the reliability gap?
The benchmark gap (a CLI path completing every run while the MCP path managed 72 percent) is not because MCP is badly designed. CLI tools are old, boring, and heavily represented in training data, so models rarely misuse them. MCP is young: servers vary in quality, descriptions can be vague, and a model facing fifty unfamiliar tool schemas has more ways to pick wrong. Boring and well documented beats new and clever, which is a lesson that extends well past AI plumbing.
Pick the boring bridge
The three bridges are not competitors, they are different tools with different bills. And notice what actually made the comparison make sense: knowing what an API is, what a CLI is, and what a context window costs. That is fundamentals again. Vibe coding an agent together without knowing which bridge it stands on works right up until the bill arrives, or until the agent quietly loses most of its memory to tool menus.
Pick the boring bridge until the boring bridge cannot do the job.
Sources
- Firecrawl: MCP vs CLI for AI agents for the token cost benchmarks, reliability numbers, and the inner/outer loop pattern
- Jam with AI: When to use MCP vs API vs function calls for the stage-based decision framework
- MindStudio: CLI vs MCP vs API for AI agents for the three-way comparison and the context overhead report