Last month, I published a comparison: MCP Servers vs. CLI. Single server (GitHub), controlled test, clear conclusion: Native MCP wastes 99.7% on schema tax in typical sessions.
But that’s a lab test. In reality, I don’t run one MCP server. I run four: GitHub, Garmin, Stitch, Intervals.icu. 2 for my develoment sections and 2 I’m using to plan and follow my health and sport coaching. And sometimes I don’t take care about the MCP servers and I’m making my requests with all of them enabled. What about you? I guess you too have configured several MCP servers and then forgot about them.
This post takes the same question into the real world: Measure actual token burn across a multi-server setup where you actually work—not a proof of concept, but production data.
Here’s the problem: every MCP server you enable injects its entire tool schema into every single request—regardless of whether you actually use it. And in the pay-per-use AI era, that invisible tax is costing you real money.
The Shift No One Warned Us About#
Remember when AI APIs had monthly packages? Those days are gone. As of early 2026, the industry has fully transitioned to token-based pay-per-use pricing.
The big players have made this crystal clear:
| Provider | Input ($/1M tokens) | Output ($/1M tokens) | Note |
|---|---|---|---|
| OpenAI GPT-5.4 | $2.50 | $15.00 | Cached: $0.25 |
| Claude Sonnet 4.6 | $3.00 | $15.00 | Long-context premium above 200K |
| Gemini 2.5 Pro | $2.00 | $12.00 | 2x above 128K tokens |
Every token counts now. And here’s what nobody talks about: every MCP server you connect is silently burning tokens on every prompt.
I Measured It Live on my Own AI Setup#
I queried my own working (personal) environment through LeanProxy (my new tool) to get real numbers. Here’s what I found:
| MCP Server | Tools Available | Tokens per Request |
|---|---|---|
| Garmin | 100 | ~10,000 |
| GitHub | 41 | ~4,100 |
| Stitch (Google) | 12 | ~1,200 |
| Intervals.icu | 10 | ~1,000 |
| Total | 163 | ~16,300 tokens |
That’s approximately $0.04-$0.08 per request just to have the tools available. Even if you only use GitHub twice in a session.
The Real Cost: 3 Working Sessions#
We simulated three realistic workflows:
Morning Sport Check (4 prompts)#
garmin_get_stats → intervals_get_events →
intervals_get_activity_intervals → intervals_add_or_update_eventThat’s 4 tool operations—but a real morning check isn’t just 4 prompts. You check stats, then ask: “Am I recovered?”, “What’s my training readiness?”, “Compare to last week?”, “Any warnings?”, “What intensity for today?”, “Check weather impact…”, “Adjust tomorrow’s plan based on this…”.
More realistically: 15 prompts × 16,300 tokens = ~244,500 tokens
Native MCP: ~244,500 tokens
With LeanProxy: ~2,000 tokens
You save: ~99%
Development Session (5 prompts)#
github_search_repositories → github_get_file_contents →
stitch_list_projects → stitch_generate_screen_from_text →
github_create_pull_requestBut wait—there’s no 5 prompts in a real development session. You open your IDE, ask for an issue, get the code. Then 10 more prompts: “fix this bug”, “add tests”, “refactor this”, “why is it failing?” Each one includes the full MCP schema. The GitHub/Stitch tools are only used twice, but you’re paying for all 163 tools on every single prompt.
A more realistic breakdown for a 15-prompt session:
Prompts 1-2: GitHub/Stitch operations (2 tool invocations)
Prompts 3-15: Coding, debugging, refactoring (0 tool invocations)
That’s 15 prompts × 16,300 tokens (full schema) = 244,500 tokens just to have tools available.
Native MCP: ~244,500 tokens
With LeanProxy: ~2,500 tokens
You save: ~99%
Full Day (7 prompts)#
garmin_get_training_readiness → intervals_get_events →
stitch_list_projects → github_get_file_contents →
stitch_generate_screen_from_text → garmin_log_food → github_push_filesBut that’s 7 tool operations across the day—not 7 prompts. A real day looks more like:
Morning (prompts 1-3): Check Garmin, plan session in Intervals, review last week
Mid-day (prompts 4-12): “Why did my HR spike?”, “What was my zone distribution?”, “Am I recovered enough?”, “Plan tomorrow’s session”, “Adjust intensity based on sleep”…
Evening (prompts 13-15): Log food, review training effect, check Intervals for next week
Dev work (prompts 16-25): Code, bugfix, refactor…
That’s 25 prompts × 16,300 tokens = ~407,500 tokens just to have your MCP tools loaded.
Native MCP: ~407,500 tokens
With LeanProxy: ~4,000 tokens
You save: ~99%
The Cache Read Illusion#
You might think: “But prompt caching! 90% discount!”
It doesn’t work that way. Cache hits still cost money—they’re not free:
Anthropic (Claude Sonnet 4.6):
| Category | Price per 1M tokens |
|---|---|
| Fresh input | $3.00 |
| Cache write (5 min) | $3.75 (1.25x) |
| Cache hit (read) | $0.30 (0.1x) |
| Output | $15.00 |
OpenAI (GPT-4o):
| Category | Price per 1M tokens |
|---|---|
| Fresh input | $2.50 |
| Cache hit | $1.25 (0.5x) |
| Output | $10.00 |
Cache hits are NOT free—they’re just discounted. And MCP tool schemas are identical every request, so 100% cache hit means:
16,300 tokens × cache cost = "effective" tokens still costing you
With Claude Sonnet: 16,300 × $0.30/M = ~$0.005/request
With GPT-4o: 16,300 × $1.25/M = ~$0.02/requestNot huge—but multiplied across sessions, it’s real money. And this assumes your cache stays valid (5 min TTL on most providers).
How This Changes Our Workflow#
Here’s the shift in thinking:
Before: “Enable all MCP servers, AI will use what it needs.”
After: “Enable MCP servers on-demand. AI will ask for what it needs.”
Having MCP ready isn’t about loading everything upfront. It’s about making the capability available through a smart gateway that only loads tool schemas when actually invoked. Or… remember to enable and disable them when not needed.
Other Proxies Exist—Why Build Another?#
There are other MCP proxy solutions, but each has trade-offs:
dynamic-mcp: Similar token optimization approach—it exposes only 2 tools initially (
get_dynamic_tools,call_dynamic_tool) and loads the rest on-demand. It’s a Rust implementation, supports OAuth, and focuses on the same goal. Not that much different from LeanProxy, but when I tested I wasn’t able to get it working properly with the MCP I had. (I might have to try again)mcp-proxy: TypeScript proxy for converting stdio to HTTP/SSE. Useful for transport bridging but has no token optimization—it passes all tool schemas through.
LiteLLM’s dynamic-mcp_route: Part of the LiteLLM proxy. Known to have SSE buffering issues, not ideal for streaming tool responses. And is quite big for only a simple MCP proxy to use locally (not intended for this local use case)
LeanProxy is purpose-built for the specific problem: minimize token overhead while supporting stdio, HTTP, and SSE transports—with a focus on CLI-first workflows.
LeanProxy: Performance Focus#
Built in Go for performance, not just Python/Node convenience:
# Startup is instant
time leanproxy-mcp server run --stdio "npx -y @modelcontextprotocol/server-filesystem ./my-project"
# Real-world: <50ms cold start
# Dry-run for token savings reports
leanproxy-mcp compactor --manifest ./mcp.json
# Centralized server management
leanproxy-mcp server listNo heavy runtime dependencies. No npm install. Just a single binary.
Real Examples#
Before: Native MCP#
$ leanproxy-mcp server list
# Shows all 4 servers configured, but with full tool schemas
# in every prompt
NAME STATUS TRANSPORT COMMAND
--------------------------------------------------------------
garmin enabled stdio uvx --python 3.12 --from git+https://github.com/Taxuspt/garmin_mcp garmin-mcp
Intervals.icu enabled stdio /opt/homebrew/bin/uv run --with mcp[cli] --with-editable /opt/intervals-mcp-server mcp run /opt/intervals-mcp-server/src/intervals_mcp_server/server.py
stitch enabled http https://stitch.googleapis.com/mcp
github enabled stdio docker run -i --rm -e GITHUB_PERSONAL_ACCESS_TOKEN ghcr.io/github/github-mcp-server
4 server(s)After: With LeanProxy#
$ leanproxy-mcp server run --stdio "npx -y @modelcontextprotocol/server-filesystem ./my-project"
# Router schema only: ~110 tokens
# First tool invocation (e.g., garmin_get_stats):
# → Schema loads JIT: ~500 tokens
# → Subsequent prompts: cachedSee Token Savings#
$ leanproxy-mcp compactor --manifest ~/.config/opencode/opencode.json
Token Report:
- Native MCP: 16,300 tokens/request
- LeanProxy: ~2,000 tokens/request
- Savings: 87%Why This Matters Now#
The AI API market in 2026 is pay-per-use. A typical developer doing 20-30 sessions/day with 4 MCP servers enabled is burning:
At 16,300 tokens/session × 30 sessions × $0.04/1K = ~$19.56/day
At 2,000 tokens/session × 30 sessions × $0.04/1K = ~$2.40/day
Monthly difference: ~$515/month just on MCP overhead.
Get LeanProxy#
Available on GitHub: https://github.com/mmornati/leanproxy-mcp
Related research: Read the earlier MCP vs CLI comparison for single-server lab data. This post extends it with real production measurements.
Install:
brew tap mmornati/leanproxy-mcp
brew install leanproxy-mcp
# Or download from releases
curl -fsSL https://github.com/mmornati/leanproxy-mcp/releases/latest/download/...What’s Next?#
Enable your MCP servers smartly. Keep the capability, lose the tax.
The future isn’t about having less. It’s about using what you need, when you need it.
