Tools vs Raw Commands - The Token Cost Theory - Part 1

The Hook

Scalekit ran 75 benchmark runs comparing CLI and MCP agents on identical GitHub tasks. CLI was 10 to 32x cheaper and 100% reliable. MCP hit only 72% — failing on more than a quarter of tasks (source).

Perplexity's CTO reported that MCP tool descriptions consumed 72% of the available context window before the agent performed any actual work (source).

The narrative is everywhere: MCP is the future, CLI is legacy. But the numbers tell a different story — and one where the real answer isn't "pick one."

The Token Cost Theory

Every interaction an AI agent makes has a token price — input tokens (the instruction) + output tokens (the response). Multiply by the token rate, and you get the real cost of a single operation.

But there's a hidden variable: schema overhead. Every MCP server exposes tool definitions — names, descriptions, JSON input schemas. These get injected into the LLM context on every single request, whether you call the tool or not.

PolicyLayer measured 3,875 MCP servers and found a median of 2,064 tokens per server in tool definition overhead (source). A GitHub MCP server alone clocks 14,406 tokens. Connect GitHub + Linear + Supabase: 24,116 tokens — 12% of a 200K context window, before the first message.

The numbers, in my agent

I measured three modes across common operations:

Tool Call:

Input:  50 tokens (tool name + args)

Output: 100 tokens (structured JSON response)

Framing: 20 tokens

Total:  ~170 tokens

Raw Command (with RTK filtering):

Input:  30 tokens (command string)

Output: 350 tokens (RTK-filtered stdout)

Wrapper: 80 tokens (exit code, error type)

Total:  ~460 tokens

Raw Command (unfiltered):

Input:  30 tokens

Output: 3,000 tokens (raw terminal output)

Wrapper: 80 tokens

Total:  ~3,110 tokens

The spread: 1x, 2.7x, 18x — same intent, different delivery.

The real numbers from benchmarks

Independent research paints a wider gap. Afroze Amjad benchmarked graph-cli as both CLI and MCP, finding MCP's per-turn cost was consistently higher — the schema catalog ships with every request (source). When tools hold 50+ schemas, that overhead compounds.

The worst case: a 93-tool GitHub MCP server at 55,000 tokens of schema alone. At $3/M input tokens (Claude Sonnet), that's $0.17 per request for schema the agent doesn't use. At 10,000 requests/day: $51,000/month in schema tax (source).

Why This Matters at Scale

Per-operation costs are academic until you stack them. Here's 100 operations:

The difference between a tool-oriented agent and a raw-command-oriented one over 100 retrievals: $0.29 vs $2.94. At 1,000 operations, that's $2.90 vs $29.40.

But these numbers assume one MCP server. Most agents run 5+ servers (GitHub, Slack, Postgres, Sentry, Filesystem). At 5 servers averaging 2,064 tokens each, that's 10,320 tokens per request just to keep tool descriptions warm — whether the agent runs one operation or zero.

The G/N ratio is the missing variable

The cost structure flips based on how often you actually use a tool (source):

For a tool used on 2 of 20 prompts (10% frequency), 99.3% of MCP tokens are wasted on schema descriptions the agent never needed (source).

The Conflict

But here's the catch: tools aren't free to build. Every dedicated tool must be written, tested, maintained, and updated when the upstream API changes. npmPackageDownloads is 20 lines of TypeScript. The npm view CLI command it replaces was written by npm's team.

The CEO voice in me asks: Why am I duplicating infrastructure that already exists?

Here's the scene that answers that. I'm sitting in WSL, my agent wants to check a package version. It calls npm view — a raw shell command. The output comes back: 2,140 lines of package metadata, README, maintainer list, dependency tree, signature hashes. What I wanted was one field. What I got was a firehose.

The tool call: 170 tokens. The raw command: 2,500+ tokens. The tool was 15x cheaper on that single operation.

Afroze Amjad found the same pattern with graph-cli: CLI saves on cost, MCP saves on latency and discovery. The right answer depends on which dimension your workload optimizes for (source).

Estimation without measurement is anxiety wearing arithmetic as a disguise. So I measured.

The Resolution

Three patterns cut MCP's token cost dramatically:

1. Schema filtering. Instead of injecting all 93 GitHub tool schemas, a routing layer returns only the 2-3 tools relevant to the current request. This alone cuts MCP token usage by ~90% (source).

2. Gateway pattern. Near-zero fixed overhead (~20 tokens/prompt), MCP-quality structured outputs, linear scaling regardless of backend services (source).

3. Hybrid dispatch. The most practical setup (source):

┌─ Query / retrieval?      → MCP tool (structured, typed, fast)

├─ Execute / side effect?  → Raw CLI (small output, no schema needed)

├─ Large output expected?  → MCP tool (schema caps response size)

└─ Filter / pipe needed?   → Raw CLI (jq, grep, UNIX pipes work)

This dispatch matrix cut one practitioner's token usage by 60% — $8.64/day to $3.45/day (source).

The Closing

The MCP backlash is real, but the target is wrong. The problem isn't the protocol. It's the native injection pattern — loading every schema into every prompt, whether the agent needs it or not. The schema tax dominates until you actively manage it.

MCP's per-call cost is a deployment problem, not a protocol problem. Good tool design means routing the tool surface to match actual usage patterns, not defaulting to everything for everyone.

Build tools that return answers, not documents. Route schemas that match actual usage, not every possibility. And when the task is a one-shot retrieval with a CLI you already know: run the command. The token market thanks you either way.

Sources: Scalekit MCP vs CLI Benchmark · Afroze Amjad graph-cli comparison · OnlyCLI token cost benchmark · Mornati MCP vs CLI deep-dive · PolicyLayer MCP cost calculator · Dev.to hybrid dispatch case study · Tyk enterprise comparison guide