The Token-Saving MCP Trio — A Hands-On Review

Wire several MCP (Model Context Protocol) servers into an AI coding agent — Cursor, Cline, Claude Code, Codex — and it doesn't take long before your tokens bottom out and the context window throttles the session mid-task. I hit an API bill I wasn't ready for and lost a few days to it, so I went looking on GitHub for MCP servers built specifically for token savings and context compression, then set up and tested the three heavyweights myself.

Here's the review, ordered by popularity and by how much they actually helped in day-to-day work.

First, Where the Tokens Actually Leak

Before the review, it's worth pinning down the problem, because it explains why all three tools are shaped the way they are. In an MCP setup, tokens leak from three places.

One: the tool schemas themselves. The moment an MCP server connects, it hands the agent a full catalogue of its tools — names, descriptions, JSON schemas. That list is injected into the context on every request, whether the agent touches a single tool or none at all. For a tool-heavy server like GitHub MCP, a published benchmark puts 94 tools at roughly 17,600 tokens. Hook up three or four servers and you're staring at tens of thousands of tokens before anyone types anything.

Two: oversized responses. The agent reads an entire file to see one function, then greps the whole repo to "understand the structure."

Three: duplicate responses that compound. The part people miss: every tool result an agent receives gets billed again as input tokens on every subsequent turn, for the rest of the session. A 3,000-line file read once becomes a 3,000-line charge twenty turns later. That's the gap the third tool closes.

1. mcp-compressor (Atlassian Labs)

• Repo: github.com/atlassian-labs/mcp-compressor
• Target problem: wasted context from enormous tool schemas

Review

The first one I reached for is mcp-compressor, built by Atlassian. Normally, connecting a large MCP server like GitHub or Jira means the agent burns tens of thousands of tokens just reading tool names, descriptions, and nested JSON schemas before it has done a single useful thing.

Dropping it in as a proxy in front of my existing MCP servers felt like a different world. The agent sees a heavily compressed tool list up front and only receives the full schema once it decides to invoke a specific tool. It supports four compression levels from Low to Max, and if you run several MCP servers side by side, it's the first thing you should set up — a genuine must-have.

How it works — why the compression is "safe"

The key is schema-preserving compression. Despite the name, it doesn't just shred descriptions: it strips long prose, enum documentation, and nested type explanations while keeping the parameter structure the agent needs to actually call the tool. So the agent's calling behaviour doesn't change.

Setup is a one-line swap. Instead of pointing at the MCP server directly, you point at the proxy. Borrowing Atlassian's own GitHub MCP example:

{
  "mcpServers": {
    "github": {
      "command": "uvx",
      "args": ["mcp-compressor", "--server-name", "github"]
    }
  }
}

Outwardly, the proxy exposes only a couple of tools — get_tool_schema and invoke_tool by default, with list_tools added optionally at the max level. The agent asks for a tool's original schema only when it needs it. SDKs are available for Python, TypeScript, and Rust, and remote streamable HTTP backends with OAuth are supported.

Atlassian's published measurements for the four levels make the effect concrete. GitHub MCP style, 94 tools:

Worth knowing: this pattern wasn't invented for the release. Atlassian had been running it inside Rovo Dev to get MCP prompt costs under control before publishing it as open source, which is part of why I trusted it more quickly.

2. tokensave (aovestdipaperino)

• Repo: github.com/aovestdipaperino/tokensave
• Target problem: token burn from brute-force whole-file searching (grep/read)

Review

The most frustrating moment with a coding agent is watching it read several hundred-line files end to end, or grep the entire repository, all in the name of "understanding the code." tokensave changes that approach at the root.

It analyses a project folder in advance and builds a Semantic Knowledge Graph. Instead of scanning the codebase as text, the agent queries that graph and gets back only the symbols it needs, the relationships between functions, and the exact snippet — nothing else. I pointed it at my own repo and a structure-comprehension task that had cost over 140,000 tokens dropped to roughly 5,000 (about 88% saved). It runs 100% locally, so there's no latency penalty, and support for 30+ languages is reassuring.

How it works

It started life as CodeGraph, a Node.js/TypeScript project, and this is a ground-up Rust rewrite — which is why it ships as a single binary. You index a repo once, then the agent queries the graph instead of hunting files. Questions like "who calls this function" or "where is this type defined" come back with symbols, relationships, and source in a single call.

The scope is wider than it first looks: the project describes 40+ tools, 30+ languages, and 9 agent integrations. It can run as an MCP server or attach as a PreToolUse hook, so you can also configure it to nudge the agent toward graph queries before it reflexively fires off a grep.

Installation varies by platform.

# macOS
brew install aovestdipaperino/tap/tokensave

# Windows
scoop bucket add tokensave
scoop install tokensave

# Anywhere Rust exists
cargo install tokensave

Wiring it up means adding it to your existing MCP config:

{
  "mcpServers": {
    "tokensave": {
      "command": "/path/to/tokensave",
      "args": ["serve"]
    }
  }
}

The zero network calls were my favourite property. Your code never leaves the machine, so it's safe from a security standpoint, and there's no waiting on a round trip. For anyone who was uneasy about handing code intelligence to an external service, that's the deciding factor.

3. sqz-mcp (ojuschugh1/sqz)

• Repo: github.com/ojuschugh1/sqz
• Target problem: duplicate response content piling up from repeated file reads

Review

The last one I set up, sqz-mcp, has the most interesting idea behind it. It protects you from the duplicate text that appears when an agent edits code and then re-reads the same file several times to verify the change.

Any file or directory listing the agent has already read gets replaced with a 13-token hash reference (§ref:HASH§). And if the agent ever needs the exact original bytes back, it can expand it at any time — reversibility is guaranteed. You can run it as a standalone MCP server, or lay it over an existing MCP in proxy mode to fold away the noise in error logs and search results. It reined token usage in by 40–95% on repetitive debugging sessions, which finally solved the genuinely annoying problem of a session seizing up because the window was full.

How it works

The design principles are simple: deterministic, offline, and zero LLM calls. If compression required calling another model, that model's cost would show up on the bill — that can't happen here. More importantly, every compressed result is recoverable byte-for-byte. It keeps the hash instead of the text rather than lossily mangling it, which is why I trust it.

The session-level dedup cache is the core mechanism. If a content hash has already been sent once in the session, a single §ref:HASH§ line goes out instead. Published usage data reports a 24.7% average reduction across 3,003+ compressions, and up to 92% savings on repeated file reads. That said, the spread per command is wide: prose barely reaches 2%, while repeated log lines hit 58%. In other words, the savings scale with how repetitive your work is.

It exposes three tools:

Proxy mode is the impressive part. It wraps an entire existing MCP server and compresses what comes back, automatically injecting an sqz_expand tool so the agent can always recover the original. Configuration is just a sqz-mcp proxy -- prefix on the command:

{
  "mcpServers": {
    "github": {
      "command": "sqz-mcp",
      "args": ["proxy", "--", "npx", "-y", "@modelcontextprotocol/server-github"]
    }
  }
}

Install with cargo install sqz-cli sqz-mcp, npm install -g sqz-cli, or brew tap ojuschugh1/sqz && brew install sqz. Running sqz init auto-registers it with every client it detects (Claude Code, Cursor, Windsurf, Cline, Gemini CLI, Codex, Zed, Copilot CLI, and more). It's listed on the official MCP Registry as io.github.ojuschugh1/sqz.

One security detail worth calling out: safe mode detects sensitive data such as stack traces and passes it through uncompressed. That prevents accidentally mangling debugging information out of an error log.

All Three at a Glance

Setup Advice

You don't need all three. If the problem is the tool schemas themselves because you've connected too many MCP servers, go with mcp-compressor. If the project is large enough that the agent's code-exploration overhead is the bottleneck, go with tokensave. If you're stuck debugging a single problem for a long stretch and the accumulated conversation log is the burden, go with sqz-mcp.

Slightly more practical rules of thumb:

If the symptom is "the context is half full before I start" — that's the tool list. Reach for mcp-compressor. It costs nothing to try, since it's a one-line config change rather than source surgery.

If the symptom is "the agent keeps hammering Read and Grep and making no real progress" — that's exploration strategy. Reach for tokensave. Keep in mind it needs an initial index run, so large repos carry a setup cost and significant code churn means re-indexing.

If the symptom is "after thirty minutes of debugging the window is red" — reach for sqz-mcp. Even with the other two in place there's more duplicate response than you'd expect, so on long sessions I'd add it last but I would add it.

There's also a sensible order for running all three. Their problem areas barely overlap, so they don't conflict: mcp-compressor shrinks the tool listing at the front, tokensave replaces code exploration, and sqz-mcp compresses the responses flowing between them. That said, stacking all three complicates your config considerably — add them one at a time and measure, so you know which one earned its keep. mcp-compressor and sqz-mcp both work as proxies, so avoid double-wrapping the same server; assign per server instead.

Wrap-Up — Verdict and Caveats

Running all three together, the thing that stands out is that token saving has stopped being a "tip" and become infrastructure. Once you've been hit by a surprise bill, there's no reason to skip this. Today I run mcp-compressor permanently, tokensave on larger projects, and sqz-mcp on long sessions.

Three things to keep in mind, though.

First, compression ratios have to be measured on your own workload. The 97% figure assumes a 94-tool GitHub MCP server. If your connected servers only expose ten tools, the win is far smaller. Conversely, servers returning heavily structured JSON see larger sqz-mcp gains than you'd guess. All three publish measurement instructions — run your own before/after numbers when setting up.

Second, running locally matters a lot for security. All three operate without LLM calls, and tokensave and sqz-mcp are fully offline. Specifically, tokensave keeps your codebase from leaving your machine, which makes it the easiest of the three to justify on a private repo.

Third, edge cases always remain. All three leave a restore path open, but never treat a compression tool as a complete substitute for the original stream. If an agent starts answering oddly, switch compression off and rerun the same task against the raw flow. Reverse that order and you'll spend twice as long hunting the cause.

References

• atlassian-labs/mcp-compressor — docs: atlassian-labs.github.io/mcp-compressor
• MCP Compression: Preventing tool bloat in AI agents — Inside Atlassian
• aovestdipaperino/tokensave — crates.io docs: docs.rs/crate/tokensave
• Tokensave replaces expensive reads with local graph queries — Towards AI
• ojuschugh1/sqz — MCP context compression docs: mcp-context-compression.md
• sqz-mcp — docs.rs