How to Optimize MCP Token Usage (Without Replacing It With Bash)

In early 2026, a sharp opinion started making the rounds in developer circles: MCP barely works, and almost everything it does could just be a bash script. It came from well-known engineers and it landed hard, because it had a ring of truth to it.

The criticism is half right. The token cost problem it points at is very real and measurable. But the conclusion "just use bash" misses where the industry is actually heading. The useful question isn't MCP or CLI. It's how do you keep MCP and stop it from eating your context window?

This post covers what MCP actually costs in tokens, seven techniques to bring that cost down, and when a plain CLI really is the better tool.

What is MCP token usage, and why does it cost so much?

What is MCP token usage, and why does it cost so much?

If you're newer to AI agents, here's the 30-second version.

An AI agent is an LLM that can do things: call APIs, run commands, read and write files; not just chat. To do that, it needs tools.

MCP (Model Context Protocol) is a standard from Anthropic for how an agent discovers and calls those tools. Think of it as a universal plug: any tool that speaks MCP can connect to any agent that speaks MCP.

A CLI (bash) is the other approach: don't build special tool connectors at all. Just give the agent a sandboxed terminal and the command-line tools it already knows such as: git, curl, jq, aws, kubectl and friends. The model learned these from millions of examples during training, so it's already fluent.

That fluency is the CLI's superpower. The agent can chain commands into a single pipeline, and it only "pays" to learn a tool's options when it actually runs “--help”. Nothing is loaded until it's needed.

MCP, by default, works the opposite way and that's where the bill comes from.

The context tax: what MCP token overhead actually measures

An LLM has a context window, its working memory for a conversation. Everything in it costs tokens, and tokens cost money, latency and space. The problem with naive MCP is that it eager-loads: every connected tool's full description gets dumped into that memory up front, whether the agent ends up using it or not.

The numbers are uncomfortable:

That accuracy figure is the part people miss. In the same study, code generation degraded by 17.0% and reasoning tasks by 10.2% once MCP context was added. Token bloat isn't only a cost problem, it's a quality problem.

Three things drive it:

1. Eager loading: every tool definition lands in the prompt by default, burning tokens before anyone says hello.
2. Round-tripping: intermediate results flow back through the model instead of staying in a sandbox, the way a shell pipeline keeps them.
3. Verbose envelopes: JSON-RPC wrapping inflates even plain text by another 30–50%.

How to optimize MCP token usage: 7 techniques that work

The good news: almost all of that overhead is an implementation choice, not a property of the protocol. Here's what to do about it, roughly in order of payoff.

1. Stop eager-loading: use progressive disclosure
Expose a small discovery surface instead of every tool definition. The agent asks what's available, then loads only the definitions it needs for the task in front of it. This is the single biggest win, because it attacks the cost that gets paid on every request whether or not a tool is used.

2. Put a search or router tool in front of your catalogue
Instead of loading fifty tools, load one router tool that can find the right one semantically. Discovery becomes a runtime lookup rather than a fixed context tax.

3. Let the agent write code against MCP instead of calling tools one by one
Anthropic's own code-execution pattern has the model write a short script that calls MCP servers, so loops, conditionals and intermediate results stay in the execution environment. In their Google Drive → Salesforce example this took a task from 150,000 tokens to 2,000, a 98.7% reduction.

4. Filter data where it lives, not in the context window
If a tool returns a 10,000-row sheet, filter, aggregate and summarise it in the sandbox and return the twenty rows that matter. Every row that crosses into context is paid for twice: once in tokens, once in the attention it steals from the actual task.

5. Design tools around intent, not around your API surface
A one-to-one wrapper over a REST API produces dozens of thin, overlapping tools with long schemas. One well-named tool that does what a user actually wants replaces ten of them, and its description is shorter than any of theirs.

6. Trim the schemas themselves
Shorten descriptions, drop optional parameters the agent will never set, flatten deeply nested objects, and prefer compact response shapes over verbose JSON envelopes. Unglamorous, but this is often a 30–60% cut for an afternoon's work.

7. Split work across subagents
Give each subagent only the tools its domain needs, rather than handing one agent the union of everything. Reported overhead reductions land in the 50–60% range, and tool selection gets more reliable as a side effect.

A quick way to measure your baseline: start a session with your MCP servers connected, send a single trivial message, and look at the input token count. That number is what every conversation pays before any work happens. If it's more than a few thousand tokens, techniques 1 and 2 will pay for themselves immediately.

When a CLI is still the better choice

Optimisation has limits, and sometimes the honest answer is that you didn't need a protocol.

A CLI shines when you control the environment. If your users are developers, your targets already ship command-line tools, and you're single-tenant, a sandboxed shell gives the model something it's already fluent in at close to zero context cost.

Where MCP still earns its keep

Here's what the "just use bash" crowd glosses over: some things are genuinely hard to do in pure shell.

Think of an enterprise SaaS app like HR, finance or CRM with no public CLI, where the agent acts on behalf of many different users, each with their own OAuth permissions, and where you need audit trails and the ability to revoke access centrally. You can't reasonably rebuild that in a shell script, and you wouldn't want to try.

The actual answer: bury MCP, don't delete it

So the 2026 consensus isn't "MCP or CLI." It's a hybrid, and the trick is the same in every winning pattern: keep MCP, but hide it behind a layer that loads only what's needed.

There's a nice irony here. The engineer who first popularised the "bash is better" line now ships a tool that converts MCP servers back into a single CLI command — itself a hybrid move.

A simple way to decide:

• Use a CLI when you control the environment, your users are developers, your tools have command-line interfaces, and it's single-tenant.
• Use MCP when the target has no CLI, you've got multiple users with different OAuth scopes, and audit trails matter.
• Use the hybrid when you're in doubt. Wrap MCP behind a meta-tools gateway, expose it through a CLI surface or a Skill, and let the agent compose it like any other Unix tool.

TL;DR 

• MCP's token problem is real: measured input-token growth of 3.25× to 236.5×, and an average 9.5% accuracy hit.
• Nearly all of it comes from eager-loading tool definitions and round-tripping data through the model.
• Fix it with progressive disclosure, a router tool, code execution, in-sandbox filtering, intent-shaped tools, leaner schemas, and subagents.
• Keep the CLI for developer-controlled, single-tenant environments; keep MCP for multi-user, OAuth-scoped, audited ones; and reach for the hybrid whenever you're unsure.

Reference

Song, W., Zhong, H., Ding, Z., Xue, J., & Li, Y. (2025). Help or hurdle? Rethinking Model Context Protocol-augmented large language models (arXiv:2508.12566). arXiv. https://doi.org/10.48550/arXiv.2508.12566

Anthropic. (2025). Code execution with MCP: building more efficient agents. https://www.anthropic.com/engineering/code-execution-with-mcp