MCP vs CLI for AI agents: the context cost, measured
An MCP server charges the context window twice: its tool schemas ride in every prompt whether they are used or not, and every result lands whole. A CLI with a fixed output contract charges once, when the agent reads the surface, and lets the agent trim the result before it arrives. Measured on nine real MCP servers with 258 tools, the raw tool listing is 236,818 bytes and the compiled CLI describe is 58,309 bytes, a 4.1x difference.
measured 2026-09-03servers 9tools 258method docs/bench.md
Written by Wes Sander, who built declick. Updated 2026-09-04. Every number on this page comes from node scripts/bench-tokens.mjs in the declick repository, where the method and its caveats are written up.
What does an MCP server cost an agent per prompt?
An MCP server costs its full tool list on every turn. When an MCP client connects, it calls initialize and tools/list, and the response, every tool name, description and JSON schema, goes into the model's context. It stays there for the whole session. Nine stdio servers on one machine, measured once each, came to 236,818 bytes of listing, roughly 59,000 tokens at four bytes per token. One server with 124 tools accounted for 94,525 bytes of that on its own.
adapter tools raw init+tools/list declick describe describe --verb ratio
agentcash-mcp 12 22,420 bytes 3,334 bytes 1,111 bytes 6.7x
chrome-devtools 29 25,992 bytes 6,290 bytes 1,098 bytes 4.1x
context7-mcp 2 5,954 bytes 1,300 bytes 1,086 bytes 4.6x
dashclaw-mcp 19 22,030 bytes 4,560 bytes 1,183 bytes 4.8x
fs 14 13,128 bytes 4,506 bytes 1,299 bytes 2.9x
offlocal 124 94,525 bytes 25,680 bytes 1,216 bytes 3.7x
playwright-mcp 24 18,643 bytes 4,757 bytes 1,031 bytes 3.9x
repowise-mcp 9 18,329 bytes 2,448 bytes 1,114 bytes 7.5x
xapi 25 15,797 bytes 5,434 bytes 1,181 bytes 2.9x
total 258 236,818 bytes 58,309 bytes 10,319 bytes 4.1xWhat does the same server cost as a CLI?
Compiled to a CLI, the same nine servers cost 58,309 bytes for every verb on every adapter, and the agent does not read that whole. It reads declick describe <adapter> for the one adapter it needs, under 2,000 characters by contract, then declick describe <adapter> --verb <verb> for the one verb it is about to call. That per-verb read held between 1,031 and 1,299 bytes across servers with anywhere from 2 to 124 tools, because reading one tool's detail costs the same no matter how many others exist. That column is the number that generalizes. The whole-adapter ratio grows with tool count, the same way tools/list does.
$ declick describe fs
$ declick describe fs --verb read-file
$ declick run fs read-file README.md --fields content --max-bytes 2000Does a CLI make each call cheaper too?
No, not by itself. Per call, the CLI can cost slightly more: declick wraps every result in {ok, data, meta}, so list-allowed-directories on the filesystem server came back at 160 bytes raw and 191 bytes through declick. The per-call saving comes from trimming, which the agent controls: --fields a,b keeps named fields, --limit N caps a list, --where k=v filters it before either, and --max-bytes N puts an 8,192-byte ceiling on data by default. A raw MCP result has no equivalent. It lands whole.
When is MCP the better choice?
MCP is the better choice when the agent has an MCP client and no shell, when a server exposes a handful of tools whose listing is small, or when the tool needs a stateful session the server holds open. A two-tool server measured 5,954 bytes raw, and the difference at that size is not worth an extra layer. A CLI is the better choice when the agent runs from a shell, when the server has dozens of tools, when results are large and need trimming, or when the same agent also needs an API, a database or a window, since every declick engine returns the same envelope and the same five exit codes.
Can an agent keep its MCP servers and still get the CLI?
Yes. declick setup reads the MCP servers an agent already has configured and compiles each one into an adapter, without removing the server. declick setup --revert puts every file back byte for byte. A stdio server is spawned per call, and that spawn is most of what a call costs, so declick daemon start keeps the servers warm between runs: a server that takes 600 ms to start answered in 59 ms warm instead of 703 ms cold. The guard, the audit line and the local policy stay on the client side of that socket.
$ npm i -g declick
$ declick setup
$ declick daemon start
$ declick listRun an MCP server from the command lineGenerate a SKILL.md per adapterRead the declick overview