MCP tool schemas measured at 4-32x the token cost of equivalent CLI tools

The measurement

When an agent connects to an MCP server, the server answers the handshake with a catalog of its capabilities: tool names, prose descriptions, and JSON schemas enumerating every parameter with its type and its own description. A dev.to post published on August 26 by the developer of a CLI called mcptoon measured what that costs at scale. Counted with tiktoken, OpenAI's tokenizer, 255 tools drawn from 50 MCP servers came to 71,929 tokens when loaded as raw JSON schemas. Listing just the tool names, the way a command-line interface would, came to 123 tokens for the same set.

The author's argument is that these schemas are only truly needed twice per session: when the model selects a tool, and when it supplies arguments. The rest of the time the definitions occupy context that the user's code, conversation history, and the model's own reasoning otherwise need.

One caveat belongs up front: the post promotes the author's own tool, so its central measurement is self-reported. The weight of the piece, however, rests on outside figures it assembles.

Independent numbers point the same way

According to benchmarks the post attributes to Firecrawl, running the same tasks through a plain CLI cost roughly 200 tokens while running them through MCP cost roughly 44,000, a spread the post characterises as 4x to 32x depending on the shape of the task. Scalekit's separate analysis is cited as independently confirming the 32x worst case.

Anthropic's engineering write-up on code execution with MCP, referenced in the post, reports that switching to on-demand tool loading cut context overhead by up to 98.7%, from roughly 150,000 tokens to roughly 2,000. On the protocol side, the proposal SEP-1576 targets schema redundancy reduction and smarter tool selection, which amounts to the specification itself acknowledging the catalog format is bloated. Academic work converges too: MCP-Zero, from Xiamen University and USTC, shows that retrieving tools on demand keeps retrieval cost constant as tool counts grow, while ProMCP, noted as appearing at ACL ARR 2026, profiles where an MCP agent's token budget actually goes.

Why eager loading hurts

On a 128K-context model of the Claude Sonnet or GPT-4o class, 71,929 tokens of definitions consume about 56% of the window before the first user message is processed. On the 64K windows typical of cheaper and faster models, the catalog simply does not fit; operators must either drop servers they spent time configuring or pay for a larger-context model essentially to transport boilerplate. And because schemas ride along with every request, the cost repeats across turns and sessions, an expense the post notes never shows up as a visible line item anywhere.

The proposed fix: an index instead of a catalog

mcptoon, the CLI the author maintains, sits between the agent and the MCP servers. Discovery produces a tiered manifest rather than a schema dump: names only, at 123 tokens for the 255-tool setup, or names plus parameter types at 8,282 tokens, an 88.5% reduction. Full schemas stay on disk in a config file and are never injected into context; when the model settles on a tool, it can request that tool's details. The author is careful to distinguish this from compression, which would still deliver the whole payload into the window eventually. Here the schemas are simply not sent until they are needed.

Execution also routes through the CLI: a call spawns the relevant MCP server, performs the invocation, and tears it down, with a cold start reported at a few hundred milliseconds, plus a serve mode for long-lived connections on hot paths. Errors return in structured form, with did-you-mean suggestions for mistyped server names so an agent can correct itself. An opt-in, off-by-default output encoding called TOON is claimed to trim a further 34% from typical tool responses.

Why it matters

Context windows are the binding constraint on agent quality, and tool catalogs are now large enough to consume most of one before a session begins. What stands out in the post is the convergence: a spec proposal, the company that created MCP, two practitioner benchmarks, and two academic groups all reached the same diagnosis, namely that eager whole-catalog schema injection does not scale. For agent builders the practical playbook is lazy discovery, tiered name-first listings, and keeping schemas on disk until a specific call requires them, trading an occasional extra lookup for a permanently lighter window. The open question is adoption, since patterns like these need support in the clients and servers people already run rather than only in a wrapper CLI.