u/Blade999666

The "MCP eats my context window" complaint is real. I measured it: 57 tools across 4 servers = 7,528 tokens before the agent does anything.

So I built slim-mcp — a proxy that sits between your agent and your MCP servers. It replaces verbose JSON Schema with TypeScript-style parameter signatures in the description. Think caveman speak for tool definitions:

Before: {"type": "string", "description": "The owner of the repository"}

After: owner:s!

Result: 7,528 tokens → 1,750. 77% reduction.

We tested accuracy with 120 API calls against Claude Sonnet — zero failures at every compression level. But that's our tools and our prompts. I want to know if it holds with yours.

Looking for:

• People running 5+ MCP servers (GitHub, Notion, Playwright, etc.) — the more tools, the better the test.

• Cursor / Cline users who don't have Claude Code's built-in Tool Search

• Anyone willing to try extreme mode and report if tool calls break

Default is standard (19% reduction, zero risk). The aggressive modes are opt-in.

--> npm install -g slim-mcp

Everything else — config, benchmarks, how it works — is in the README.

npm: npmjs.com/package/slim-mcp

GitHub: github.com/Joncik91/slim-mcp

The context window problem is an engineering problem, not a protocol flaw. MCP doesn't need to die — it needs better tooling.

I keep seeing people complain about usage limits, followed by replies like “How do you use it?” or “I can’t hit my cap even with X, Y, Z.”
I think that completely misses the point, so here’s the actual issue from my POV:

My workflow hasn’t changed in the last week or month. Same tasks, same patterns, same depth. That’s exactly why the comparison is meaningful.

If a full GSD-style flow (idea → spec → implementation) used to take ~20% of my quota for something simple for let's say a small dashboard, and now the exact same flow burns ~60%, the variable isn’t my usage. The variable is Anthropic.

There are only a few plausible explanations for a 2–3× jump:

• they were previously over‑granting usage due to a bug (OR on purpose)
• they introduced a bug that now over‑counts usage (OR something related to caching as some suspect)
• they tightened limits or are running throttling / A/B tests

None of those scenarios depend on how any of us use the model.
If the same task suddenly costs dramatically more, that’s a platform-side change, not a user-behavior change.