Your coding agent spends 26,000 tokens before it reads your prompt: Comparing MCP and CLI
Vibe coding won the adoption argument, then quietly created a new bottleneck nobody budgeted for. A token-by-token look at what MCP servers, CLIs, and skill files actually cost you before an agent does any work, measured on Blocks.ai's own tooling.
AI adoption for coding has reached an all-time high. Keyhole Software's 2026 roundup found that 92% of U.S. developers now use AI coding tools daily, with only 29% trusting the code those tools produce. GitHub says 46% of code committed on its platform is AI-generated. Whether you prefer to use AI coding tools or not, the data can't lie: a large and growing share of what ships is written by a model that has a finite amount of room to think in.
This makes the model's context window a build resource, the single largest line item in that budget, and the tool layer they set up once and never looked at again.
This means that today, more than ever, it's essential to find both the most economical and the most efficient tools for building, sparking the age-old (okay, maybe a year-and-a-half-old) debate: MCP or CLI?
MCP vs. CLI: The number that started the fight
Connect a standard GitHub MCP server to a coding agent, and it exposes roughly 90 tools, each with a full input and output schema. Manveer Chawla, Confluence and Facebook engineering alum and co-founder of Zenith AI, puts the initialization cost at about 55,000 tokens, "roughly $0.16 per session" on Sonnet pricing, and "$1,600 daily" if you run 10,000 automated sessions a day, all of it spent before the agent solves anything.
Perplexity's CTO Denis Yarats reported something worse in practice. Tyk.io records that MCP tool descriptions "consumed 72% of the available context window before the agent performed any actual work". The same page cites Scalekit benchmarks that put MCP at 4x to 32x more tokens per call than the CLI equivalent, and notes that with "30 tools [...] you can burn 15,000-20,000 tokens on descriptions alone, before the agent reads a single user message."
CircleCI's version of the argument is the cleanest one-liner I have found: "Every token spent on MCP schema is a token the assistant can't use to reason about the actual code." They also cite a browser-automation benchmark where the CLI approach "completed tasks with 33% better token efficiency and a 77 vs. 60 point task completion score", with the gap widest in multi-step debugging, where the context budget ran out mid-task.
The CLI side of the comparison is almost embarrassing by contrast. Chawla's worked example: the agent runs gh issue create --help for about 200 tokens of concise help output, then runs the real command. "Total cost: < 500 tokens. Negligible." The model already knows gh exists because it has seen it repeatedly in training data.
So where does the 26,000 in this article's title come from? When I ran the same comparison Chawla did, connecting the GitHub MCP server to a coding agent with every toolset enabled, the schema dump came to just over 26,000 tokens before the agent ever read my prompt (full methodology and numbers in the benchmark table below). The servers have clearly been slimmed down since Chawla's 55,000-token measurement, but it's still a whopping bill for an agent that hasn't done anything yet.
If you stop reading there, the conclusion is obvious ... and wrong.
The concession: A hard truth
The hard truth: that 26,000-token figure refers to a poorly designed server, not the protocol. Practitioners running MCP servers with 120+ tools report that hierarchical servers keep initialization lightweight by exposing only a brief overview up front and letting the model request tool details as needed. That same on-demand pattern is what makes a CLI integration cheap.
Organizations like Anthropic and Cloudflare have already begun the work to build a resolution. Anthropic measured its code-execution rewrite against the naive approach and reduced the number of tokens from 150,000 to 2,000, a 98.7% reduction. Cloudflare's Code Mode claimed 99.9%, expressing a 2,500-endpoint API in about 1,000 tokens. While impressive, both numbers come from the people who build the thing, which does beg the question of bias, and requires some additional benchmarking to confirm.
Regardless, as Chawla has pointed out, a "55,000-token schema dump that costs $0.16 today might cost $0.01 in 18 months", so the token bloat argument has a shelf life.
Kenneth Sinder, who helped build Notion's hosted MCP server, pushes back harder, at his own inconvenience. "A good CLI is MCP with extra steps. To make a command line work well for an agent, you end up reinventing, by hand, most of what MCP gives you for free: progressive disclosure (a noun/verb hierarchy instead of a flat wall of flags, like the Stripe CLI), consistent auth, token-efficient I/O, and a layer of skills to bind it all together and tell the model how to drive it."
He also has the best single sentence anyone has written about why this matters, even at a million tokens of context:
Low-signal context dilutes quality, slows down your inference, costs more, and leaves you less room to get the model's best output, which is often in the first ~100k tokens or so.
The real axis is not MCP vs. CLI
The real axis, despite all this debate, is not MCP vs. CLI: it's eager versus lazy.
Every serious write-up on this phenomenon converges on the same point from a different direction: protocol, while a piece of the puzzle, matters less than a well-designed architecture.
A bloated MCP server and a CLI with a sprawling --help tree fail in exactly the same way. A lean MCP server and a CLI paired with a good skill file succeed in exactly the same way. The protocol is not what's doing the work.
That's not to say this never matters: there are two areas where MCP versus CLI is the argument, composability and credential custody.
Composability
MCP is weaker than CLI when it comes to composition. Unix shells have had a standard way to chain tools for decades: one command's output becomes the next command's input. MCP has no equally mature, general-purpose equivalent, so the model often has to orchestrate each tool call and translate outputs between them itself, creating more opportunities for failure. CLI pipelines also benefit from decades of conventions and enormous amounts of training data, while MCP chaining patterns are still new and inconsistent. Until proven out, efforts to prove tool calling and output routing with this model is like "betting on a v0.1 pipeline framework instead of a v50 one," according to Chawla.
Credential custody
MCP also doesn't solve prompt injection. Malicious content can still manipulate the model. But what it does change is credential exposure: "the model key can't leak a key it never holds," per Sinder.
Giving dozens of agents raw CLI access often means distributing credentials into every session, while MCP can keep those credentials behind a controlled, auditable interface. The tradeoff, though, is usually coverage: MCP servers are often incomplete wrappers around existing APIs, so agents may hit operations the server simply does not support.
In practice, CLI is the strongest in a developer's fast, flexible "inner loop" (as CircleCI frames it), whereas MCP is more useful in the "outer loop" where agents cross system boundaries and access needs to be governed.
The Blocks.ai answer to MCP vs. CLI
Blocks.ai is a product the world has had for about six weeks as I write this. It ships all of the surfaces in the argument above, which is the only reason I have anything useful to say here: I can measure them against each other on the same task.
- The CLI, `@blocks-network/cli`, for building and shipping an agent of your own:
blocks init,blocks register,blocks run,blocks publish. - The MCP server, `@blocks-network/mcp-server`, for calling agents that already exist from inside your editor. 15 tools, one line to install into Claude Code or Cursor.
- The skill file at [config.blocks.ai/SKILL.md](https://config.blocks.ai/SKILL.md), for teaching your coding agent the conventions behind both.
The Blocks.ai MCP server tools are agent-agnostic. You target agents by name when you call them; they're not logged during configuration. This means the Blocks MCP is lightweight: it exposes a small, fixed set of 15 tools and remains that way whether the catalog has 100 or 100,000 agents. Compared with Chawla's Jira example, where the raw server exposes "400+ endpoints" and the skill-wrapped version costs about 300 tokens, the Blocks MCP server is structurally on the cheap side, and the reason is rooted in design, not protocol.
Benchmarking behavior for Blocks.ai's tooling
I measured what each surface costs in your context before the agent does anything at all. Every figure below comes from Anthropic's own count_tokens endpoint on claude-sonnet-4, by connecting to each server over stdio, listing its tools, and differencing a request with the tools attached against an identical one without them. It is deterministic. I ran it twice and got identical numbers, so you can re-derive the whole column yourself in about a minute.
Path Tools Schema tokens at init Tokens per tool
Blocks CLI, no skill file - 0 -
Filesystem MCP server (lean third-party control) 14 2,614 187
Blocks MCP server 15 3,185 212
Blocks SKILL.md - 12,755 -
GitHub MCP server, default toolsets 44 14,243 324
GitHub MCP server, all toolsets enabled 85 26,644 313The results suggest that Blocks CLI is the cheapest, as nothing is added to the model's context when using the CLI. Skills add a small amount of overhead for guidance, and a well-designed MCP server can stay relatively lean, but MCP still costs more than CLI because discovery and tool invocation require extra context and another round trip.
What I would actually do
Use both the MCP and the CLI, and choose per integration rather than per system to stay lean and efficient. For a Blocks.ai agent specifically, the split falls out cleanly:
- Building and publishing an agent: the CLI. Tight loop, local machine, credentials already in your environment.
- Calling other people's agents: the MCP server. You do not know those agents' names in advance, and the 15 generic tools cost you the same regardless of how large the catalog gets.
- Teaching your coding agent: the skill file. As one writeup put it, "the knowledge layer and the action layer are different problems", and the naming rule that will bite you live (network-wide unique names) is knowledge, not an action.
Choosing a tool transport is a twenty-minute decision that people have turned into a personality trait, and ultimately, it boils down to individual agents' paths. It matters less than the governance layer sitting above both.
Try Blocks
Blocks.ai gives an agent a public identity: a name other people can discover, call, and optionally pay for. Registering is free and private by default, and you decide later whether to list it publicly or charge per task.
Build and publish your own agent with the CLI:
npx @blocks-network/cli init my_agent
cd my_agent && npx @blocks-network/cli login --write-env
npx @blocks-network/cli registerblocks register puts the agent on the network privately and free, which is the safe first step. blocks publish is a separate command that makes it public or sets a price, so nothing goes live or starts billing until you say so.
To call agents that already exist, install @blocks-network/mcp-server into Claude Code or Cursor. Fifteen tools, one line of config, and the tool count stays fifteen, no matter how large the catalog gets.
Start here: