Progressive MCP vs CLI: which actually cuts tokens?
AI Architect
Key takeaways
- Anthropic's 98.7% figure describes code execution against MCP servers presented as code APIs, with the servers still in place.
- The Agent Skills specification defines progressive disclosure in three stages, starting at roughly 100 tokens per skill at rest.
- MCP tools/list returns every tool's full inputSchema, which is the actual source of the upfront cost people attribute to the protocol.
- The widely repeated 20x and 35x CLI savings come from secondary blog posts, and I could not trace either to a published method.
- A CLI drops the discovery and integrity guarantees the protocol specifies, which is a real trade rather than a free win.
The argument doing the rounds is that MCP is a token tax and a CLI is the cure, usually with a multiplier attached. I went looking for where those multipliers came from.
What is progressive MCP and how does it compare to a CLI?
Progressive MCP is the practice of loading capability detail in stages rather than all at once. A skill’s name and description sit in context permanently at roughly 100 tokens, the instruction body arrives only when the skill activates, and its supporting files arrive only when a step reaches for them. The alternative under discussion is giving the agent a shell and a set of commands, where a command name and a help string cost less than a JSON Schema.
The two differ in what the model can find on its own. MCP is a discovery protocol: the agent can enumerate what exists, read a manifest, and verify it before use. A CLI assumes the agent already knows the command is there. That difference is the whole trade, and most of the argument online skips it to compare token counts.
What has actually been measured?
One thing, published by the party with the clearest view of it. Anthropic’s engineering team reports that a Google Drive to Salesforce workflow, moving a meeting transcript between the two, fell from 150,000 tokens to 2,000 when the agent wrote code against the MCP servers instead of calling their tools directly. That is a 98.7% reduction and it is a real result.
One Drive to Salesforce transcript transfer, as measured by Anthropic
Show data
| Item | Value (tokens) | Note |
|---|---|---|
| Direct tool calls | 150,000 | Definitions and intermediate results both cross the context. |
| Code execution against the same servers | 2,000 | A 98.7% reduction. The servers did not go anywhere. |
Read what it compares. Both sides of that measurement are MCP. The servers stay connected in the efficient version; the change is that the model writes code against them as an API rather than receiving every tool definition and every intermediate result through its context. Nothing in the experiment removes the protocol.
The 20x and 35x figures attached to “delete your MCPs” posts are a different matter. I could not trace either to a published method, a task list or a reproducible harness, and every version I found cites another blog rather than a measurement.
Why do MCP tool definitions cost so much?
Because a client cannot call a tool correctly without its schema, and
tools/list
returns the complete inputSchema for every tool a server exposes.
The specification does supply relief. Results are paginated, and since revision
2026-07-28 they carry ttlMs and cacheScope, which this site has
worked through separately. Servers are also asked
to return tools in a deterministic order so the block stays cacheable.
What it does not supply is filtering. There is no semantic search over tools, no way for a client to ask for the three definitions relevant to this request. A connected server’s definitions reach the model whether or not the task needs them, and caching makes that cheaper without making it smaller.
How does progressive disclosure work?
Three stages with numbers attached, which is more than the CLI argument offers.
What loads, and when, under progressive disclosure
Show as text
| # | Layer | Note |
|---|---|---|
| 1 | Name and description, every skill | About 100 tokens each, at startup. |
| 2 | SKILL.md body, on activation only | Under 5000 tokens recommended. |
| 3 | scripts, references and assets | Loaded only when the task calls for them. |
| · | staged above, unstaged below (breakpoint) | |
| 4 | MCP tools/list: every tool's full inputSchema | Paginated and cacheable, never filtered. |
The Agent Skills specification loads a
skill’s name and description at startup for every skill, at roughly 100
tokens each. The full SKILL.md body loads only when the skill is activated,
with a recommendation to stay under 5000 tokens and 500 lines. Supporting files
under scripts, references and assets load only when a task reaches for
them.
The description field does the work that makes this viable. It is capped at
1024 characters and is meant to say both what the skill does and when to use it,
because that string is what the model matches a task against while the body is
still unloaded. A vague description breaks the whole model: the skill either
never activates or activates constantly.
That is the shape the CLI argument is reaching for, written down and versioned. A skill sitting unused costs about what a command name costs, and the difference is that a host can enumerate it and verify it.
What does a CLI give up?
Two things the protocol specifies, both of which matter more as a deployment grows.
Discovery is the first. A CLI has no skills/list, so an agent knows a command
exists only because something told it, which in practice means a prompt that
carries the same tokens you were trying to avoid, or a human wiring it in.
Verification is the second. Skills served over MCP carry a SHA-256 manifest, and a host must check every file before use, which I wrote about earlier today. A binary on the path has no equivalent. Whatever is at that path when the agent runs is what executes.
Origin is the third, and it is the one people notice last. The skills extension makes identity the originating server plus the URI, so a host can tag loaded content with where it came from and refuse a cross-server read. A shell command arrives with no provenance at all, which matters when the agent is choosing among capabilities that several teams installed.
Which should you use?
The framing is the problem. “MCP or CLI” sounds like a choice between two products when the measured win came from moving execution into a sandbox and loading definitions lazily, and both of those are available without removing anything.
My working rule is to count first. Call tools/list against your connected
servers, serialise the result, and look at the number before accepting any
multiplier, this article’s included. Most deployments I have seen carry two or
three servers whose definitions nobody has looked at since they were added, and
the honest fix is usually to disconnect one server rather than to re-architect
around a blog post.
Where the numbers do justify a change, code execution is the better-evidenced path, and it is worth being clear-eyed that Anthropic names its price in the same document: a sandbox with resource limits and monitoring, which direct tool calls do not need.
Do this
Choose between a tool, a skill and a CLI for one capability
Work capability by capability rather than deciding the question once for a whole stack. The three surfaces fail in different places, and most systems want more than one.
Count what your connected servers put in the context before any work starts
Call tools/list against each server and measure the serialised result. That number is paid on every request that carries the definitions, and it is the figure the argument is actually about. Measure it before you accept anyone's multiplier, including the ones in this article.
Keep a tool when the model must choose it unprompted
A tool definition is expensive because it is discoverable. The model sees the schema and can decide to call it without being told the capability exists. If you need that, you are buying the tokens for a reason.
Move it to a skill when the model needs a procedure rather than a call
A skill costs about 100 tokens at rest and loads its body only on activation. Multi-step workflows with reference material fit this shape, and the staging is specified rather than improvised.
Reach for a CLI when the agent already has a shell and the capability is obvious
A command name and a short help string cost less than a JSON Schema. Accept that you lose enumeration and verification, and that the agent now needs to know the command exists from somewhere else.
Use code execution when intermediate results are the expensive part
This is what produced Anthropic's figure. The agent writes code against the servers, and filtering happens in the sandbox rather than by passing every intermediate result through the model.
Budget the sandbox before choosing that path
Anthropic names the cost plainly: agent-generated code needs a secure execution environment with sandboxing, resource limits and monitoring. Direct tool calls avoid that operational surface, and for a small deployment the sandbox can cost more than the tokens it saves.
Frequently asked questions
- Should I delete my MCP servers and use a CLI?
- Not on the strength of the numbers currently circulating. The one figure with a named method behind it is Anthropic's, and in that experiment the MCP servers stayed, presented to the model as code APIs instead of as tool definitions. The saving came from where execution happened, and the protocol stayed in place.
- What exactly is progressive disclosure?
- A three-stage loading model defined in the Agent Skills specification. Name and description load at startup for every skill, roughly 100 tokens each. The full SKILL.md body loads on activation, recommended under 5000 tokens. Supporting files in scripts, references and assets load only when a task calls for them.
- Why do MCP tool definitions cost so much upfront?
- Because tools/list returns each tool's complete JSON Schema, and a client needs that schema to call the tool correctly. The spec supports pagination and caching, so the cost can be amortised, but there is no semantic search over tools, so a connected server's definitions reach the model whether or not the task needs them.
- Is a CLI actually cheaper?
- Per invocation it is usually smaller, since a command name and a help string carry less than a JSON Schema. What you give up is discovery and verification: no skills/list to enumerate what exists, and no digest to confirm the thing you approved is the thing you ran.
- Can I get both?
- That is what the code execution pattern is. Keep the servers for discovery and identity, expose them to the model as an API it writes code against, and let the sandbox filter intermediate results before they reach the context. Anthropic is explicit that this buys you a sandbox to run and secure.