MCP vs CLI for AI Agents: What Actually Reaches the Model (Measured on a Live Agent Fleet, 2026)

MCP vs CLI is the agent-tooling fight of 2026, and most of it is argued from a lab bench. Someone runs 75 GitHub tasks both ways, counts the tokens, and declares a winner. Useful, but it isn’t how an agent lives. So here’s the other view: what actually reaches the model when an agent runs a real job, measured on the run that wrote this post.

Quick context. I run 10+ autonomous brand containers on Claude Code. This post was researched, written, illustrated and published by one of them at midnight while I slept. Its job tonight touched the Airtable keyword queue, a Google SERP, eight competitor articles, an image pipeline and WordPress. It did all of that through the command line: curl plus a few lines of Python. No MCP tools were called.

That doesn’t make CLI the winner. It makes CLI the right fit for this kind of work, and the honest numbers below include the place where my CLI setup costs more context than a well-built MCP server would. By the end you’ll know which side of the MCP vs CLI line your agent’s jobs fall on, and the five questions that decide it.

MCP vs CLI: The Short Answer

Both are ways for an AI agent to take action. They differ in how the agent learns what it can do and what lands in its context window while it works.

Question	CLI (the agent runs shell commands)	MCP (the agent calls tools on an MCP server)
How does the agent know what’s available?	Training data (it has seen git, gh, curl millions of times), --help, or a short instruction file	The server lists its tools with names, descriptions and input schemas
What sits in context before work starts?	Nothing, or whatever instructions you load	Tool definitions: all of them (older clients) or names only until used (clients with lazy loading)
Can output be trimmed before the model reads it?	Yes. Pipe it through jq, grep, head or a script	Only if the server or client does it for you
Auth	Whatever the CLI uses, usually an API key or a local login	Built for per-user OAuth, scoped access and revocation
Blast radius	A shell can do anything the user can	Only the tools the server exposes
Best fit	You are the user, the tool has a CLI or a simple HTTP API, and the jobs repeat	Your customers are the users, the service needs OAuth, or the client has no shell

The one-line rule I use: if the agent has a shell and you’re the only user, start with CLI. If other people connect their own accounts, or the AI app has no shell at all, that’s MCP’s job.

If you’re still fuzzy on the layer underneath both, I covered the protocol itself in MCP vs API. This post is about the interface the agent holds in its hands.

What “CLI” Means When an Agent Holds the Keyboard

When people hear “CLI” they picture a developer typing in a black window. In the MCP vs CLI debate it means something more specific: the AI agent gets one tool, a shell, and writes its own commands. Claude Code, Codex, Gemini CLI and Cline all work this way. The model types gh pr list --state open or curl -s https://api.airtable.com/..., the shell runs it, and the output comes back as text.

Three things make that surprisingly strong:

• The model already knows the tools. git, curl, aws, kubectl and gh are all over the training data. Nobody has to describe them first.
• Commands compose. One line can fetch, filter and count: curl ... | jq '.records[].fields.keyword' | head -20. With MCP, that’s often several separate tool calls, each one passing its full result back through the model.
• The output is yours to trim. This is the big one, and it’s where my numbers come from in a minute.

MCP, the Model Context Protocol, works the other way round. A server wraps a service and publishes a menu of tools (“create_issue”, “search_files”) with a description and an input schema for each. The AI app reads the menu and calls tools by name. It’s tidy and standard, and it works in places with no shell at all, like a chat app on your phone.

The hidden third option: skills

There’s a middle path that most MCP vs CLI posts treat as a footnote, and it’s the one my whole business runs on: a CLI plus a written instruction file. Claude Code calls these skills. Mine are plain markdown files that say “here’s the endpoint, here are the exact field names, here’s the gotcha that burned us last month.” Scalekit’s benchmark found that adding just ~800 tokens of gh tips to a CLI agent cut tool calls and latency by about a third. My files are a lot longer than 800 tokens, and that has a cost I’ll put a number on below.

The Token Bill: What the MCP vs CLI Benchmarks Measured

The numbers everyone quotes come from a handful of public tests. Here they are with their sources, because “MCP costs 30x more” gets repeated a lot without its context.

Scalekit: 75 runs, same GitHub tasks, both ways

Scalekit ran 75 benchmark runs in March 2026. They used Claude Sonnet 4, the gh CLI, and GitHub’s official MCP server with its 43 tools.

Task	CLI tokens	MCP tokens	Gap
Repo language and license	1,365	44,026	32x
PR details and review status	1,648	32,279	20x
Repo metadata and install	9,386	82,835	9x
Merged PRs by contributor	5,010	33,712	7x
Latest release and dependencies	8,750	37,402	4x

CLI also finished 25 of 25 runs. MCP finished 18 of 25 (72%), with most failures being timeouts connecting to the remote server. Their cost estimate for 10,000 operations a month: about $3.20 for CLI vs $55.20 for MCP.

Look at the first row. “What language is this repo?” cost 44,026 tokens over MCP, and nearly all of that is the menu: 43 tool definitions loaded so the agent could use one or two.

The fixes are already shipping

That’s the naive version of MCP, and it’s getting fixed fast:

• Lazy loading. Claude Code now loads MCP tool names up front and fetches the full schema only when a tool is used. The Claude Code Ultimate Guide puts a 5-server setup at roughly 55,000 tokens before this change and about 8,700 after. The same deferral showed up in tonight’s run: 14 of Claude Code’s own optional tools were listed by name only, with no schemas loaded unless used.
• Code execution. Anthropic’s engineering team showed that letting the agent write code that calls MCP tools, instead of calling them one by one, cut one workflow from 150,000 tokens to 2,000. Look closely and that’s the CLI trick: process the data outside the model and send back only the answer.
• Gateways and schema filtering. Scalekit’s own gateway trims the 43 GitHub tools to the 2 or 3 a request needs, which takes MCP from about 44,000 tokens to about 3,000 and failures from 28% to about 1%. I broke down when a gateway is worth running in my MCP gateway guide.

So the fair reading is this: the token gap is real for MCP servers that dump everything into context, and much smaller for MCP done well. The bigger, more lasting difference is the next one. It’s about what happens to the output.

My Receipt: What Reached the Model Tonight

Here’s a measurement no lab benchmark can give you, because it comes from a working job. I logged four of the calls this run made, what each one returned raw, and what I actually let into the model’s context after piping it through a filter. Token counts are estimated at 4 characters per token, so treat them as close but not exact.

Call (tonight, 2026-11-02)	Raw response	What reached the model	Cut
Keyword queue from Airtable (114 rows)	36,570 chars (~9,100 tokens)	60-line summary sorted by difficulty: 7,198 chars (~1,800)	80%
Content calendar triage (4 rows)	30,093 chars (~7,500 tokens)	ID, status and keyword only: 191 chars (~50)	99%
Google results for “mcp vs cli” (DataForSEO)	5,405 chars (~1,350 tokens)	Rank, site and title: 681 chars (~170)	87%
8 competitor articles (Firecrawl)	182,024 chars (~45,500 tokens)	Headings only: 17,037 chars (~4,300)	91%
Total	~254,000 chars (~63,500 tokens)	~25,100 chars (~6,300 tokens)	~90%

Two honest caveats. First, after the triage pass I went back and read the full notes on all four calendar rows, because they held editorial decisions I needed. Filtering doesn’t mean never reading. It means reading on purpose. Second, I then grepped the competitor articles for every line with a number in it, and that took a few thousand more tokens. Even so, the agent never had 45,000 tokens of other people’s articles sitting in its context while it wrote.

That’s the real CLI advantage, and it’s bigger than the schema argument. A tool result over MCP usually lands in context whole, unless the server trims it. A shell command can be shaped before the model ever sees it. Across a job with dozens of calls, that difference compounds.

Where my CLI setup loses

Now the uncomfortable part. A CLI agent still needs instructions, and mine are big. Before tonight’s run did any work, it loaded two files:

• The blog-writing skill file: 47,730 bytes, roughly 11,900 tokens.
• The brand’s main instruction file: 29,597 bytes, roughly 7,400 tokens.

That’s about 19,300 tokens of fixed overhead every night, which is more than double the ~8,700-token lazy-loaded MCP figure above. My “no MCP” agent pays its own schema tax. It’s just written in English instead of JSON.

The saving grace is that the whole library is lazy-loaded too. This brand has 39 skill files totalling about 489 KB (around 122,000 tokens), and each run loads exactly one. That’s the same idea as MCP tool search, done with a scheduler and a filename. If you take one thing from this section: whether you pick MCP or CLI, the context bill is set by what you load and what you let back in.

(If you want the full picture of how those scheduled agents are wired, the agentic OS breakdown covers the scheduler, memory and permissions, and the Claude Code loop guide covers the cron side.)

Where MCP vs CLI Tips Toward MCP

I’m not anti-MCP. I’m anti-paying for it when the job doesn’t need it. Here’s where it clearly earns its keep, including one case I hit myself.

1. OAuth that has to refresh itself

A CLI is happy with an API key in an environment variable. It’s not happy with OAuth: browser redirects, refresh tokens that rotate, access that expires. My fleet learned this the hard way. One brand’s Google refresh token has returned invalid_grant since at least October 5. I checked it again tonight and it’s still dead.

The fix wasn’t an MCP server. It was a small script that mints short-lived tokens from a Google service account, and the inbox agent has used it without trouble ever since. That works because I’m the only user. If my customers each had to connect their own Google account, a script like that falls apart, and per-user OAuth with revocation and audit is exactly what MCP was built for.

2. Services with no CLI

Plenty of business software has no command-line tool and never will. Many HR, design and enterprise SaaS tools fall into this bucket. If the only door in is an OAuth API, an MCP server someone else maintains is far less work than writing your own wrapper.

3. AI apps with no shell

Claude on the web, ChatGPT and most desktop chat apps can’t run curl. If you want a tool to work there, MCP is how you get it in. That’s also why MCP is the right call when you’re shipping an integration for other people’s agents rather than running your own.

4. Stateful, long-lived sessions

Driving a browser through a multi-step checkout, or holding a database connection open across many calls, is awkward as a string of one-off shell commands. A server that keeps the session alive is a better shape. That’s why browser-automation MCP servers like Playwright’s are popular, and why I’d reach for one before scripting a browser by hand. (I covered the interactive side of this in MCP Apps.)

Notice what’s missing from that list: “my agent needs to call an API I control with a key I own.” That’s most of what a small business automates, and it’s where CLI wins on cost, debugging and moving parts. My earlier count found zero MCP calls across this brand’s 39 skill files. Tonight’s count adds one more number: 38 of those 39 files contain curl.

The Safety Question: A Shell Is a Bigger Door

This is the part of MCP vs CLI where the CLI camp gets quiet, and they shouldn’t. A shell can do anything the user account can. An MCP server can only do what its tools expose.

Runlayer’s example is the clearest one I’ve seen. An agent asked to “back up the logs” reads instructions planted in the data, and the second command it’s told to run, aws s3 rm ... --recursive, empties the bucket. With a CLI, the agent’s own judgement is the last line of defence. With a narrow MCP tool like backup_logs, the dangerous command doesn’t exist.

I’ll be straight about my own setup, because I’ve published it before. My scheduled agents run Claude Code with permission prompts switched off, because nobody is awake to click “allow” at midnight. I explained the trade-offs, and what’s missing, in the agent orchestration post. What keeps that sane:

• Each brand runs in its own container. A bad command can wreck one brand’s sandbox, not my laptop or the other nine brands. More on that in Claude Code sandbox.
• Keys are scoped per brand. The WordPress password inside this container only works on this site.
• The jobs are narrow and written down. The agent isn’t browsing the open web and taking orders from it. It follows one skill file per run.

What I’d add before handing a shell agent anything customer-facing: deny rules for destructive commands and a pre-run hook that blocks them. Both are covered in my Claude Code hooks guide. MCP isn’t automatically safe either. Third-party servers are code you’re trusting, and security researchers have found plenty with sloppy credential handling. But a well-scoped MCP tool does shrink the blast radius in a way a raw shell can’t.

A 5-Question Filter: CLI, MCP, or Both

Run each integration through these five questions. You’ll usually have your answer by the third.

1. Does a CLI (or a plain HTTP API) already exist that the model knows well? git, gh, aws, curl against a REST API. If yes, lean CLI.
2. Who is the user: you, or your customers? If it’s just you, one key in one container is fine. If customers connect their own accounts, lean MCP.
3. Is auth a simple key, or an OAuth dance? A key is CLI territory. Refresh tokens across many users are MCP territory.
4. How big is the output, and do you need all of it? If responses are large and you only need a slice, CLI lets you cut it before the model reads it. If you go with MCP, pick servers that filter or use code execution.
5. Can the agent safely have a shell where it runs? Inside a container with scoped keys, yes. In a chat app, or anywhere a wrong command is costly and unreviewed, give it narrow MCP tools instead.

Here’s how that plays out across my own stack:

Job	What I use	Why
Airtable, WordPress, Asana, social scheduling	CLI (curl) + a skill file	Simple keys, one user, big responses that need trimming
Google inbox, Search Console, Analytics	CLI + a service-account token script	OAuth, but I’m the only user. Customer-facing would flip this to MCP
Web research and scraping	CLI against Firecrawl’s API	Pages are huge, and I keep headings and numbers only
Browser tasks with login and state	Would use an MCP server	Long-lived sessions are awkward as one-off commands
Anything a client’s team connects to themselves	Would ship as MCP	Per-user OAuth, revocation, audit trail

Most real setups end up as both. Claude Code itself is a hybrid: a shell for the inner loop, MCP for the services that need it. If you’d rather not work this out integration by integration, this is the kind of map I build for clients. You can get in touch here and I’ll tell you which of your jobs need MCP at all.

MCP vs CLI FAQ

Is MCP dead because of CLI?

No. The criticism is mostly aimed at MCP servers that load every tool into context, and lazy loading, gateways and code execution are fixing that. MCP is still the standard way to give AI apps without a shell, and multi-user products, access to tools. What’s changed is that “add an MCP server” is no longer the automatic first move for a solo builder.

Which is cheaper, MCP or CLI?

In Scalekit’s public benchmark, CLI used 4x to 32x fewer tokens per task. In practice the gap depends on two things: how many tool definitions you load, and how much raw output you let into context. A careless CLI agent that dumps full API responses can burn as many tokens as a careless MCP setup.

Does Claude Code use MCP or CLI?

Both. It runs shell commands natively and can connect to MCP servers, and it lazy-loads MCP tool schemas so unused tools cost little. My scheduled agents mostly use the shell. I compared how other agent tools handle unattended runs in Cline vs Claude Code.

Can I turn an MCP server into a CLI?

Yes. Tools like mcp2cli turn MCP tool schemas into CLI commands so the agent only reads what it calls. It’s most useful for big remote servers and scripted agents without lazy loading built in.

Is giving an AI agent a shell safe?

It’s as safe as the box you put it in. Run it in a container, give it scoped keys, keep its jobs narrow, and add deny rules or hooks for destructive commands. If you can’t do those things, give it narrow MCP tools instead.

Do I need to learn the command line to use the CLI approach?

Less than you’d think. The agent writes the commands. Your job is to write down the job clearly, which endpoint, which fields and what “done” looks like, and to read the log when something breaks. If you can write a good checklist, you can run a CLI agent.

Final Thoughts: Pick by Who’s at the Other End

The MCP vs CLI argument gets framed as a protocol war. In practice it’s a question about who is at the other end of the connection. If it’s you, with your own keys, running the same jobs on a schedule, a shell and a well-written instruction file will be cheaper, easier to debug and simpler to keep alive. If it’s your customers, or an AI app with no shell, MCP is the grown-up answer.

Whichever you choose, watch the two numbers that actually set your bill: what you load before the job starts, and what you let back into context while it runs. Tonight’s job let in about a tenth of what the APIs sent back, and it still started with 19,000 tokens of instructions I should probably trim. Both are fixable, and neither depends on which side of the debate you’re on.

Start with one integration. Run it through the five questions. Then measure what reaches the model, because that’s where the real difference shows up.