MCP, a CLI or a Direct API Call

There are three common ways to give an agent a tool: an MCP server, a command-line program wrapped in a skill, or a direct API call the agent makes from a script.

The videos I have notes on mostly argue about which one wins. Nate Herk ranks them, with the CLI first and MCP last. Matt Van Horn says a CLI plus a skill beats MCP. David Soria Parra, who co-created MCP at Anthropic, says the best agents use all of them.

Reading them side by side, I care less about the ranking than about two questions: who else needs this tool, and what does it cost in context.

What each one is

An MCP server speaks a standard protocol. Any client can ask it for its tool list at runtime, whatever service sits behind it. In practice most servers wrap an existing REST API.

A CLI plus a skill is two layers. A local program does the work and prints short output. The skill is a markdown file that tells the agent when to call the program and how. Van Horn's point is that the skill is what makes the CLI discoverable, because a bare binary may never get used.

A direct API call is the agent running a small script that makes the HTTP request. Herk's earlier advice was to keep a saved markdown reference for the API, so the agent does not rediscover the endpoints every session.

What it costs in context

The cost I care about is what lands in the context window, since I pay for that on every turn.

Soria Parra names the MCP problem himself. The common setup loads every connected server's full tool list into the prompt on every turn. His slide puts that at more than 56,000 tokens per turn, falling to about 9,000 when the server exposes one search tool and the model fetches definitions on demand. He calls that progressive discovery. The numbers come from a slide and he has a commercial interest in MCP. He is also describing a weakness in his own protocol, which makes me trust it more.

The best evidence on the CLI side is a screenshot in Herk's video. Pulling a community feed returned roughly 132,000 tokens of JSON over the wire, and about 2,000 reached the model, because the program wrote the payload to disk and passed along a summary. The CLI did not shrink the response. It kept the response out of the context window. That is one pull of one feed, but it shows the mechanism cleanly.

His other numbers I do not accept. The same video says MCP used 35 times more tokens than a CLI and that reliability fell from 100 percent to 72 percent. No source appears on screen. A later Eric Tech video shows what looks like the origin, a benchmark credited to scalekit: 25 of 25 for the CLI against 18 of 25 for MCP, and 3.20 USD against 55.20 USD a month at 10,000 operations. Eighteen of 25 is 72 percent. The methodology is not shown in either video, and 25 is a small sample. I read it as directional.

A direct API call sits wherever you put it. If the raw JSON goes straight to the model, it is expensive. If a script filters it first, it is cheap. A CLI is that filter made permanent, with a cache.

Who else needs it

This is where MCP earns its overhead. Soria Parra's case for it is typed semantics, independence from any one platform, and enterprise auth and governance. If a tool has to work from clients I do not control, such as someone else's harness, a desktop chat app, or a team with access rules, then a shared protocol is the whole point.

A CLI plus a skill is for me and my agent on my machine. It can be shared: Herk packages a CLI and its skill into a private repo, with keys staying in each person's local env file. Every user then needs the runtime and a harness that reads skills.

Van Horn adds login as a practical cost. His complaint is that MCP integrations always feel logged out, while a CLI can re-authenticate itself. That is one builder's experience, but it is a cost token counts do not show.

One detail keeps me from taking the loudest CLI arguments at face value. Printing Press, the generator Van Horn built and Herk's video promotes, emits a CLI, skills, and an MCP server from the same run. What loses is the thin MCP wrapper that loads everything up front.

A small decision table

Situation	Reach for	Why
Only my agent and I use it, and responses are large	CLI plus a skill	The payload stays on disk and the skill costs a description until it is used
A well-known CLI already exists, like `git` or `gcloud`	That CLI, no skill	ZazenCodes' rule: the model already knows it
Other people or other clients need it, with access control	MCP server	Standard discovery and auth; check that it supports progressive discovery
A rare call inside a script	Direct API call	Nothing to maintain; filter the response before the model sees it
The service has no public API	A CLI built on the site's own endpoints	There is nothing for MCP to wrap; expect it to break when the site changes

Where this leaves my setup

I run four MCP servers in Claude Code, and the rule in my own notes is to judge each server separately instead of replacing them as a group. My research skill already has the two-layer shape: the skill carries the procedure and a separate open-source tool, yt-vision-pro, does the frame extraction.

Before moving anything, I would check the /context readout with and without each server. One that supports on-demand discovery may cost very little.

Key Takeaways

Ask who else needs the tool. If the answer is other clients or other people with access rules, that is what MCP is for.
Ask what reaches the context window. A CLI wins when it keeps a large payload on disk and returns a short answer.
A direct API call is fine for rare use, as long as code sits between the response and the model.
The 72 percent reliability figure appears to trace to a 25-sample benchmark with no methodology shown. The 35-times token figure has no source on screen.
"MCP loses" really means that servers which load every tool definition up front lose.

Sources

Next I want the actual /context cost of each MCP server I run, so the decision rests on my numbers and not on someone's slide.