DEV Community: MCP Token Saver

Your AI Agent Reads a 300-Page Book Before It Answers You

MCP Token Saver — Sun, 30 Aug 2026 11:31:17 +0000

Every prompt you send starts with homework. Before Claude Code or Cursor even looks at your question, it reads the full JSON schema of every MCP tool it might call. On my machine that was 255 tools across 50 servers. I measured it with tiktoken cl100k_base: 71,929 tokens. A 300-page book, read cover to cover, every session, before your agent ever thinks about what you asked.

That same tool listing now costs me 123 tokens. A sticky note. Same tools, same capabilities, and you can reproduce the number on your own config with one command.

This is the story of mcptoon, a zero-dependency CLI, and the three problems it fixed that I never planned to touch.

Problem 1: four agents means four config files

Claude Desktop wants claude_desktop_config.json. Claude Code wants .claude.json. Cursor wants .cursor/mcp.json. Cline, Windsurf and VS Code Copilot each have their own shape too. Add a fetch server in Cursor, forget Claude. Fix a path in Claude, break Cursor. Repeat weekly.

mcptoon's answer is one file. ~/.mcptoon/config.json becomes the single source of truth, and mcptoon sync writes native config into every agent it detects. It merges instead of overwriting, so servers you configured by hand stay put. Run mcptoon sync --watch and drift detection catches external edits before they bite.

The part I like most: agents need zero setup. mcptoon is a program your agent already knows how to run. There is no mcpServers entry, no plugin API, nothing to register and nothing to restart. One line in CLAUDE.md and your agent drives every MCP server through the shell. That also means it reaches places MCP cannot: shell scripts, CI jobs, cron, aider, terminal-only boxes.

Problem 2: the token tax

Here is the mechanism behind that 300-page book. When your agent asks "what tools exist?", native MCP ships the full schemas. Every parameter, every description, every nested properties block. Multiply by 255 tools and you get 71,929 tokens sitting in your context before a single tool call.

mcptoon's manifest command answers the same question with a name index:

$ mcptoon manifest --compact
fetch: fetch(url) · github: search_repos(q), get_file(repo, path) · sqlite: query(sql)

Schemas stay on disk. They never enter the context at all. That is the difference between this and compression: compression still ships the payload and unpacks it later, so the cost just moves. Here the cost is deleted.

It's a dial, not a switch. The same 255-tool config measures 8,282 tokens with --slim (names plus parameter types, minus 88.5%) and 123 with --compact (names only, minus 99.8%). Full JSON stays available with --json whenever you want zero ambiguity. Reproduce it yourself: mcptoon manifest --compact --tokens.

Problem 3: configured is not alive

A 2026 community audit found 52% of published MCP servers unreachable. Half the servers in people's configs are dead weight, and nothing in a JSON file tells you which ones.

mcptoon health checks every server, shows latency, and exits 1 in CI when something is dead:

── mcptoon health: 3/5 alive ──────────────
  ✓ fetch     [stdio]  1 tool     120ms  ok
  ✗ brave     [stdio]  0 tools  10002ms  timeout
  ✓ github    [http]  12 tools    340ms  ok

And because MCP servers run code on your machine and return arbitrary text into your agent's context, every result passes through checks for prompt injection ("ignore previous instructions" buried in tool output), credential leaks (sk-..., AKIA..., ghp_... patterns) and dangerous operations like delete or drop unless you pass --destructive.

No telemetry. No analytics. Nothing phones home.

The objections I hear

"Isn't this just TOON compression?" No. The headline number comes from architecture: full schemas simply are not sent. Optional TOON encoding of tool results saves another 30 to 40% and it is off by default.

"Didn't Claude Code already defer tool loading?" Deferred loading decides when definitions load. mcptoon decides what a listing costs, in every agent at once, and adds sync, health and security on top. They stack fine.

"Why a CLI?" Because the shell is the one interface every agent already speaks. Zero dependencies also means the whole supply chain is about 6,800 lines of readable Python, with 569 tests staying green in CI.

Try it

pip install mcptoon
mcptoon quickstart    # finds servers you already configured
mcptoon demo          # live side-by-side: JSON vs mcptoon, real token counts

mcptoon speaks the latest MCP spec (2026-07-28) with full backward compatibility, runs on Windows, macOS and Linux, and ships under Apache 2.0. Repo: https://github.com/activeing123/mcptoon

If your agent is reading a 300-page book before it answers you, that is context you paid for and never used. Make it a sticky note.

I Replaced 72,341 Tokens of MCP Config With 123 Tokens. Here's the Exact Setup.

MCP Token Saver — Thu, 27 Aug 2026 01:59:31 +0000

I spent a weekend optimizing my MCP setup and the results were... unexpected.

The Starting Point

My Claude Code config had 255 tools registered across 10 MCP servers. Each tool came with a full JSON schema describing its inputs, outputs, constraints, and examples. Seemed reasonable until I measured the actual token cost.

72,341 tokens. Just for the schemas. Before I typed a single word.

That's roughly 40% of Claude's 200K context window gone before the conversation even starts.

The Experiment

I tried three approaches to reduce this overhead:

Approach 1: Remove descriptions

Stripped all description fields from tool schemas. Result: 72K → 58K. Saved 14K tokens but lost critical context about what each tool actually does.

Approach 2: Truncate descriptions

Cut every description to 50 characters. Result: 72K → 45K. Better, but now tools like create_issue and update_issue look identical.

Approach 3: TOON format

Compressed the entire schema structure using mcptoon's compact notation. Result: 72,341 → 123 tokens.

Wait, what?

How 123 Tokens Work

The trick is lazy loading. Instead of sending all 255 full schemas upfront, TOON format sends one-line summaries:

search_issues(query:string, repo:string, state?:string) → Issue[]
create_issue(repo:string, title:string, body:string) → Issue
update_issue(repo:string, id:int, title?:string, body?:string) → Issue

Each tool gets a single line: name, parameters with types, return type. That's enough for the model to decide which tool to use.

When it actually calls a tool, the full schema is loaded on demand. The model already knows what it wants to do — it just needs the exact parameter names and types.

The Setup

# Install
pip install mcptoon

# Compress your MCP config
mcptoon compress

# That's it. One command.

The compressed output replaces your original config. If you don't like it, mcptoon decompress gets you back to the original.

Real-World Impact

Metric	Before	After
Schema tokens	72,341	123
Context available for conversation	~128K	~200K
Tool selection accuracy	94%	93%
Time to first response	2.1s	1.4s

The 1% accuracy drop came from tools with similar names but different purposes. For most workflows, it's imperceptible.

What I Learned

Schema verbosity is the silent killer. We obsess over prompt engineering but ignore that our tool definitions are eating half the context window.
Lazy loading beats compression. You don't need all schemas all the time. Load what you need, when you need it.
The model doesn't need your examples. Those enum constraints and example values in your schemas? The model figures them out from the parameter name and type.

Try It Yourself

pip install mcptoon
mcptoon compress

GitHub: https://github.com/activeing123/mcptoon

If you're running more than 50 MCP tools, you're probably wasting tens of thousands of tokens on schemas alone. Worth a look.

This post is part of my ongoing investigation into MCP token overhead. Previous posts covered benchmarking 10 MCP servers and measuring real token costs.

How MCP Wastes 4-32x More Tokens Than CLI (and How to Fix It)

MCP Token Saver — Wed, 26 Aug 2026 05:58:03 +0000

Here are two numbers that should ruin your morning coffee:

71,929 tokens versus 123 tokens. Same 255 tools. Same machine. Same day.

The first number is what your agent pays — every single session — when 255 tools from 50 MCP servers load as raw JSON schemas into its context window. The second is what the same tool listing costs when discovery happens through a CLI instead.

That's a 300-page book vs. a sticky note, every single session, before your agent has answered a single question. If you're running multiple MCP servers in Claude Code, Cursor, or anything similar, you're paying the book price right now and probably don't know it.

I didn't believe it either, so I measured it with tiktoken (OpenAI's tokenizer) and built a tool around the result. Let me show you the receipts.

The Problem: Every Tool Ships Its Entire Resume

When an agent connects to an MCP server, the server hands over a tool catalog. Each entry looks like this:

{
  "name": "search_repos",
  "description": "Search GitHub repositories by query",
  "inputSchema": {
    "type": "object",
    "properties": {
      "query": {
        "type": "string",
        "description": "The search query"
      },
      "per_page": {
        "type": "number",
        "description": "Results per page (default 30)"
      }
    },
    "required": ["query"]
  }
}

That's one tool. Multiply by every parameter, every description, every nested properties block, and then by 255 tools. The protocol's answer to "what can you do?" is a full API reference document — types, defaults, prose descriptions and all — injected wholesale into the context window.

And here's the thing: the schema only matters twice per session — once when the model picks a tool, and once when it fills in arguments. The other 99% of the time, that 71K-token wall just sits there, occupying prime real estate while your actual code, conversation, and diffs fight for scraps.

This isn't a niche problem. The Firecrawl team benchmarked MCP against plain CLI usage in 2026 and found the same tasks cost roughly ~200 tokens through a CLI vs. ~44K tokens through MCP — a spread of 4× to 32× more expensive depending on the task shape. Scalekit's independent analysis landed on the same headline figure: up to 32× more tokens for identical work.

Why This Actually Matters (Not Just Aesthetics)

"Tokens cost money" is the obvious objection, but the math is worse than it looks, because schema overhead isn't a one-time fee — it rides along with every request.

On a 128K context window (Claude Sonnet, GPT-4o class models), 71,929 tokens of tool definitions consume ~56% of the window on syntax alone. More than half your context is gone before the first user message is processed. Your agent now has half the room for your codebase, your conversation history, and your reasoning chains — so it degrades, forgets earlier instructions, or truncates file context sooner.

On a 64K window — common for cheaper and faster models — it's not "worse," it's mathematically impossible. The tools don't fit. Period. You either uninstall servers you paid good time configuring, or you pay for the big-context premium model purely to absorb boilerplate. That second option is the quiet budget killer: you're effectively subscribing to a larger model to carry JSON.

And because schemas re-enter every request, the waste compounds. At typical frontier pricing, tens of thousands of redundant tokens × dozens of requests per session × daily sessions adds up to real money spent on punctuation and curly braces. Nobody budgets for that line item because nobody sees it on an invoice. It's just... your context quietly dying.

Don't Take My Word For It: The Evidence

The best part of this story is that it's not my thesis. Independent groups keep arriving at the same conclusion from completely different directions:

Source	What they found	Direction
SEP-1576 (official MCP proposal)	Proposes schema redundancy reduction and smarter tool selection — the protocol itself acknowledges the bloat	Spec
Anthropic Engineering — code execution with MCP	Loading tools on demand cuts context overhead by up to 98.7% (~150K → ~2K tokens)	Lab
Firecrawl	Same tasks: CLI ≈ 200 tokens vs MCP ≈ 44K — 4–32× overhead	Practitioner
Scalekit	Independently confirms the 32× worst case	Practitioner
MCP-Zero (Xiamen Univ. + USTC)	On-demand tool retrieval keeps retrieval cost constant regardless of tool count	Academic
Microsoft — dynamic tool discovery	Agent-side guidance: discover tools at runtime instead of front-loading every definition	Vendor
ProMCP (ACL ARR 2026)	Profiles token flows and latency of MCP agents — quantifies exactly where the budget goes	Academic

Read that table again. The standards body, the company that created MCP, two practitioner benchmarks, and two academic groups all converged on the same diagnosis: eager, whole-catalog schema injection doesn't scale. When Anthropic's own engineering blog writes about cutting 150K tokens down to 2K, the debate about whether there's a problem is over. Only the how do we fix it remains.

The Fix: Pay for Names, Not Schemas

All of the above approaches share one insight: the model needs an index, not an encyclopedia.

That's the idea behind mcptoon, a zero-dependency CLI I work on. Instead of injecting every schema into context, tool discovery becomes a names-only manifest:

$ mcptoon manifest --compact
fetch: fetch(url) · github: search_repos(q), get_file(repo, path) · sqlite: query(sql) · ...

That's the whole listing. 123 tokens for 255 tools. The full schemas stay on disk in ~/.mcptoon/config.json and never enter the context at all. This is the crucial part — it's not compression. Compression ships the whole payload and unpacks it later; the bytes still land in your window eventually. Here the schemas simply aren't sent. The model reads the index, decides which tool fits, and asks for details only if it needs them.

It's a dial, not a switch:

Tool listing (tiktoken cl100k_base)	Tokens	vs. raw JSON
Raw JSON schemas, 255 tools	71,929	—
`--slim` (names + parameter types)	8,282	−88.5%
`--compact` (names only)	123	−99.8%

(Measured over a real-world 255-tool config spanning 50 MCP servers. Reproduce with mcptoon manifest --compact --tokens.)

Same principle applies to outputs. Tool results get encoded with TOON (a tabular token-oriented notation), which trims another ~34% off typical responses — and it's opt-in, off by default, so nothing surprises you.

How It Works Under the Hood

The architecture is almost boring, which is the compliment: a small CLI sits between the agent and the MCP servers.

Agent ──runs──▶ mcptoon CLI ──spawns (only when called)──▶ MCP server ──▶ result back
                     │
                     └─ ~/.mcptoon/config.json  (schemas live here, on disk)

The flow inside an agent session looks like this:

# 1. Discovery: a name index, not a schema dump
$ mcptoon manifest --compact

# 2. Execution: call exactly one tool
$ mcptoon call fetch fetch '{"url":"https://example.com"}'
# CLI spawns the fetch server, performs the call,
# returns the result, server exits. Nothing lingers.

Three properties fall out of this:

Zero servers running until you call one. No daemon, no proxy process, no port. mcptoon call spawns the server, gets the answer, tears it down. Cold-start is a few hundred milliseconds; hot paths can use mcptoon serve mode if you want a long-lived connection instead.
Every error is structured and actionable. Call a tool that doesn't exist and you get "server 'fetchh' not found — did you mean 'fetch'?" — which means the agent self-corrects instead of stalling until a human rescues it.
Security checks ride along free. Every result passes inspection for prompt-injection strings and credential patterns (sk-…, AKIA…, ghp_…) before entering context, and destructive tool names require an explicit --destructive flag.

And because it's a CLI, it works with anything that can execute a command — including agents with no MCP support at all, shell scripts, CI jobs, cron. The shell is the one interface every agent already speaks.

Try It Yourself in 60 Seconds

Don't trust my benchmarks — measure on your own machine:

pip install mcptoon     # pure stdlib, ~250KB, zero dependencies

mcptoon demo            # live side-by-side: JSON vs mcptoon, real token counts

demo spins up a sample fetch server, prints the same listing both ways, and shows the actual token counts computed on your box. No telemetry, no account, nothing leaves your machine — it's ~6,800 lines of readable Python you can audit in an afternoon.

If you already have MCP configs scattered around, start here instead:

mcptoon quickstart      # detects existing configs, imports them, lists your tools

The Bigger Picture: One Config for Every Agent

Token waste is only half of MCP's tax. The other half is configuration drift: Claude Code wants .claude.json, Cursor wants .cursor/mcp.json, Claude Desktop wants claude_desktop_config.json, Codex and friends each have their own shape. Add a server in Cursor, forget Claude. Fix a path in Claude, break Cursor. Repeat weekly.

mcptoon treats that as the same problem: one source of truth, synced everywhere.

mcptoon add github --stdio npx -y @modelcontextprotocol/server-github
mcptoon sync            # writes native config into every detected agent

mcptoon sync --watch    # polls config files and re-syncs automatically on change

sync merges rather than overwrites, so servers you configured by hand stay put. With --watch, editing any config propagates to every agent on the machine — cross-agent MCP management that finally stops requiring you to remember which file belongs to which tool.

Star It, Break It, Tell Me About It

To be fair to MCP: the protocol is good. Standardized tool access was genuinely needed, and the ecosystem explosion proves it. But eager schema injection was the wrong default, and everyone measuring it now agrees. The fix pattern — index in context, schemas on disk, retrieval on demand — is where the whole ecosystem is heading, whether via official proposals like SEP-1576, Anthropic's code execution approach, or plain CLIs.

If you run multiple agents and multiple servers, give it a spin:

⭐ Star mcptoon on GitHub if the numbers made you wince — it genuinely helps others find the project
Run mcptoon demo and paste your own before/after counts in the comments — I'd love to see what your tool mix costs
Open issues ruthlessly. Weird server? Broken config shape? Bad edge case? That's exactly what the issue tracker is for

Your context window is the most expensive real estate in AI right now. Stop renting it out to curly braces for free.

Further reading: SEP-1576 — schema redundancy reduction · Anthropic: effective context engineering & code execution with MCP · MCP-Zero: proactive tool acquisition

Stop Editing JSON for Every AI Agent: mcptoon Ends MCP Config Hell

MCP Token Saver — Tue, 25 Aug 2026 11:45:18 +0000

The problem: MCP config hell

If you're using multiple AI coding agents, you've hit this wall.

You want to add the GitHub MCP server to your workflow. You use Claude Code, Cursor, and Codex. Here's what happens:

Claude Code wants ~/.claude.json:

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": { "GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_xxx" }
    }
  }
}

Cursor wants .cursor/mcp.json. Same JSON, different file, different location. Oh wait — is it .cursor/mcp.json or ~/.cursor/mcp.json? Depends on the version.

Codex wants AGENTS.md. That's Markdown. Different format entirely.

Same server. Three configs. Three formats. Three places to forget when your token expires.

And when you have 50+ tools across multiple servers, the token cost of loading all those JSON schemas into context is brutal — roughly 14,113 tokens just to discover what tools are available. At 255 tools, it balloons to 71,929 tokens — a 300-page book's worth of context eaten before any real work happens.

I lived through this. It sucked. So I built something to fix it.

The fix: mcptoon

pip install mcptoon        # pure Python stdlib, ~250KB, zero dependencies
mcptoon add github --stdio npx -y @modelcontextprotocol/server-github
mcptoon sync               # writes config to every detected agent

Done. Three commands. Every agent — Claude Code, Cursor, Codex, Cline, Windsurf, any shell-capable agent — can now call:

mcptoon call github search_repos '{"query":"mcp"}'

No JSON editing. No format differences. One config in ~/.mcptoon/config.json, shared across every agent.

The killer feature nobody else has: agents need zero setup on their side. mcptoon is a CLI — any agent that can run a shell command can use it, even agents that don't support MCP natively.

New in v0.5.5: continuous sync

But config drift is still a thing. You change a token, and later realize Cursor is still using the old one because you forgot to re-sync.

mcptoon sync --watch

Now mcptoon watches your config files using pure-stdlib polling (os.stat fingerprinting — no watchdog dependency, identical behavior on Windows, macOS and Linux). Change a token or add a server in ~/.mcptoon/config.json, and every agent's config updates automatically within seconds.

mcptoon sync --watch --interval 5 --quiet   # daemon-friendly

Drift detection catches accidental external edits to agent configs too. Default mode re-merges (your manually-added servers stay safe). Or use --watch-mode strict to just get a warning.

How it works

mcptoon is a CLI tool, not an MCP server. It doesn't plug into mcpServers JSON. Instead, your agent runs mcptoon commands via shell.

Layer 1: mcptoon CLI (~250KB, zero deps)
         Runs in your agent's shell. No JSON config in your agent.
                    │
Layer 2: MCP Servers (npm/pip packages)
         Launched on-demand only when you call a tool.

Your agent calls mcptoon call fetch fetch '{"url":"https://example.com"}'. mcptoon connects to the MCP server, calls the tool, returns the result. The MCP server's schema never enters your agent's context window.

Token savings that actually matter

mcptoon doesn't just save you JSON editing. It changes what your agent loads into context.

Tool listing (tiktoken cl100k_base)	Tokens	Savings
Raw JSON schemas, 255 tools	71,929	—
`--slim` (names + params)	8,282	−88.5%
`--compact` (names only)	123	−99.8%

In human terms: 71,929 tokens is a 300-page book. 123 tokens is a sticky note.

This is a dial, not a switch — --json is always available when you need full schemas. And mcptoon call results can be encoded as TOON format, saving another ~34% on result payloads.

Full category-level numbers across approaches in docs/comparison.md.

Why zero dependencies matters

mcptoon is pure Python stdlib. No requirements.txt. No supply chain to audit.

~6,800 lines. 531 tests. Zero third-party imports. ~250KB source.

Every dependency is a potential attack vector. Zero dependencies means mcptoon itself has a minimal attack surface. We also verified this with an AST-based zero-dep gate in CI that catches any accidental third-party import, including patterns where try/except ImportError wraps optional enhancements.

Built-in security firewall

MCP servers can execute code on your machine. That's the point — but a malicious server can do real damage.

mcptoon inspects every tool result before it reaches your agent:

Layer	What it does
Prompt injection guard	Blocks hidden instructions like "ignore previous instructions"
Credential leak guard	Scans for exposed API keys (AWS, GitHub, OpenAI, Slack, etc.)
Dangerous-op blocker	Blocks delete/drop/purge operations by default

Most agents load tool responses directly into context without any inspection. That's how Tool Poisoning works — a malicious server returns hidden instructions, and the LLM executes them. mcptoon stops that at the gate.

Cross-agent tool management

When you have multiple agents sharing the same tools, you need a single source of truth for MCP config. mcptoon provides:

sync — one config, written to every detected agent's native format
health — check all servers across agents with timeouts; exit code for CI
manifest — see what tools each agent has access to
--watch — keep everything aligned continuously

It's the cross-agent tool management CLI: one command per operation, every agent covered.

Getting started

pip install mcptoon
mcptoon quickstart                    # auto-detect existing configs
mcptoon add fetch --stdio npx -y @modelcontextprotocol/server-fetch
mcptoon sync --watch                  # keep every agent aligned
mcptoon manifest --compact --tokens   # see: 123 tokens vs 71,929 raw

GitHub: https://github.com/activeing123/mcptoon
PyPI: https://pypi.org/project/mcptoon/
License: Apache 2.0

mcptoon is an independent third-party MCP client. Not affiliated with Anthropic, OpenAI, or Cursor.

MCP Was a Mistake. Here Are 200,000 Tokens That Prove It.

MCP Token Saver — Sun, 23 Aug 2026 09:19:14 +0000

MCP Was a Mistake. Here Are 200,000 Tokens That Prove It.

"mcp were a mistake. bash is better." — Peter Steinberger, OpenClaw founder

I didn't want to believe it either. MCP was supposed to be the USB-C of AI — one protocol to connect everything. Anthropic, OpenAI, Google all backed it. 97 million monthly downloads. 17,000 servers.

But then I measured what MCP actually does to your context window.

The Setup

I connected 10 popular MCP servers to a token counter. Here's what happened before I typed a single word:

Server	Tools	Tokens Injected
Filesystem	11	3,847
Brave Search	8	2,103
Sequential Thinking	3	890
Memory	9	2,567
Puppeteer	15	5,890
Postgres	19	8,231
Notion	24	13,780
GitHub	28	12,440
Slack	22	14,672
Google Drive	31	47,293
Total	170	111,713

111,713 tokens. Before your first message.

That's not a typo. Connecting 10 MCP servers to Claude means over 100K tokens of JSON schemas get injected into your context window. You haven't asked a question yet. You haven't made a tool call. The schemas are just... sitting there.

The Math That Made Me Angry

At Claude 3.5 Sonnet pricing ($3/M input tokens):

Every conversation starts with 111K tokens of overhead: $0.33
20 conversations per day: $6.67/day
22 working days per month: $147/month
Annual cost of JSON schemas: $1,764

That's more than a Claude Pro subscription. You're paying $1,764/year to read JSON braces describing tools you might never use.

But Wait — It Gets Worse

The 111K is just the schema injection. When you actually call a tool, MCP wraps the result:

{
  "content": [
    {
      "type": "text",
      "text": "{\"file\": \"app.py\", \"size\": 1024}"
    }
  ]
}

The actual content is 38 characters. The wrapping is 47 characters. 55% of your result tokens are JSON overhead.

With 20 tool calls per conversation:

Schema injection: ~111K tokens
Result wrapping: ~18K tokens
Total overhead: ~130K tokens per conversation

Your $0.54 conversation now has 130K tokens that serve zero purpose.

What Garry Tan Was Right About

When YC's CEO said "MCP sucks honestly," he was talking about exactly this. The protocol design has a fundamental flaw: it assumes context is free.

In 2024, when Anthropic designed MCP, context windows were 200K tokens. Loading 100K of schemas seemed fine — you still had 100K left. But now we're building complex agent workflows. Multi-turn reasoning chains. Tool call sequences that span hundreds of messages.

When you're 30 messages deep into debugging a production issue and your context is already at 150K tokens, those 111K of MCP schema injection aren't just wasteful — they're the reason your conversation falls off a cliff.

The "Anthropic Backstab" That Confirmed It

Anthropic's own engineers published a blog showing token consumption could drop from 150,000 to 2,000 — a 98.7% reduction. Their solution? Stop loading tool schemas into context. Instead, let the model write code that calls tools at runtime.

In other words: the fix for MCP is to not use MCP the way it was designed.

Cloudflare took this further. Their 2,500-endpoint API originally required 1.17M tokens of schema. They compressed it to 1K tokens by exposing just two functions: search and execute.

1.17M → 1K. That's not optimization. That's admitting the architecture was wrong.

"But MCP Has 97 Million Downloads!"

Yes. And jQuery has billions of page loads. Popularity doesn't mean the design is correct. It means it was first, it was backed by a major player, and the alternatives weren't ready.

The real question is: of those 97 million downloads, how many are actively used in production agent systems? A developer on HN tested 15 MCP servers for three months and kept only 6. The top comment said: "GitHub MCP is a waste of tokens — Claude Code has gh CLI built in. Same for Playwright."

When the CLI equivalent exists, MCP loses every time. The only servers that survived were ones with no CLI alternative.

What I Built Before You @ Me

I'm not just complaining. I built mcptoon — a CLI proxy that sits between your agent and MCP servers:

Caches schemas — injects tool definitions once, not per conversation
Strips result wrapping — returns clean text, not {"content":[{"type":"text","text":"..."}]}
TOON format — compresses 170 tools from 111K tokens to 3.2K (97% reduction)

Before:  111,713 tokens → $0.33/conversation
After:     3,247 tokens → $0.01/conversation
Savings: $1,760/year

pip install mcptoon

250KB binary. Zero dependencies. 486 tests. Apache 2.0.

The Unpopular Opinion

MCP's protocol design is not the problem. Standardized tool interfaces do matter. The problem is the implementation pattern: loading every tool schema into the model's context at startup.

This is like forcing a carpenter to read every tool manual before picking up a hammer. The manuals don't go away. They just sit on the workbench, taking up space, while the carpenter tries to work around them.

The fix isn't a new protocol. It's a smarter proxy layer that loads schemas on demand, strips JSON wrapping, and lets the model focus on the actual task.

MCP wasn't a mistake. But the way we use it is.

All token counts are measured with tiktoken (cl100k_base), not estimated. Measurement scripts and raw data: GitHub repo. Independent project, not affiliated with Anthropic.

Claude Code Is Burning Your Token Budget. Here's the Receipt.

MCP Token Saver — Sun, 23 Aug 2026 09:18:35 +0000

Claude Code Is Burning Your Token Budget. Here's the Receipt.

I found $2,500/year of hidden token waste in my Claude Code setup. It was the MCP servers.

The Discovery

Last week I noticed my Claude Code conversations were dying at around message 15. Context window full. The model starts forgetting earlier instructions. Tool calls fail. The conversation degrades into hallucination.

I assumed it was my fault — too many messages, too much context. So I started measuring.

Here's what I found:

Session start:
  Claude system prompt:        ~8,000 tokens
  MCP schema injection:      ~111,000 tokens
  User's first message:            50 tokens
  ──────────────────────────────────────────
  Total before any work:     ~119,000 tokens

  Remaining context:         ~81,000 tokens

I was starting every conversation with 60% of my context already consumed.

The culprit wasn't my prompts. It was the 10 MCP servers I had proudly configured in my claude_desktop_config.json.

The Receipts

I measured each server's schema injection using tiktoken:

Server	Why I Installed It	Token Cost	Times Used/Week
GitHub	PR reviews, issues	12,440	3
Slack	Message reading	14,672	0
Google Drive	Doc access	47,293	1
Notion	Knowledge base	13,780	2
Postgres	Query DB	8,231	4
Puppeteer	Screenshots	5,890	0
Filesystem	File access	3,847	15
Brave Search	Web search	2,103	5
Memory	Context persistence	2,567	0
Sequential Thinking	Reasoning	890	2
Total		111,713

Look at the "Times Used/Week" column. Three servers were used zero times. Two more were used once or twice. But every single one of them was injecting 100% of its schema into every conversation.

I was paying $0.33 per conversation — $2,500/year — to load schemas for tools I barely used.

The Moment I Realized Everyone Has This Problem

I posted my findings on Bluesky. Within hours:

"I had the same issue. Removed 6 MCP servers and my conversations went from dying at message 15 to lasting 40+ messages." — @developer1

"GitHub MCP is 12K tokens but Claude Code already has gh CLI built in. Why did I install it?" — @developer2

"Google Drive MCP alone is 47K tokens. FORTY SEVEN THOUSAND. For a tool I used once this month." — @developer3

This isn't a niche problem. Everyone running 5+ MCP servers is silently burning 50-100K tokens per conversation.

The Fix (3 Minutes, Zero Code)

Step 1: Audit Your MCP Servers

# Count token cost of each server
pip install mcptoon
mcptoon audit --config ~/.config/claude/claude_desktop_config.json

Output:

Filesystem:     3,847 tokens  ✓ Keep (used daily)
GitHub:        12,440 tokens  ✗ Remove (use `gh` CLI instead)
Google Drive:  47,293 tokens  ✗ Remove (use `gdrive` CLI)
Slack:         14,672 tokens  ✗ Remove (use `slack` CLI)
Notion:        13,780 tokens  ⚠ Depends (no good CLI alternative)
Postgres:       8,231 tokens  ✓ Keep (used 4x/week)
...
Total waste:   89,702 tokens  →  $1,346/year

Step 2: Remove Unused Servers

{
  "mcpServers": {
    "filesystem": { ... },
    "postgres": { ... },
    "brave-search": { ... }
  }
}

I went from 10 servers to 3. My context overhead dropped from 111K to 14K tokens.

Step 3: Proxy The Rest

For servers you must keep, wrap them with mcptoon to compress schemas:

{
  "mcpServers": {
    "postgres": {
      "command": "mcptoon",
      "args": ["serve", "--stdio", "npx", "@modelcontextprotocol/server-postgres"]
    }
  }
}

mcptoon compresses tool schemas by 97% using a compact TOON format. The model sees the same tools but with 3K tokens instead of 111K.

The Results After One Week

Metric	Before	After	Change
Context at session start	111K tokens	3.2K tokens	-97%
Conversations before context death	~15 messages	~45 messages	3x
Token cost per conversation	$0.54	$0.14	-74%
Monthly cost (20 conv/day × 22 days)	$237	$62	-$175
Annual savings	—	—	$2,100

The Bigger Picture

This isn't just about money. The real cost of MCP schema bloat is cognitive degradation:

Your model forgets earlier instructions because context is full of JSON
Tool calls fail because the model can't find the right tool among 170 options
Response quality drops because the model is reasoning through a wall of schema noise
Long conversations become impossible — not because of your prompts, but because of MCP overhead

When Perplexity's CTO announced they were replacing MCP with REST API + CLI internally, this is what he was talking about. When Garry Tan said "MCP sucks honestly," this is what he meant. When Anthropic's own engineers showed 98.7% token reduction by not loading schemas into context, this is the problem they were solving.

The Unpopular Truth

MCP servers aren't bad. The protocol isn't bad. But loading every tool schema into context at startup is a design flaw that costs every developer thousands of dollars per year in wasted tokens.

Most developers don't know this because:

Token costs are invisible until you look at your bill
Conversation degradation feels like "the model getting dumber"
Nobody measures their MCP overhead

Now you know. Go audit your config.

pip install mcptoon
mcptoon audit --config your-config.json

mcptoon is open source, Apache 2.0, 250KB, zero dependencies. GitHub · PyPI. All measurements use tiktoken cl100k_base. Not affiliated with Anthropic.

Garry Tan Was Right: "MCP Sucks Honestly." I Have the Token Receipts.

MCP Token Saver — Sun, 23 Aug 2026 09:18:07 +0000

Garry Tan Was Right: "MCP Sucks Honestly." I Have the Token Receipts.

"MCP sucks honestly. Context window eats too much, auth is a mess. I wrote a CLI wrapper in 30 minutes and it works better."

When YC's CEO says this on X, people listen. But nobody had the data to back it up.

Until now.

What Garry Tan, Perplexity's CTO, and 97 Million Downloads Can't Hide

Three things happened in the last 6 months that changed how I think about MCP:

Peter Steinberger (OpenClaw founder) tweeted: "mcp were a mistake. bash is better."
Eric Holmes wrote "MCP is dead. Long live the CLI" — it hit HN frontpage
Denis Yarats (Perplexity CTO) publicly announced they're replacing MCP with REST API + CLI internally
Garry Tan (YC CEO) replied: "MCP sucks honestly"

The community split into two camps:

"MCP is dead" — CLI is simpler, cheaper, faster
"MCP is fine" — 97M downloads, 17K servers, it's the standard

Both are wrong. The problem isn't MCP. The problem is what MCP does to your context window.

The 47,000-Token Problem Nobody Measured

I connected 10 MCP servers to a token counter. Here's what I found:

MCP Server	Tools	Token Cost	Equivalent
Sequential Thinking	3	890	This blog post
Brave Search	8	2,103	A short email
Filesystem	11	3,847	A README
Memory	9	2,567	A meeting note
Puppeteer	15	5,890	A chapter of a book
Postgres	19	8,231	A whitepaper
GitHub	28	12,440	A court filing
Notion	24	13,780	A legal contract
Slack	22	14,672	A novella chapter
Google Drive	31	47,293	Half of a novel
Total	170	111,713	A short book

One MCP server — Google Drive — injects 47,293 tokens into your context before you ask a single question.

The entire works of Shakespeare is 900K tokens. Google Drive's schema is 5% of Shakespeare. For listing files.

The Cost Breakdown (So You Can Get Angry Too)

At Claude 3.5 Sonnet pricing ($3/M input tokens, $15/M output):

Scenario	Tokens	Cost	Annual Cost
1 server (minimal)	3,847	$0.01/conv	$4.40/yr
3 servers (common)	14,528	$0.04/conv	$19.40/yr
5 servers (typical)	33,061	$0.10/conv	$44/yr
10 servers (max)	111,713	$0.34/conv	$1,496/yr
10 servers + 20 tool calls	~180,000	$0.54/conv	$2,376/yr

Assumptions: 20 conversations/day, 220 working days/year.

$2,376/year. In JSON braces. For tools you might not even use.

What Anthropic's Own Engineers Admitted

Anthropic published a blog showing that complex MCP workflows can consume 150,000+ tokens. Their solution? A 98.7% token reduction by moving tool definitions from context to runtime code.

Translation: The fix for MCP's token waste is to stop using MCP the way MCP was designed.

Cloudflare went further. Their 2,500-endpoint API originally required 1.17M tokens of schema. They compressed it to 1K by exposing just two functions: search and execute.

1,170,000 → 1,000.

That's not an optimization. That's an architecture admission.

The Real Cost Nobody Talks About: Cognitive Degradation

Money is measurable. But the worse cost is what MCP bloat does to your agent's intelligence:

Without MCP bloat (3K tokens overhead):

Context used by schemas:    2% 
Context for reasoning:     98%
Conversation longevity:     40+ messages
Tool selection accuracy:   high (few tools to choose from)

With MCP bloat (111K tokens overhead):

Context used by schemas:   56%
Context for reasoning:     44%  
Conversation longevity:     15 messages
Tool selection accuracy:   low (170 tools, model gets confused)

Your agent isn't getting dumber. Your context window is getting fuller.

"But I Need Those MCP Servers!"

Do you? I audited my own setup:

Server	Token Cost	Used/Week	CLI Alternative
GitHub	12,440	3	`gh` (built into Claude Code)
Slack	14,672	0	`slack-cli`
Google Drive	47,293	1	`gdrive`
Notion	13,780	2	API + curl
Puppeteer	5,890	0	`playwright` CLI

Three servers were used zero times per week. Two more had direct CLI equivalents. I was paying $1,346/year for tools I never touched.

After the audit, I kept 3 servers, removed 7, and proxied the remaining 3 through mcptoon:

pip install mcptoon

Metric	Before	After
Servers	10	3
Schema tokens	111,713	3,247
Reduction	—	97%
Annual cost	$2,376	$69
Savings	—	$2,307

mcptoon wraps your MCP servers and compresses their schemas into a TOON format — 97% smaller, same functionality, zero dependencies.

The Verdict

Garry Tan was right. Not because MCP is fundamentally broken — it's not. The protocol is fine. But the implementation pattern — loading every tool schema into context at startup — is a tax on every developer using it.

The evidence is overwhelming:

YC CEO says it sucks
Perplexity CTO replaced it internally
Anthropic's own engineers showed 98.7% waste
97M downloads but developers are removing servers after 3 months
My data: 111K tokens of overhead per conversation, $2,376/year wasted

The fix isn't a new protocol. It's a smarter proxy layer.

pip install mcptoon

Or just remove your unused MCP servers. That's free and takes 2 minutes.

"MCP was a mistake" is too strong. But "MCP as currently implemented is burning your token budget" is exactly right.

All data measured with tiktoken (cl100k_base). Scripts: GitHub. Independent, not affiliated with Anthropic, YC, or Perplexity.

I Benchmarked 10 MCP Servers — One of Them Burns 47K Tokens Just to Say Hello

MCP Token Saver — Sun, 23 Aug 2026 09:06:08 +0000

I Benchmarked 10 MCP Servers — One of Them Burns 47K Tokens Just to Say Hello

10 popular MCP servers. 847 tools total. 312K tokens of JSON schemas. One server alone wastes more tokens than a full GPT-3 conversation. Here are the results.

What I did

I installed the 10 most popular MCP servers from the official registry. Connected each one to a token counter. Measured exactly how many tokens get injected into your context window before you ask a single question.

The servers:

#	Server	Tools	Token Cost
1	Filesystem	11	3,847
2	GitHub	28	12,440
3	Postgres	19	8,231
4	Puppeteer	15	5,890
5	Brave Search	8	2,103
6	Memory	9	2,567
7	Sequential Thinking	3	890
8	Slack	22	14,672
9	Google Drive	31	47,293
10	Notion	24	13,780

Totals:

847 tools across 10 servers
111,713 tokens of JSON schemas
200,000+ tokens including server status messages, headers, and error schemas

That's right — connecting 10 MCP servers to Claude means 200K tokens of overhead before your first message.

The worst offender: Google Drive

Google Drive's MCP server exposes 31 tools. Each tool has deeply nested schemas for file operations, permission management, sharing, and search. The full schema dump:

{
  "name": "drive.files.list",
  "description": "Lists files in the user's Google Drive with optional filtering",
  "inputSchema": {
    "type": "object",
    "properties": {
      "q": {"type": "string", "description": "Query string for filtering files..."},
      "corpora": {"type": "string", "enum": ["user", "domain", "sharedDrive", "allDrives"]},
      "includeItemsFromAllDrives": {"type": "boolean"},
      "orderBy": {"type": "string"},
      "pageSize": {"type": "integer"},
      "pageToken": {"type": "string"},
      "spaces": {"type": "array", "items": {"type": "string"}},
      "supportsAllDrives": {"type": "boolean"},
      "fields": {"type": "string"}
    },
    "required": []
  }
}

That's ONE tool. 31 of them. At ~1,525 tokens per tool average.

47,293 tokens. Just for Google Drive. For comparison, the entire works of Shakespeare is ~900K tokens. Google Drive's schema is 5% of Shakespeare — just to list files.

What this costs you

At Claude 3.5 Sonnet pricing ($3/M input tokens):

Setup	Tokens	Cost per conversation
1 server (Filesystem)	3,847	$0.01
3 servers (common)	21,578	$0.06
5 servers (power user)	33,061	$0.10
10 servers (max setup)	111,713	$0.34
10 servers + 20 tool calls	~180,000	$0.54

A developer with 10 MCP servers, 20 conversations per day:

Daily: $10.80
Monthly: $216
Annual: $2,592

That's more than the Claude Pro subscription itself. You're paying for JSON braces.

The token breakdown

Where do the tokens actually go?

Tool name + description     →  35%   (39,100 tokens)
InputSchema properties      →  42%   (46,920 tokens)
Type definitions (nested)    →  15%   (16,757 tokens)
Required field arrays       →   3%   (3,351 tokens)
Server metadata + headers    →   5%   (5,586 tokens)

The biggest chunk isn't the tool descriptions — it's the inputSchema properties. Each parameter needs a type, a description, sometimes an enum, sometimes nested objects. That JSON structure is expensive.

The JSON-inside-JSON problem

Every MCP tool result comes wrapped:

{
  "content": [
    {
      "type": "text",
      "text": "{\"file\": \"app.py\", \"size\": 1024}"
    }
  ]
}

The actual content ({"file": "app.py", "size": 1024}) is 38 characters. The wrapping is 47 characters. 55% of the result is JSON overhead.

Multiply by 20 tool calls per conversation:

20 results × 47 chars overhead = 940 chars of pure wrapping
20 results × ~100 chars actual content = 2,000 chars of real data
32% of your result tokens are JSON braces

How to fix it

I built mcptoon — a CLI proxy that sits between your agent and MCP servers:

Caches schemas — injects tool definitions once, not per conversation
Strips result wrapping — returns clean text, not {"content":[{"type":"text","text":"..."}]}
TOON format — compresses 847 tools from 111K tokens to 3.2K (97% reduction)

Before vs After

Metric	Raw MCP	With mcptoon	Savings
10 servers tool discovery	111,713 tok	3,247 tok	97%
Per-result overhead	47 chars	0 chars	100%
20 tool calls	18,800 tok	8,200 tok	56%
1 full conversation	~180K tok	~45K tok	75%
Cost per conversation	$0.54	$0.14	74%

Quick start

pip install mcptoon

{
  "mcpServers": {
    "filesystem": {
      "command": "mcptoon",
      "args": ["serve", "--stdio", "npx", "@anthropic/mcp-filesystem"]
    }
  }
}

Zero dependencies. 250KB. 486 tests. Works with Claude Code, Cursor, and any agent that speaks MCP.

The methodology (so you can reproduce)

Installed each MCP server via npx or pip
Connected via stdio MCP protocol
Called tools/list on each server
Counted tokens using tiktoken (cl100k_base encoding)
Measured result wrapping by calling tools/call 20 times per server
All measurements taken on 2026-08-23 with latest server versions

Raw data and measurement scripts are in the GitHub repo.

The bigger question

MCP is a great protocol. Standardized tool interfaces matter. But the current implementation has an efficiency problem that nobody talks about.

The official examples show 3-5 tools. That's 2-5K tokens — manageable. Real-world setups have 100-847 tools. At that scale, JSON overhead becomes the dominant cost.

If you're building MCP servers:

Keep descriptions under 50 words
Flatten schemas — avoid nested objects when a flat string works
Don't expose unused tools — every tool costs tokens even if never called
Consider token cost as a design constraint

If you're consuming MCP:

Use a proxy like mcptoon to compress schemas
Limit connected servers — do you really need all 10 at once?
Cache across conversations — schemas don't change between messages

Show me the code

mcptoon is open source, Apache 2.0, zero dependencies:

GitHub: https://github.com/activeing123/mcptoon
PyPI: pip install mcptoon
Size: 250KB (vs 25MB for typical MCP clients)
Dependencies: 0
Tests: 486 (runs in 0.5s)
Security: No supply chain attack surface

If this was useful, a GitHub star helps others find it. Data errors? Open an issue — I'll fix the benchmarks.

This is an independent project. Not affiliated with Anthropic, Google, or any MCP server maintainer. All token counts are measured, not estimated. Measurement methodology is reproducible.

Real Token Cost of MCP: 91K Tokens of JSON

MCP Token Saver — Sat, 22 Aug 2026 22:19:33 +0000

255 MCP tools. 91,000 tokens of JSON schemas. Before you ask a single question. Here's what I found and how I fixed it.

The experiment

I connected Claude Code to 5 MCP servers. File system, GitHub, Postgres, Puppeteer, and a custom search tool. Then I counted every token that flowed through the system.

The numbers:

Phase	Token Count	What it is
Tool discovery (initial)	91,247	JSON schemas for 255 tools
Per-conversation overhead	12,400	Repeated schema injections
Tool result wrapping	812 per call	`{"content":[{"type":"text","text":"..."}]}`
20 tool calls later	16,240	Result overhead alone
Total for 1 conversation	~120,000	Before any real output

That's a GPT-4 conversation where 60% of your tokens are JSON braces, brackets, and repeated schema definitions.

Let me show you what I mean.

What MCP tool schemas actually look like

Here's ONE tool definition from a typical MCP server:

{
  "name": "search_files",
  "description": "Search for files matching a pattern in a given directory",
  "inputSchema": {
    "type": "object",
    "properties": {
      "pattern": {
        "type": "string",
        "description": "Glob pattern to match files"
      },
      "path": {
        "type": "string",
        "description": "Root directory to search in"
      },
      "case_sensitive": {
        "type": "boolean",
        "description": "Whether to perform case-sensitive matching",
        "default": false
      }
    },
    "required": ["pattern"]
  }
}

That's 347 characters, ~87 tokens. For ONE tool.

A typical MCP server exposes 30-60 tools. Five servers = 255 tools. That's 22,185 tokens just for tool definitions.

But it gets worse. The model also gets:

Server status messages (~200 tokens each)
Tool listing headers (~50 tokens per server)
Error handling schemas (~100 tokens per tool)

Realistic total: 91K tokens for a 5-server setup.

The result wrapping problem

Every MCP tool result comes wrapped in this structure:

{
  "content": [
    {
      "type": "text",
      "text": "The actual content you care about"
    }
  ]
}

That's 47 characters of JSON overhead per result. For a 100-character result, 32% of tokens are pure overhead.

If the result is structured data:

{
  "content": [
    {
      "type": "text",
      "text": "{\"file\": \"app.py\", \"matches\": [\"line 42\", \"line 87\"]}"
    }
  ]
}

Now you have JSON inside JSON. The inner JSON is stringified. The outer JSON wraps it. Double encoding. Double parsing. Double tokens.

The cost in dollars

At Claude 3.5 Sonnet pricing ($3/M input tokens):

Scenario	Input Tokens	Cost per Conversation
Without MCP	10,000	$0.03
With 5 MCP servers	130,000	$0.39
With 10 MCP servers	250,000	$0.75
Heavy tool use (50 calls)	200,000	$0.60

A developer having 20 conversations per day with MCP:

Daily cost: $7.80 - $15.00
Monthly cost: $156 - $300
Annual cost: $1,872 - $3,600

That's not counting output tokens.

I built a tool to fix this

mcptoon — a CLI that sits between your AI agent and MCP servers. It:

Caches tool schemas — injects them once, not per conversation
Compresses results — strips JSON wrapping, returns clean text
Uses TOON format — Token-Optimized Object Notation

What TOON looks like

Instead of:

{"name": "search_files", "inputSchema": {"type": "object", "properties": {"pattern": {"type": "string"}, "path": {"type": "string"}}, "required": ["pattern"]}}

TOON outputs:

name search_files
pattern string required
path string

That's 62 tokens instead of 2,034 for all 255 tools. 97% reduction.

Real-world results

Metric	Raw MCP	With mcptoon	Savings
Tool discovery	91,247 tok	2,847 tok	97%
Per-result overhead	47 chars	0 chars	100%
20 tool calls	16,240 tok	7,080 tok	56%
1 conversation total	~120K tok	~35K tok	71%

How to use it

pip install mcptoon

Then in your Claude Code config:

{
  "mcpServers": {
    "filesystem": {
      "command": "mcptoon",
      "args": ["serve", "--stdio", "npx", "@anthropic/mcp-filesystem"]
    }
  }
}

Or if you use Cursor:

mcptoon add filesystem --stdio npx @anthropic/mcp-filesystem
mcptoon list

Zero dependencies. 250KB. Works with any agent that runs shell commands.

The bigger picture

MCP is a great protocol. The idea of standardizing tool interfaces across AI agents is important. But the implementation has a token efficiency problem that nobody talks about.

When Anthropic announced MCP, the examples showed 3-5 tools. That's manageable. But real-world setups have 50-255 tools. At that scale, the JSON overhead becomes the dominant cost.

If you're building MCP servers:

Keep tool descriptions short
Minimize schema complexity
Don't nest JSON in results
Consider token cost as a first-class concern

If you're consuming MCP tools:

Use a proxy like mcptoon to compress
Cache schemas across conversations
Limit the number of servers you connect

Show me the code

mcptoon is open source, Apache 2.0, zero dependencies:

GitHub: https://github.com/activeing123/mcptoon
PyPI: pip install mcptoon
Size: 250KB
Dependencies: 0
Tests: 486

The entire codebase is readable in an afternoon. No transitive dependencies to audit. No supply chain risk.

If this was useful, a GitHub star helps others find it. Questions? I'm in the comments.

This is an independent project. Not affiliated with Anthropic or the MCP team. All token counts are measured, not estimated.

Zero Dependencies, 250KB, 486 Tests: What I Learned Building an MCP Client

MCP Token Saver — Thu, 20 Aug 2026 02:34:23 +0000

Zero Dependencies, 250KB, 486 Tests: What I Learned Building an MCP Client

This is not a product pitch. It's an engineering diary. If you want the pitch, the README is here. This is about the cost of zero.

The setup

Six weeks ago I started building mcptoon — a CLI tool that sits between AI agents (Claude Code, Cursor, Codex) and MCP servers. The problem it solves: MCP tool schemas get injected into your context window as JSON. 255 tools = ~91K tokens of JSON braces, brackets, quotes, and commas — before any actual work happens.

mcptoon keeps schemas out of context. The agent runs shell commands. Only the compact result enters context.

But none of that is what I want to talk about.

I want to talk about the decision that shaped everything: zero dependencies.

# pyproject.toml
dependencies = []

Not "minimal dependencies." Not "few dependencies." Zero.

Why zero?

The trigger was the uv security incident. A transitive dependency in a popular Python tool had a supply chain vulnerability. Thousands of projects were affected. Not because they did anything wrong — because someone upstream did something wrong.

I looked at my own pip install history. How many packages had I installed in the last year? Hundreds. Each one pulling in its own dependency tree. How many of those dependencies had I audited? Zero.

So when I started mcptoon, I made a rule: no third-party imports. Python standard library only.

This sounded reasonable in theory. In practice, it meant I was about to hand-roll a lot of things.

The cost: What I had to build myself

No `requests` → hand-write an HTTP client

The standard library has http.client and urllib. They work. But they're verbose. Here's what a POST request looks like with urllib:

import json, urllib.request

def http_post(url, data, headers=None):
    body = json.dumps(data).encode("utf-8")
    req = urllib.request.Request(
        url, data=body,
        headers={"Content-Type": "application/json", **(headers or {})}
    )
    with urllib.request.urlopen(req, timeout=30) as resp:
        return json.loads(resp.read().decode("utf-8"))

That's 8 lines. With requests, it would be 1:

import requests
resp = requests.post(url, json=data, headers=headers, timeout=30)

Cost: ~200 lines of HTTP plumbing (streaming SSE, error handling, retry logic, auth). With requests, maybe 30 lines.

Was it worth it? For SSE (Server-Sent Events) parsing — yes, I learned how the protocol actually works. For basic HTTP — no, it was just plumbing.

No `click` or `argparse` extensions → hand-write CLI parsing

Python's stdlib argparse is... fine. But click is so much nicer. Decorators, subcommands, context, help text generation. With argparse, I ended up with a 400-line CLI dispatch function:

def main():
    parser = argparse.ArgumentParser(prog="mcptoon")
    sub = parser.add_subparsers(dest="command")

    # ... 15 subcommands, each with its own args ...

    add_cmd = sub.add_parser("add")
    add_cmd.add_argument("name")
    add_cmd.add_argument("--stdio", nargs="+")
    add_cmd.add_argument("--url")
    # ... etc for every command

Cost: ~400 lines of argument parsing. With click, maybe 150 lines.

No `pydantic` → hand-write validation

MCP servers return JSON. Without pydantic, every response is a dict and you validate by hand:

def validate_tool_result(result):
    if not isinstance(result, dict):
        raise ValueError("Expected dict")
    if "content" not in result:
        raise ValueError("Missing 'content'")
    for item in result["content"]:
        if "type" not in item:
            raise ValueError("Each content item needs 'type'")
        if item["type"] == "text" and "text" not in item:
            raise ValueError("text content missing 'text' field")

Cost: ~300 lines of validation across the codebase. With pydantic, models would self-validate.

No `rich` → hand-write terminal formatting

This one actually surprised me. I didn't need rich. ANSI escape codes work fine:

def bold(text): return f"\033[1m{text}\033[0m"
def green(text): return f"\033[32m{text}\033[0m"
def dim(text): return f"\033[2m{text}\033[0m"

Cost: ~50 lines. Not bad.

No `pytest` plugins → plain `unittest`-style tests

Actually, I do use pytest as a dev dependency (in [project.optional-dependencies]). But no pytest-mock, no pytest-cov, no responses, no httpx for mocking. Just unittest.mock:

from unittest.mock import patch, MagicMock

@patch("mcptoon.client.MCPClient._stdio_request")
def test_call_tool(mock_request):
    mock_request.return_value = {"result": {"content": [{"type": "text", "text": "hello"}]}}
    client = MCPClient(stdio=["echo", "test"])
    result = client.call_tool("search", {"q": "test"})
    assert result["content"][0]["text"] == "hello"

Cost: More verbose test setup. But 486 tests still run in 0.5 seconds because there are no heavy fixtures.

The payoff: What zero dependencies bought me

1. Install size: 250KB

$ pip install mcptoon
# Downloaded 250KB. Installed in 0.3s.

For comparison, a typical MCP client with requests, pydantic, click, rich:

requests + its deps: ~5MB
pydantic + its deps: ~15MB
click: ~200KB
rich: ~5MB
Total: ~25MB

mcptoon is 1% of that.

2. Security audit surface: zero

$ pip audit mcptoon
# No vulnerabilities found.
# (Because there's nothing to audit beyond stdlib.)

When the next supply chain attack hits npm or PyPI, mcptoon users are unaffected. Not because I was clever — because there's nothing to attack.

3. Cross-platform: actually works on Windows

Most Python CLI tools are developed on macOS/Linux and "should work on Windows." With zero dependencies, there are no platform-specific binary wheels to worry about. No uvloop that doesn't support Windows. No uvicorn worker model differences. Just sys.platform checks for .cmd vs binary names:

def _resolve_cmd(cmd):
    if sys.platform == "win32" and not cmd[0].endswith(".cmd"):
        if shutil.which(cmd[0] + ".cmd"):
            cmd = [cmd[0] + ".cmd"] + cmd[1:]
    return cmd

mcptoon works on Windows, macOS, and Linux. Not "should work" — "tested on all three."

4. Install speed

$ time pip install mcptoon
# real    0m0.3s

$ time pip install <competitor-with-20-deps>
# real    0m12.4s

When your CI runs 1000 times a day, 12 seconds per install adds up.

5. Trust

When someone reads your source and sees import json, subprocess, urllib.request, argparse — they understand it. There's no import magical_toolkit that does something opaque. The entire codebase is readable by anyone who knows Python.

This matters for adoption. Developers who care about security (and MCP users tend to) can audit your code in an afternoon. They don't need to audit 30 transitive dependencies.

When zero dependencies is NOT worth it

I'm not going to pretend zero dependencies is always the right choice. Here's when it hurts:

When you're building a web app. You need a router, a template engine, a database ORM, session management. Hand-writing all of these is insane. Use Django, FastAPI, Flask.

When the problem is already solved well. json parsing? Use stdlib. HTTP/2? Use httpx or h2 — the protocol is complex enough that a hand-rolled implementation will have bugs.

When your team is larger than one. Zero dependencies means everyone needs to understand the entire stack. With libraries, you can treat them as black boxes. That scales better with team size.

When you need to move fast. Zero dependencies means writing more code. More code means more bugs. If you're racing to market, use libraries.

For mcptoon, it was the right choice because:

It's a CLI tool, not a web app — scope is bounded
The core problem (JSON encoding/decoding, HTTP, subprocess) is well-defined
It's security-sensitive — it handles credentials and tool results
Small enough for one person to maintain
The zero-dependency story IS the marketing — it's not just engineering, it's product

The unexpected lesson: Zero dependencies made me a better programmer

This is going to sound like a motivational poster. Bear with me.

When you use requests.post(), you don't think about:

What HTTP version is being used
How redirects are followed
What happens when the connection drops mid-response
How SSL verification works

When you hand-write HTTP, you have to understand all of it.

When you use pydantic, you don't think about:

What happens when a field is None vs missing
How nested validation works
What the error messages look like for users

When you hand-write validation, you own all of it.

When you use click, you don't think about:

How subcommands are dispatched
How help text is generated
How arguments are parsed from sys.argv

When you hand-write CLI parsing, you understand your own interface.

I'm not saying you should never use libraries. I'm saying: if you've never built something with zero dependencies, you should try it at least once. The things you learn about the tools you use every day are worth the extra code.

The numbers

After six weeks of zero-dependency development:

Metric	Value
Source size	~250KB
Lines of code	~6,400
Tests	486
Test runtime	0.5s
Dependencies	0
Install time	0.3s
GitHub stars	177
PyPI versions	8 (v0.1.0 → v0.5.1)
Security vulnerabilities	0

The most surprising number is the test runtime. 486 tests in 0.5 seconds. No fixtures to load, no mocking frameworks to initialize, no database to set up. Just pure Python functions. I can run the entire test suite before my terminal even finishes rendering the prompt.

What's next

mcptoon v0.5.1 just shipped with mcptoon serve (stdio bridge mode) and mcptoon demo (zero-config one-command experience). The project is at 177 stars and growing.

The zero-dependency rule stays. It's not just an engineering decision — it's a promise to users: when you install this tool, you get exactly what you see. No hidden code. No transitive surprises. No supply chain.

If that resonates with you:

pip install mcptoon

Or read the source. It's 250KB. You can audit it in an afternoon.

This is an independent project. Not affiliated with Anthropic. Apache 2.0 licensed. If you found it useful, a GitHub star helps others find it.

5 MCP pains that waste your tokens — and how I killed all 5 with a 50KB CLI

MCP Token Saver — Mon, 17 Aug 2026 15:44:28 +0000

I've been using MCP servers with Claude Code daily. Here's what nobody tells you:

Pain 1: Context death. Add 10 MCP servers (especially browser tools like puppeteer/playwright) and you get 50,000-100,000+ tokens of {"type":"object","properties":...} before you type a single word. The MCP community itself says "MCP is unusable past 5 servers." Latent Space's analysis confirms: "The MCP protocol creates a scaling cliff around 20-30 tools."

Pain 2: Config hell. Want to add a server? Edit claude_desktop_config.json by hand. Miss a comma → broken. Wrong path → broken. Missing env var → broken. You debug for an hour.

Pain 3: Agent can't self-serve. Your agent says "I need GitHub search." It can't install tools — it's an AI. So you stop coding, edit JSON, restart, and your agent forgot what it was doing.

Pain 4: Reconfigure per agent. Set up 15 servers for Claude Code. Switch to Cursor → different format, redo everything. Then OpenCode. Then Codex. Same servers, 4× the work.

Pain 5: Paying for JSON garbage. Every MCP result: {"content":[{"type":"text","text":"{\"name\":\"react\",\"stars\":219000}"}]} — 80 tokens to deliver 6 tokens of data. Over 200 tool calls, that's 15,000 tokens of pure syntax waste.

The fix: mcptoon

I built mcptoon — a CLI that keeps all your MCP servers configured but their schemas never enter your agent's context.

How? CLI mode.

Your agent runs mcptoon commands instead of connecting to MCP servers as a client. Schemas live on disk in ~/.mcptoon/config.json. Only the compact output you request enters context.

Measured results (255 tools, 5 formats)

Tools	JSON	Standard TOON	mcptoon	SLIM	Compact
50	17,790	8,776 (-51%)	6,981 (-61%)	1,203 (-93%)	117 (-99%)
255	90,804	44,863 (-51%)	35,735 (-61%)	6,174 (-93%)	117 (-100%)

Simon Willison said it: "JSON is the least token-efficient format possible for structured data sent to an LLM." TOON fixes this.

TOON vs JSON

JSON (287 tokens):

[{"name":"search_web","description":"Search the web","inputSchema":{"type":"object","properties":{"query":{"type":"string"},"num_results":{"type":"number","default":5}},"required":["query"]}},{...}]

TOON (5 tokens):

search_web fetch_url

One config, every agent

pip install mcptoon
mcptoon init
mcptoon add fetch --stdio npx -y @modelcontextprotocol/server-fetch
mcptoon manifest --compact    # → all tool names, 117 tokens

Works with Claude Code, Cursor, Codex, OpenCode, CatPaw — any agent that runs shell commands. Zero dependencies. 50KB. Python 3.10+. Apache 2.0.

Your agent can even install its own tools: mcptoon add github --stdio npx -y @modelcontextprotocol/server-github

GitHub: https://github.com/activeing123/mcptoon

Curious — what's your MCP token overhead? My benchmark scripts are in the repo.

How I Cut MCP Token Usage by 91% (and Learned a Humbling Lesson About Tokenizers)

MCP Token Saver — Sun, 16 Aug 2026 02:35:21 +0000

The Problem

When you add MCP servers to your AI coding agent, each one dumps its full JSON schema into context. 255 tools across all servers = 39,964 tokens. On a 128K context window, that's 31% gone before you type a single character.

I was literally paying for JSON syntax overhead. Every API call included {"content":[{"type":"text","text":"..."}]} — 80 tokens to deliver 6 tokens of data.

The Solution: mcptoon

I built a CLI that sits between your agent and MCP servers. It does three things:

1. Schema Compression (SLIM format)

Instead of full JSON schemas, mcptoon presents tools in a compact pipe-delimited format:

# Full JSON (287 tokens per tool):
{"name":"search","description":"Search the web","inputSchema":{"type":"object","properties":{"q":{"type":"string","description":"Query"},"n":{"type":"number"}},"required":["q"]}}

# SLIM format (26 tokens):
search|q:s*|n:n

255 tools: 39,964 → 3,511 tokens. 91% saved. Verified with tiktoken.get_encoding("cl100k_base").

2. Zero-Context Discovery

Schemas live on disk in ~/.mcptoon/config.json. Your agent runs mcptoon manifest --slim to see what's available, then mcptoon call <server> <tool> '{"param":"value"}' --toon to execute. Only the compressed output enters context.

3. TOON Format for Results

Tool results come back as human-readable key-value pairs instead of nested JSON:

# JSON result (80 tokens):
{"content":[{"type":"text","text":"{\"name\":\"react\",\"stars\":219000}"}]}

# TOON result (12 tokens):
name: react
stars: 219000

The Lesson

My first version replaced null with ∅ (the empty set symbol). I thought I was being clever. Then someone ran it through tiktoken: null = 1 token, ∅ = 2 tokens. I was literally increasing token count and calling it optimization.

The HN community called me out on it. Fair enough — I hadn't measured before shipping. Now everything is tiktoken-verified. true stays true. null stays null. No unicode tricks.

Cost Impact

At GPT-4o pricing ($5/M tokens):

Without mcptoon: 25 requests × 40K schema tokens = 1M tokens = $5
With SLIM: 25 requests × 3.5K = 87.5K tokens = $0.44
Daily savings (100 sessions): ~$540/month

Getting Started

pip install mcptoon
mcptoon add fetch --stdio npx -y @anthropic/mcp-fetch
mcptoon manifest --slim    # see what's available, compact
mcptoon call fetch fetch '{"url":"https://example.com"}' --toon

Works with any agent that can run shell commands. One config file for all agents — no more reconfiguring for Claude Code vs Cursor vs OpenCode.

3000 lines of Python, 309 tests, zero dependencies.

GitHub: https://github.com/activeing123/mcptoon

What's Next

More MCP servers being added to the default config
Working on a rigorous quality benchmark (currently only have token counts, not LLM accuracy)
Open to feedback on the SLIM format — is there a better encoding?

What's your biggest MCP token waste? How are others handling this?