I routed 60 MCP tools through a single proxy — here's what I learned about token waste and security

Donnyb369 — Thu, 16 Apr 2026 21:05:54 +0000

I've been building MCP servers for Claude Desktop for a few months now. At one point I had five servers running: filesystem, GitHub, SQLite, a knowledge graph, and Brave Search. Sixty tools total, all piped into one LLM.

It worked. But three things kept going wrong.

The token problem

Every time Claude makes a tool call, it sends the full schema of every available tool in the context window. Sixty tools means sixty JSON schema definitions, every single request. I measured it: over 4,800 tokens of schema overhead per request, before Claude even starts thinking about your question.

That's money. At API rates, those wasted tokens add up fast across a workday of tool calls.

The security problem

I found out the hard way that my claude_desktop_config.json was passing environment variables to child processes — and a bug in how I was merging env vars meant the entire system PATH, including tokens and API keys, was getting passed through. One of my GitHub tokens ended up in a log file. Twice.

MCP servers run as child processes with whatever permissions your user account has. There's no audit trail, no rate limiting, no secret scrubbing. If a tool call returns sensitive data, it goes straight into the LLM context with no filtering.

The context rot problem

Claude would read a file, modify it three tool calls later, then reference the stale version from its context. The file had changed on disk but Claude was still working with the old content. I called this "context rot" — the LLM's view of the world drifts from reality over a long session.

So I built a proxy

MCP Spine sits between Claude Desktop and all your MCP servers. One proxy, one connection, all traffic flows through it.

Claude Desktop ◄──stdio──► MCP Spine ◄──stdio──► filesystem
                                      ◄──stdio──► GitHub
                                      ◄──stdio──► SQLite
                                      ◄──stdio──► memory
                                      ◄──stdio──► Brave Search

Here's what it does at each layer:

Security proxy — validates every JSON-RPC message, scrubs secrets from tool outputs (AWS keys, GitHub tokens, bearer tokens, private keys, connection strings), rate limits tool calls, blocks command injection and path traversal, and writes an HMAC-fingerprinted audit trail to SQLite.

Schema minifier — strips verbose descriptions, defaults, and metadata from tool schemas before they reach the LLM. The type information and required fields stay intact. Real measured savings on 12 representative tools:

Level	Savings
0 (off)	0%
1 (light)	11%
2 (default)	32%

The best individual tool (read_file) went from 586 characters down to 242 — a 59% reduction. The savings compound: with 60 tools, Level 2 saves roughly 1,500 tokens per request.

State guard — watches files on disk with SHA-256 hashes. When Claude references a file that's changed since it last read it, Spine injects a version pin into the response: "this file has changed since you last saw it." No more context rot.

Semantic router — uses local embeddings (ChromaDB + MiniLM) to figure out which tools are relevant to the current task. Instead of showing all 60 tools, it shows the 5-10 that matter. This is optional and currently experimental — the ML dependencies add startup time, so I made them lazy-loading.

What I learned building it

Environment variable handling is a minefield. The biggest bug I hit was env=self.config.env or None in the subprocess spawn. When a server config had custom env vars (like GITHUB_TOKEN), this replaced the entire process environment instead of extending it. Every server that needed a custom env var was silently missing PATH, HOME, and everything else. The fix was one line: {**os.environ, **self.config.env}. But it took hours to diagnose because the error messages were about missing executables, not missing env vars.

Windows is a different world. Python's asyncio on Windows uses a Proactor event loop that can't do connect_read_pipe / connect_write_pipe on stdio handles from piped processes. The workaround is raw binary I/O with run_in_executor for reads. I also had to handle paths with spaces and parentheses (my project lives in MCP (The Spine)), UNC paths, and the MSIX sandbox that Claude Desktop runs in.

npx is slow, node is fast. Spawning MCP servers via npx @modelcontextprotocol/server-github takes 10-15 seconds because npx checks for updates every time. Switching to node C:\path\to\node_modules\...\dist\index.js connects in under a second. This matters because MCP clients have handshake timeouts.

Thread safety in audit logging is easy to get wrong. The semantic router runs a background thread for model loading. That thread calls the audit logger, which tries to use a SQLite connection created in the main thread. SQLite doesn't allow cross-thread connection sharing. Fix: check_same_thread=False plus a threading.Lock() around all DB operations.

The numbers

Running on Windows with Python 3.14 and Claude Desktop:

6 MCP servers connected through one proxy
60 tools total, routed and minified
32% average schema token savings (up to 59% on verbose tools)
135+ tests, CI green on Windows + Linux
Sub-second server connections (with node direct path)

Try it

pip install mcp-spine

Configure your servers in a TOML file, point Claude Desktop at Spine, and all your MCP traffic gets security hardening, token savings, and an audit trail.

GitHub: github.com/Donnyb369/mcp-spine
PyPI: pypi.org/project/mcp-spine

It's open source, local-first, and works on Windows and Linux. No cloud, no accounts, no telemetry.

I'm an independent developer building open-source MCP tooling. If you're using MCP servers with Claude Desktop or any other LLM client, I'd love to hear what problems you're hitting. Drop a comment or open an issue on GitHub.

DEV Community: Donnyb369