DEV Community: MCP Token Saver

Claude Code / Codex / Cursor / Hermes Agent: zero config, one shared MCP config and skill set

MCP Token Saver — Tue, 06 Oct 2026 18:23:52 +0000

One environment variable, four clients, one silent miss

Last week I added an environment variable to one of my MCP servers — API_BASE, pointed at an internal host.

Added it in Claude Code. Worked. Added it in Cursor. Worked. The Codex copy I meant to come back to, then forgot.

Three days later I was calling that same server from Codex and it wouldn't connect. I spent a while on the network before I found it: not the network. That config file simply didn't have the line.

Three configs, two correct, one stale. You never catch this at the moment it happens. You catch it weeks later, from a different client, at the worst time.

A copied config is a config that will drift

The annoying part isn't typing the same thing three times. Typing is cheap.

The annoying part is that once the same config is copied into three places, it stops being the same config. You change something in A. B and C don't move. Six months on, "the same server" has three different sets of parameters across your clients, and nothing tells you which one is right.

This has nothing to do with token savings. It's the oldest rule in configuration management: one thing, one source. Three copies means three truths, each rotting on its own schedule.

My ~/.claude.json has 12 servers I wrote by hand: 1,388 characters of JSON. And that's one client.

Collapse it to one, then fan it out

I looked around for something that would keep my server list in a single place, and the one I kept is mcptoon — a 342KB command-line program that runs on the Python standard library alone, no third-party packages.

It does one core thing: holds the server list itself, as the only copy (imported once from Claude's file). After that, whatever needs it, mcptoon pushes it out.

One sync command later it reported 6 hosts updated, 42 server entries written, 0 errors.

The six: Claude Desktop, Cursor, Cline, Windsurf, VS Code Copilot, Claude Code, all at once. Cursor and Windsurf had no config file at all — it created them. It took 7 of the 12 servers from my claude.json, which was enough to fill all six; the other 5 were experiments I'd left disabled.

Here's the part that matters: those six clients now hold six projections of one thing, not six copies that can drift.

Skills work the same way

Tools are half of it. Skills are the other half.

My machine has 427 SKILL.md files, and they add up to 1,193,709 tokens of text. That's bigger than most context windows. (I counted that with tiktoken's cl100k_base — tiktoken is my measuring tool, not part of mcptoon.)

mcptoon indexes the catalog and writes a one-line pointer into each client's instruction file. That pointer sits in your context at 39 tokens. When the agent needs a skill, it looks the skill up instead of carrying all 427.

Skills are the same shape of problem: one source, many readers. One mcptoon sync handles tools and skills together.

Off-list agents are easier, not harder

Here's where I got it wrong at first.

mcptoon auto-handles a fixed list of 12 known clients, in two groups. One group is the MCP-mounting GUI clients — the six above. The other group is Codex, Gemini CLI, opencode and the like: it doesn't touch their MCP config, it only writes a one-line skill pointer into the instruction file they read every session.

So what about Hermes Agent or OpenClaw, which fall into neither group?

There's no config file to hand-edit. mcptoon is a plain CLI, and any agent that can run a shell can be pointed at it — one line, and it sees every tool and skill.

I tested that on Hermes: one hermes mcp add call pointing mcptoon at it, and the connection came back green. The agent gains 9 gateway tools, and the dozens of upstream tools are all reached through those 9, with no per-tool setup.

So "not on the list" doesn't mean "unsupported." The list is about who gets the config written for them. The CLI path is open to any agent that can run a shell.

Limits

All numbers are measured on my Windows machine (mcptoon 0.8.14). Your machine and your version will differ.
mcptoon only auto-handles 12 known clients. If yours isn't on the list, use the CLI path. Don't expect the file to be written for you.
I did not test OpenClaw on this machine — only Hermes. Anything with a shell should work, but that one's on you to try.
The 39 tokens is the standing pointer, not "all skills in 39 tokens." The full skill text stays on disk until it's needed.
It rewrites the config files of the clients it knows. Back them up first, or use mcptoon off to pull it back out.
If you only run one client, your config can't drift. Don't optimize for its own sake.

One more thing

The tool isn't mine. I've been running it a few weeks, and the server list now lives in exactly one place.

Has a client's config ever quietly drifted out of sync on you? How did you finally notice — and what broke first?

Stop Hand-Crafting MCP JSON for Cursor and Claude Code: Sync Once, Cut 98% Discovery Tokens

MCP Token Saver — Sun, 04 Oct 2026 09:28:00 +0000

Last Friday, while cross-debugging a payment refactoring branch, I had Cursor open on my left monitor for frontend reviews and Claude Code running in my terminal on the right.

To let both AI assistants inspect database schemas and query logs, I hooked up 4 MCP servers to each environment. When you only use a couple of lightweight plugins, the overhead feels unnoticeable. But as your project deepens and you accumulate dozens of specialized MCP tools across your setup, the problem explodes.

Then I typed my first prompt: "Can you review this transfer logic?"

Before reading a single line of application code, the context window usage indicator in the bottom corner surged halfway up the gauge.

Extremely frustrating.

For months, I assumed my project context was simply too large. It was only when I inspected the raw network payloads this week that I caught the real culprit: my coding assistants were being forced to memorize an entire phonebook of tool schemas before every single exchange. When dealing with dozens of complex tool descriptions, context budgets vanish instantly.

Even worse, switching between AI clients meant manually duplicating that identical setup across fragmented JSON files scattered across hidden system directories. Miss a comma or misplace an environment variable, and the debugging session is ruined.

Here is a lightweight workflow: declare your servers once, sync them across all coding assistants with a single command, and reduce the permanent discovery context footprint by over 98%.

The Numbers First: From 71,929 Down to 581 Tokens

Before breaking down the setup, look at the benchmark data.

The standard Model Context Protocol requires clients to retrieve complete tool definitions during the initialization handshake. When you accumulate a practical toolchain—such as our benchmark suite of 255 tools—the full JSON schema gets injected into the system prompt:

Traditional Full JSON Ingestion: 255 tool schemas consume 71,929 tokens in pure protocol overhead.
Compact Name Index Mode: By passing minimal tool identifiers without breaking the agent's selection ability, consumption drops straight to 581 tokens.

That saves 71,348 tokens upfront, an overall compression ratio of 99.2%.

Before your assistant even begins reasoning, you reclaim the equivalent of a complete technical manual in available context.

A massive difference.

Root Cause: Configuration Silos and the Context Tax

If you work across both Claude Code and Cursor, you have likely run into these two bottlenecks:

1. Configuration Silos

Cursor stores its MCP configuration in either user-level global settings or workspace-level settings files.
Claude Code maintains its own dedicated directory layout, schema conventions, and configuration keys.
Changing a single database connection string forces you to manually edit multiple disjointed configuration files. It is repetitive, error-prone grunt work.

2. The Silent Context Tax

Many developers assume an MCP server only incurs token costs when actively executed.

That is incorrect.

To ensure the LLM knows which tools exist, the client must inject every tool's name, argument structure, and type descriptions at the very start of the conversation.

Even if your entire debug session only needs a single read-only SQL query, all 4 servers' full definitions are repeatedly transmitted across every subsequent turn.

Three Steps to Streamlined Tool Management

You do not need to modify your existing MCP servers. The entire transition takes 3 steps and under 10 seconds.

Step 1: Centralize Server Declarations

Instead of maintaining separate JSON snippets inside each IDE's internal configuration, consolidate all common servers into a single source of truth.

Whether running local stdio scripts or connecting to remote SSE endpoints, declare them cleanly in one place without client-specific wrapper syntax.

Step 2: Push Configurations to All Environments

Once declared, trigger the synchronization command:

The environment detector inspects your machine, identifies active installations of Cursor and Claude Code, and automatically maps the connection parameters into each client's expected configuration structure.

No manual file hunting. Your tools are aligned across environments immediately.

Step 3: Enable the Name Index Gateway

This provides the token reduction.

By introducing a lightweight gateway between the client and the underlying MCP services, only compact tool names are presented to the model during idle conversation turns. When the model selects a tool for execution, the gateway hydrates the full schema on demand.

The LLM accurately picks tools by name, without paying to re-read their full schemas across every conversational turn.

When You Should Skip This

To keep things objective, two caveats apply:

Lightweight Setups Do Not Need It: If you only connect one or two small query tools to Cursor, your permanent overhead is negligible. Stick with native configurations.
High-Density Toolchains See the Biggest Gains: The benefits of centralized synchronization and schema indexing compound when managing multiple multi-tool servers with complex parameter schemas.

Do not over-engineer if your setup is minimal.

Wrapping Up

While digging into this issue, I searched GitHub to see if anyone had tackled the problem and came across mcptoon. It currently has around two hundred stars and remains relatively under the radar.

Given how cleanly it bridges Cursor, Claude Code, and other agent environments via CLI while stripping away redundant context overhead, it deserves a closer look.

How many MCP tools do you typically connect across Cursor or Claude Code? When managing dozens of extensions, have you noticed context window degradation during prolonged debugging sessions? Let's discuss in the comments below.

Two Token Bills Before Your Agent Answers: 71,929 for MCP Tools, 1,109,242 for Skills

MCP Token Saver — Thu, 01 Oct 2026 02:44:23 +0000

Everyone's started auditing the first bill. Almost nobody has found the second one.

Here's what I mean. Open your agent's context and count what's already loaded before you type a single character. There are two line items, and they come from two different places:

MCP tool schemas. Every connected server ships the full JSON description of every tool it exposes.
Agent skills. Every SKILL.md in your skills directory, loaded whole.

I measured both with tiktoken, OpenAI's official tokenizer, using the cl100k_base encoding. The tool side is bad. The skill side is worse. And the same idea fixes both.

Bill #1: the tool schemas

Connect enough MCP servers and the tool descriptions alone eat a large slice of your context window. My reference measurement is a catalog of 255 tools. Rendered as full JSON schemas, that's 71,929 tokens.

And it isn't a one-time cost. The manifest gets re-sent every turn. Ask a dozen questions in one session and you've paid that bill a dozen times.

The reason is structural. Choosing a tool only needs its name. You don't need the full schema to decide whether to call something. But the default plumbing ships the schema anyway, up front, for every tool, on every request. So you're paying for documentation you'll mostly never open.

Bill #2: the skills, the one nobody audits

The skill side is bigger, and it's bigger because of what a skill is. A tool is a name plus a schema. A skill is an entire document: instructions, examples, a workflow, a checklist. When the catalog gets exposed as "read the SKILL.md you need," the naive implementation reads the catalog.

On this machine the skills directory holds 418 skills. Concatenated whole, every SKILL.md is 1,109,242 tokens.

That can't fit in a context window, so most setups do the thing that looks careful and isn't. They load part of it, whatever the agent guesses it needs, and pay a few thousand tokens per skill, every turn, forever. You don't notice, because the bill is spread across many small, reasonable-looking decisions.

The same fix lands on both bills

The insight is almost boring once you see it. Choosing something only needs its name.

You don't need a tool's full schema to decide whether to call it.
You don't need a skill's full text to decide whether to read it.

So expose the names first, and fetch the bodies on demand.

Tools. 255 tools as a names-only index come to 581 tokens. That's 99.2% off the original 71,929. The full schema arrives only when you actually call a tool.

Skills. One resident pointer, 39 tokens, replaces the whole catalog. A single lookup returns the handful of matching skills, and that lookup costs 501 tokens. You read the full SKILL.md files only for the winners. Same idea, other bill.

The pointer's entire job is one sentence: don't load the catalog, ask for a match, then read only those files.

I run this as mcptoon, a zero-dependency CLI. It's pure Python standard library, 227KB, and it keeps every server and every skill configured and addressable while keeping their full text out of your context window. mcptoon manifest gives you the names-only view of your tools. mcptoon skills resolve "<what you're trying to do>" returns the best-matching skills as JSON. Nothing's pre-installed, and nothing loads until you choose it.

Measure your own number first

Don't take my catalog as yours. The tax scales with how much you've wired up, and so does the fix.

Count what you actually carry. Load your real tool list and your real skills directory, run them through tiktoken, and compare the whole thing against a names-only view. If the gap is large, you've got a bill worth cutting. If the gap is small, you don't.

That measurement is the whole point. It's also the step almost everyone skips, which is why the second bill goes unnoticed for so long.

The honest boundary

This pays off when you have many tools and skills. If you run a couple of servers and a dozen skills, none of this matters much. The tax is real but small, and a gateway is one more thing to keep running. Don't optimize for the sake of optimizing.

My rule of thumb: audit first, and only reach for a name-index layer when the measurement says your context is actually crowded.

The part worth arguing about

The tool-schema side is now a known problem. Anthropic's own engineering write-up makes the case, and a Firecrawl benchmark measured the same task at 1,365 tokens through a CLI against 44,026 tokens through MCP, a 32× gap. That conversation is happening.

The skill side isn't. And it's the larger of the two, because skills are documents, not schemas.

So here's the question I'd like answered in the comments: when your agent loads a skill, how much of it is the pointer, and how much is the whole file? If you've measured that number, I'd like to see it, because I suspect most people are paying the second bill without ever seeing the invoice.

mcptoon is open source. Search for it by name. The numbers above are tiktoken cl100k_base measurements on the tool and skill catalogs described. The skill figure reflects a **418-skill directory on one machine, so treat it as a shape, not a constant. Your own mcptoon status prints your number.

DHH's Omarchy Ships 13 AI Agents on Day One. Your Context Window Picks Up the Bill.

MCP Token Saver — Thu, 10 Sep 2026 07:56:12 +0000

This week the same name showed up in my feed for the fifth time: Omarchy — DHH's opinionated Arch + Hyprland distribution. The numbers are absurd for a project that started as a dotfiles repo in mid-2025: roughly 40,000 GitHub stars (39,846 when I checked on Sept 10), an MIT license, a foundation with multi-million-dollar backing, DigitalOcean committing $1M a year, and an install that officially takes 35 seconds.

But the feature that actually matters isn't the eye candy. It's the first-boot screen.

Omarchy is the first "agentic OS" to go mainstream: on day one it asks you to pick a default AI agent — Claude Code, Codex, OpenCode, Copilot CLI, Crush, Grok, Hermes, and more. I counted the picker on the official site: 13 agents, preinstalled and wired into the system. Crash notifications get routed to your agent for diagnosis. The OS literally invites the machine to fix itself.

I think this is genuinely the future. I also think there's a bill hiding under it that nobody has priced yet.

The evening of day one

Here's how day one actually goes for the target audience. You install Omarchy in under a minute. You pick your agent. You're productive — and then, being the kind of person who installs an agentic OS, you start connecting MCP servers to it. Git ops. Containers. A database client. A web fetcher. That's the whole point, right?

And here's the mechanism almost nobody talks about: every MCP server you connect ships its entire tool catalog — names, descriptions, nested JSON Schema for every parameter — into your system prompt. Not once. Every single turn of every conversation.

Your context window starts each session paying a fixed cover charge before any real work happens.

I measured a realistic "day one" stack

To put a number on it, I built a realistic day-one developer stack — the kind a new Omarchy user would plausibly wire up in their first evening:

6 servers / 32 tools: git operations, container control, package management, system probes, editor RPC, HTTP debugging
Rendered as real MCP tool definitions and measured with tiktoken (cl100k_base), the same tokenizer family most of these agents use for billing

The receipt:

Stage	Tokens
Raw JSON manifests (what the model receives)	5,359
After schema simplification	4,655 (−13.1%)
After simplification + compact TOON-style packing	3,446 (−35.7%)

A third of the day-one tax, gone, with zero capability loss — every tool still present, just not dressed in hundreds of tokens of redundant JSON ceremony.

Now scale the habit. An agentic OS that onboards you to 13 agents is also a machine that makes adding server #7, #8, #9 frictionless. The tax is linear in tools and billed per turn. It's the only cost in AI that recurs even when you're just thinking.

Two wrong turns I took first

Before measuring, I did what everyone does: blamed the model. The answers were getting lazy and generic, so I assumed the provider had quietly downgraded something. I even switched models for a week — same fog.

Then I blamed context drift and started nuking sessions every morning, keeping summaries. That made it worse, because a fresh session still pays the full fixed fee — I'd just multiplied how many times per day I paid it.

The actual culprit was sitting in my own config: a tool manifest dressed in nested schema ceremony. Most of the weight isn't even the descriptions you can read — it's the braces, the type nesting, the repeated parameter boilerplate around every tool.

What I use now

After fixing my own config I went looking and found a small open-source project called mcptoon (200-ish stars — genuinely tiny, which is why you've probably never seen it). It runs exactly this pipeline: simplify every tool definition, then repack what's left into a denser format. That's what produced the numbers above; I measured with its real pipeline, not a hand-rolled approximation.

Honest limits: if you run one or two lightweight servers, you don't need any of this — don't optimize a bill you're not paying. The math only starts to matter around ten-plus tools, and it gets loud fast after that.

The part I keep thinking about

Omarchy is not the problem. If anything, DHH's team did the hard part: they made the agentic OS approachable. The unfinished business is that the MCP ecosystem still bills you in tokens for furniture you installed once and never look at.

An OS that ships 13 agents on day one deserves a manifest you've actually audited.

So, honest question for anyone running an agentic setup — Omarchy or otherwise: how many MCP servers does your daily-driver agent carry, and do you know what its manifest costs you per turn?

I didn't know either, until I counted.

MCP Tool Discovery Ate 3,384 Tokens per Turn. I Got It Down to 816 with mcptoon.

MCP Token Saver — Wed, 09 Sep 2026 07:59:50 +0000

MCP Tool Discovery Ate 3,384 Tokens per Turn. I Got It Down to 816 with mcptoon.

Every time your AI Agent or coding assistant (like Claude Code or Cursor) connects to your infrastructure stack, it pays a silent "entry fee" in tokens before processing a single line of your actual prompt.

I recently audited our production DevOps MCP server setup—consisting of 7 core infrastructure services (Kubernetes, Terraform, AWS, Vault, Datadog, Docker, and GitHub Actions) hosting 38 tools in total.

Here is what the raw token count looked like when measured via cl100k_base tiktoken:

Raw JSON Schema Manifest:  3,384 Tokens
Slim Schema Filter:        1,388 Tokens (-59.0%)
mcptoon TOON Manifest:       816 Tokens (-75.9%)

Where Did 3,384 Tokens Go?

Most developers assume that token consumption happens when tools return large execution outputs. But the real leak happens earlier: in the initial tool discovery phase.

When an agent initialises, the system prompt gets injected with massive JSON Schema manifests for every registered tool. Brackets, quotes, nested properties, and verbose inputSchema boilerplate eat up thousands of tokens per request turn.

How I Optimized It Using mcptoon

Instead of manually editing JSON schemas for 38 tools, I used mcptoon (an open-source, zero-dependency CLI client for managing and compressing MCP servers).

Slim Manifest (mcptoon manifest --slim): Removes redundant outer metadata, parameter type duplication, and default key definitions while keeping basic types (3,384 -> 1,388 tokens).
Compact TOON Encoding (mcptoon manifest --toon): Converts verbose JSON schemas into compact Token-Optimized Object Notation (1,388 -> 816 tokens).

# Audit and compress your MCP server manifests
mcptoon manifest --slim
mcptoon manifest --toon

If you are running multi-server setups with agents, check out mcptoon on GitHub and audit your manifest footprint before tuning your prompts!

Anthropic and MuleSoft Are Now Fighting the Same Bill I've Been Complaining About

MCP Token Saver — Tue, 08 Sep 2026 10:32:49 +0000

Two weeks ago, complaining about MCP token costs made you the annoying person
in the room. This week, Anthropic and MuleSoft both shipped features that treat
the exact same problem as a first-class cost — and each of them picked a
different third of the battlefield.

I've been living in this battlefield for two months, building mcptoon, a 128KB
zero-dependency CLI (it lives on PyPI) that compresses MCP payloads. So when
the giants started aiming at the same target, I did what any reasonable
developer does: made a map. Here it is — including the third of the
battlefield that still has nobody on it.

What just happened

Anthropic shipped two capabilities for Claude:

Advanced tool use — a tool-search tool that keeps tool definitions out of the context window until needed. Anthropic's own testing with ~58 tools showed tool-definition tokens dropping 85%, and they now have agents running 1,000+ tools.
Programmatic tool calling — instead of handing each tool result to the model as context, your agent writes code that calls tools and returns only the distilled answer. Their reported case: 37% fewer tokens in a multi-data-source analysis.

MuleSoft added MCP payload optimization to its enterprise gateway — and the
compression format it picked is TOON, the same token-oriented format
mcptoon has been speaking since the summer.

Three vendors. One diagnosis: MCP payloads are a bill, not a feature.

The map: who fights where

Battlefield	Who's on it	What they fight
Tool definitions (the catalog)	Anthropic (TST), mcptoon	The "every session re-charges the full menu" tax
Tool orchestration (how calls happen)	Anthropic (PTC)	The "every intermediate result becomes context" tax
Tool traffic in transit	MuleSoft (gateway)	Enterprise traffic, compressed behind a gateway that runs their stack
Tool results on the way back	…nobody with a 128KB wheel	The "one image tool = megabytes of base64 in context" tax

That last row is the gap. Every discussion about MCP cost is about what goes
in to the model — the catalog, the schemas, the orchestration. But agentic
sessions pump results back into context all day, and results have no
guardrails: a screenshot tool returns base64 PNG, a search tool returns the
full JSON envelope, a database tool returns 200 rows when you asked for 5.

What mcptoon does about it (and what it deliberately doesn't)

mcptoon is result-side discipline, and it's honest about the numbers:

Catalog discipline: 255 tools / 50 servers list at 71,929 → 581 tokens (−99.2%) in the default compact view — schemas stay on disk, the model sees a name index and pulls signatures on demand. (Same tax Anthropic's tool-search tool attacks, from the client side instead of the platform side.)
Result compression: TOON on tool results saves ~34% vs JSON per payload; the slim manifest format runs 88.5% smaller than raw JSON.

And one design decision I keep explaining to people: you can not compress
everything. An image generator returning base64 must never be squeezed —
compressing it either breaks it or wastes the tokens you were trying to save.
Result-side compression needs per-tool judgment. MuleSoft's per-tool override
policy validated that choice from the enterprise side.

What mcptoon doesn't do, on purpose: it doesn't live inside Claude's platform
like TST/PTC (it works with any agent that speaks MCP), and it doesn't sit in a
gateway (it's a CLI on your machine — no server, no key, no proxy process).

If you use Claude Code, it's a one-line install

Claude Code users can add mcptoon from the plugin marketplace with one line —
the plugin installs the CLI, wires the bridge into your session, and ships a
skill that teaches the agent when to compress and when to ask for the full
payload. No JSON editing — the thing my last three articles were collectively
about. The exact line is in the repo's README.

The bill, in actual money

The standard conversion: $3 per 1M input tokens. Assumptions stated (they
always should be): a working day triggers ~20 catalog loads (agentic style,
every session), 30 days a month.

255 tools, raw catalog: 71,929 tokens → ~$128.43/month
255 tools, mcptoon compact index: 581 tokens → ~$1.05/month

Your number depends on your session frequency — run the math with your own
counts before believing anyone's (including mine).

See it on your own machine

mcptoon installs with one command from PyPI — and its demo command installs a throwaway
server, calls it, and prints the before/after token numbers from your own
machine. No hand-written config, no API key, no account.

Sources: Anthropic's advanced tool use and programmatic tool calling docs
(platform.claude.com), MuleSoft's MCP payload optimization policy
(docs.mcp.mulesoft.com), and mcptoon's own measured benchmarks (tiktoken,
cl100k_base). The full battle map lives in the README.

Before I Type a Word, My Agent Burns 8,248 Tokens

MCP Token Saver — Mon, 07 Sep 2026 03:40:04 +0000

Last Tuesday night I was five messages into a refactor with Claude Code. It had just suggested a helper function, I asked it to wire up the call sites, and by then it had already forgotten the signature it wrote in message two. I opened a fresh session, repeated the prompt, everything worked. An hour later the amnesia came back in a different file.

First suspect: my own config

The project CLAUDE.md had grown into a hedge, so I cut it in half and stripped the style guide down to three lines. Then I checked the context meter of a brand new session, zero messages typed. The idle count sat at 8,248 tokens. An empty conversation burning that much points at something the client sends before I say anything.

Second suspect: the MCP servers

I run a mid-fat local stack: sqlite, git, fetch, memory, search, scheduler, translator, fsops. Eight servers, 48 tools. I disconnected them one by one and watched the idle count after each restart. Every disconnect knocked a few hundred off, and even with everything unplugged the number never went near zero. At that point I was ready to quit MCP entirely and go back to pasting code by hand.

Reading the traffic instead of guessing

I pointed a local proxy at the client and dumped the first request of that empty session. The messages array was empty, literally []. The tools array was not. Every one of those 48 tool definitions arrived wrapped in full JSON Schema: "type": "object", properties, required, plus a friendly paragraph of description for each argument. I ran tiktoken (cl100k_base) over that field alone. 8,248 tokens. Per request. Before the first character I type.

{
  "type": "object",
  "properties": {
    "repo": { "type": "string", "description": "Repository name..." },
    "path": { "type": "string", "description": "File path inside..." }
  },
  "required": ["repo"]
}

The model re-reads that catalog on every call, every turn, every session. The "forgetfulness" finally made sense: a fifth of my working window was spent holding JSON the conversation never touches.

Does a model actually need the braces?

I repacked the same 48 definitions with mcptoon's pipeline: schema simplification plus its compact pipe notation, one line per field, all 48 tools kept, nothing truncated. Same information, 4,192 tokens. 49% of the original bill, and the model still received every tool with every field name it needs to make a call. I re-ran my sessions against the compact manifest: tool choice and arguments still landed right, including the annoying nested-object ones.

measured: 8 servers / 48 tools / tiktoken cl100k_base
raw JSON manifest ....... 8,248 tokens
mcptoon (simplify+slim) . 4,192 tokens  (-49%)

One honest note about the size of the cut: how much you save depends on how bloated your schemas are. Documented, human-readable schemas like mine land around half. Flatter, machine-generated schemas compress much harder. Your number is between those poles, and the only way to know is to measure your own manifest.

The treasure at the end of the search

After fixing my setup I went to GitHub to see who else had hit this. Found mcptoon. Around two hundred stars, zero dependencies, pure stdlib Python, and it does exactly this one job: it re-serves your MCP tool manifest in a compact form any MCP client can consume. For a job this narrow, the polish is ahead of the star count.

Fair limits: if your stack is one or two servers with a dozen tools, this tax is pocket change and not worth an evening. If you run a heavier stack and your empty sessions open heavy, audit the tools field before you blame the model.

Question for the comments: what does your context meter read on an empty session, before you type anything? Drop the number. Curious what a normal idle bill looks like across setups.

The 72,000-Token Invisible Tax: What Really Happens When You Load 10 MCP Servers

MCP Token Saver — Sat, 05 Sep 2026 08:27:51 +0000

The 72,000-Token Invisible Tax: What Really Happens When You Load 10 MCP Servers

If you've been using Claude Code, Cursor, Windsurf, or Codex CLI with MCP (Model Context Protocol) servers, you might have noticed something strange lately:

Even on a brand new, empty turn — before you write a single line of code — your context window is already packed, response latency feels sluggish, and your token burn rate is higher than expected.

We measured the exact payload across 50 production MCP servers. Here is what we found, why it happens, and how modern token compression drops that overhead by 99.8%.

The Measurement: Where Did 71,929 Tokens Go?

When you connect an MCP server to an AI host, the client requests the tools schema via tools/list. The server returns JSON schemas describing each tool, parameter types, nested objects, and documentation strings.

Here is the measurement from 10 common MCP servers in a typical developer workflow:

File system toolset: ~4,200 tokens
Git / GitHub integration: ~8,800 tokens
Database / PostgreSQL introspection: ~12,400 tokens
Terminal / Shell execution: ~3,100 tokens
Web search / scraper toolsets: ~14,500 tokens
API & Slack notification wrappers: ~28,900 tokens

Total uncompressed payload injected on every conversation turn: 71,929 tokens.

If you are paying typical API pricing on top-tier frontier models (such as Claude 3.7 Sonnet at $3.00 / million input tokens), this baseline schema injection costs:

$0.21 per turn just for the tool definitions
Over 100 turns in an intensive coding session: $21.00 wasted on unchanging tool definitions

More importantly, it robs your agent of working memory.

Why JSON Schema Is the Wrong Format for LLM Context

JSON Schema was built for deterministic validation in distributed REST APIs, not for autoregressive language model attention heads.

It is notoriously verbose:

Repetitive punctuation & syntax keys: "type": "string", "properties": { ... }, "required": [...]
Deep nesting: Up to 6 levels of curly braces and indentation for simple parameters.
Type boilerplate: A simple function taking a filename and integer line number takes 40+ tokens of raw JSON.

LLMs don't need JSON validation schemas to understand how to call a tool; they understand compact functional signatures:

def execute_query(sql: str, timeout_ms: int = 5000) -> dict

The Compact Schema Solution: Dropping from 71,929 to 124 Tokens

By applying AST schema distillation and compact schema projection (an open-source approach implemented in the mcptoon tool), you don't send the raw multi-thousand-line JSON.

Instead, the client compiles the tool definitions into a compacted representation:

Strips redundant schema wrappers
Inlines type annotations
Prunes inactive parameter descriptions on initial load
On-demand hydrates full schemas only when the tool is actively selected by the model

The Results:

Uncompressed schema: 71,929 tokens
Compacted schema: 124 tokens
Token reduction: -99.8%
Latency improvement: Time-to-first-token (TTFT) dropped by 64% in our local benchmarks.

Key Lessons for Agent Builders

If you are designing agentic systems or orchestrating multiple MCP servers:

Audit your tool payload size: Run a token counter on your tools/list response. You might be surprised at how much dead weight is being transmitted.
Avoid dumping raw schemas: Use functional representations or deferred schema resolution.
Preserve context budget for actual thinking: The model does its best reasoning when the context is clean and focused on code, not schema boilerplate.

How are you handling tool payload bloat in your multi-server MCP setups? Would love to hear other strategies in the comments below.

Your MCP Tool List Costs $6.50/Month in Pure Waste — Here's the Fix

MCP Token Saver — Fri, 04 Sep 2026 07:44:09 +0000

Your MCP Tool List Costs $6.50/Month in Pure Waste — Here's the Fix

Every time you open a new session, your client re-bills you for the same tool manifest.

Full disclosure: I'm one of the maintainers of mcptoon. Every number below comes from a real benchmark (tiktoken cl100k_base), not a pitch deck.

The invisible bill that recurs every session

Anyone using Claude, Cursor, or any agent has felt it: more tools installed → conversations get pricier, slower, and fill up faster.

The problem isn't the tools. It's a line item almost nobody looks at — the tool manifest.

Every session, the client stuffs the complete manifest of every MCP server into context. In JSON, that list runs tens of thousands of tokens — and it gets re-billed every time you start a new session.

Measured on 255 tools / 50 servers:

Raw JSON manifest	Tokens	What it means
Full manifest	71,929	Recharged every session
In money	≈ $0.22/session	@ $3/M input
30 sessions/day	≈ $6.50/month	Pure manifest tax — zero tool calls

Pure waste. Your agent isn't using those 70k tokens; it just has to "read the whole name list" before it can start.

A name directory that costs 124 tokens

mcptoon slims that 70k-token JSON into a plain name directory. Same config:

Format	Tokens	Savings
Raw JSON	71,929	—
`--slim` (trimmed params)	8,282	−88.5%
`--compact` (names only)	124	−99.8%

Measured on a real 255-tool / 50-server config (tiktoken cl100k_base). Reproduce on your machine: mcptoon manifest --compact --tokens.

Verify it yourself in 30 seconds

pip install mcptoon && mcptoon demo

mcptoon demo prints the token numbers for JSON vs. mcptoon format, using your own servers, on your own box.

Why saving tokens is worth it

Long conversations stop filling up so fast. Room a 70k-token manifest used = several more rounds.
Multiple agents, one source of truth. One config (~/.mcptoon/config.json) for all clients; sync pushes to all in seconds.
Install more tools without the fear. Context bloat fears disappear once the list is slim.

Zero dependencies (pure Python stdlib, ~250KB), open source (Apache-2.0), Windows / macOS / Linux, blocks injection and credential leaks.

Asking "what tools do I have?" shouldn't cost 70,000 tokens.

Benchmark: projects/mcptoon/assets/benchmark_tiktoken.json (tiktoken cl100k_base)
GitHub: github.com/activeing123/mcptoon
Install: pip install mcptoon && mcptoon demo

I Spent an Entire Release on the First 30 Seconds

MCP Token Saver — Wed, 02 Sep 2026 07:08:01 +0000

Version 0.7.2 of mcptoon adds no new token compression. No new spec support. No new agent integrations. The whole release is about what happens in the thirty seconds after somebody types pip install mcptoon, and a contributor friend of mine thinks that is a wasted release. I think it is the highest-leverage thing I shipped all month.

Here is the reasoning. A developer tools project lives or dies on its first run. Not the docs, not the benchmark table, the first run. People paste one command, watch the output, and their brain quietly votes keep or delete. If that first run ends in a config error, the tab closes and the repo becomes another star they forgot about. My earlier quickstart was functional and completely forgettable, which in practice means the same thing as broken.

So 0.7.2 rebuilt the first run around three moments.

The install got shorter. There are now one-line installers for every common platform:

curl -fsSL https://raw.githubusercontent.com/activeing123/mcptoon/main/install.sh | bash

irm https://raw.githubusercontent.com/activeing123/mcptoon/main/install.ps1 | iex

The shell script tries pipx first, falls back to pip --user, and if the system Python is distro-managed (the PEP 668 externally-managed-environment wall) it builds a venv on its own. The Windows script finds the py launcher, fixes PATH when it can, and tells you honestly when it cannot. Both end by launching quickstart for you, so the installer is not a dead end.

The quickstart got a payoff. When setup finishes, it closes with the actual count from your machine: N tools ready across M servers, followed by exactly two commands worth running next, sync to write the configs into every agent and serve to expose everything as one stdio gateway. That is the celebration screen. If you are scripting and think party output is nonsense, --dry keeps it sober, plain next-steps only. The celebration is earned, not decorative: it only prints real numbers it just counted on your disk.

The demo got a punchline. mcptoon demo used to open with a table, which is the correct format for verification and the wrong format for a first impression. Now it leads with one plain sentence, something like: SAME data, 99 percent fewer tokens, 12,400 to 117. Then the detailed table for people who want to check the math. Then a "Now you can" checklist. The order matters. The headline number is computed live from your own servers, so it is not a marketing claim I typed, it is a measurement your machine just made.

That last point is the whole philosophy of the release, so let me be precise about it. I did not add these numbers to make the tool feel bigger. I added them so the user never has to take my word for anything. The demo runs before and after on the user's actual config, with the user's actual servers, using the same tokenizer both times. If the number is unimpressive on your setup, the tool tells you so on your screen, and you can uninstall with two minutes lost. That honesty did more for the project than any feature list.

The honest limits of the release itself: the celebration screen is cosmetic and skips cleanly with --dry, the installers assume common layouts and will not handle exotic Python setups, the PEP 668 fallback targets distro-managed Pythons specifically, and demo percentages still vary by tokenizer, expect 10 to 25 percent difference from what your provider bills. The new flows carry their own fresh test file, and everything else in the suite stays green.

Compression, spec support, agent coverage, those features got people to install. The first thirty seconds decide whether they stay. One release for thirty seconds is a trade I will make every time.

I Shipped a Plugin That Teaches Your AI Agent to Manage Its Own MCP Config

MCP Token Saver — Wed, 02 Sep 2026 04:06:00 +0000

Your agent uses tools every day, but it has no idea how the plumbing works. Ask it why your MCP setup burns 70K tokens of schemas per turn and it will guess. Ask it to wire a new server into five agent configs and it will edit the wrong file, or worse, the right file in the wrong shape.

That is a skills gap, not an intelligence gap. So with mcptoon 0.7.2 we shipped the fix as a plugin: three SKILL.md files that ride along as MCP prompts, teaching any agent how to drive mcptoon — connect, author, triage. mcptoon eats its own dog food here: the skills are installed and served through mcptoon's own plugin system.

The install is now one line

The whole onboarding used to assume you were comfortable with pip and a README walk. Version 0.7.2 collapses it:

macOS / Linux / WSL:

curl -fsSL https://raw.githubusercontent.com/activeing123/mcptoon/main/install.sh | bash

Windows (PowerShell):

irm https://raw.githubusercontent.com/activeing123/mcptoon/main/install.ps1 | iex

The script picks the best available path (pipx, then pip --user, then a PEP 668-safe venv on macOS where the system Python refuses global installs), fixes PATH if needed, and hands off straight to mcptoon quickstart. You end the one-liner staring at a list of your own MCP tools.

Quickstart now ends with the payoff

mcptoon quickstart adopts your existing setup — it scans the agents you already configured and lists every tool it finds, so nothing gets re-entered. In 0.7.2 it closes with the number that matters:

🎉 255 tools ready across 8 servers!

Now you can:
  mcptoon sync      # write configs into every agent
  mcptoon serve     # expose all servers as one stdio gateway

sync writes native-format configs into each detected agent — merging, never overwriting, so your hand-tuned entries survive. serve turns the whole pile into one stdio gateway, which is where the token compression pays off: tool listings drop by up to 99% once agents read the compressed manifest instead of the raw schemas.

The skills plugin: three files, one command

mcptoon plugin install ~/.mcptoon/plugins/mcptoon-skills

What the agent gets:

connect — how to inspect an existing setup, run quickstart/sync, and verify configs landed correctly
authoring — how to write the compressed manifest format and when compression is worth it
triage — how to debug a failing MCP server: health checks, config drift, restart semantics

They are exposed through mcptoon serve as MCP prompts, so any connected agent can pull them in on demand. No new tool calls, no extra config files — the knowledge arrives through the same channel the tools do.

Try it

# 1 · one-line install (about 250KB, pure standard library, zero dependencies)
curl -fsSL https://raw.githubusercontent.com/activeing123/mcptoon/main/install.sh | bash

# 2 · see the savings on your own setup before committing to anything
mcptoon demo

# 3 · give your agent the manual
mcptoon plugin install ~/.mcptoon/plugins/mcptoon-skills

The suite behind it runs 610 tests, green in CI. It is a local CLI, not a service — nothing leaves your machine.

Your agent was never missing intelligence. It was missing the manual. Now the manual ships with the toolbox.

Everyone Agreed What an AI Plugin Is. Nobody Said How to Install It.

MCP Token Saver — Tue, 01 Sep 2026 02:43:06 +0000

Amazon, Cursor, Microsoft, OpenAI and Vercel do not agree on much. Last week they all put their names on the same thing: the Agent Plugins Specification 1.0.0, one standard way to package a plugin for AI agents. A folder. A plugin.json at the top, a skills/ directory beside it, an mcp.json for the tools.

That part needed doing. Before this, every vendor shipped its own flavor of "plugin" and you translated between the flavors by hand.

Here is the part that gets me. The spec covers packaging only, and it says so right in its own scope. Installation? Distribution? Getting one plugin into the five agent configs you already maintain? Out of scope. The spec draws a clean box around what a plugin is, then stops at the edge of the box.

So I did the math on my own machine. Five agents, one plugin. The manual way is five config files in five different shapes, five chances to fumble a path, five restarts, and an uninstall that turns into an archaeology project across all five. The industry standardized the box, then left everyone standing in the parking lot with no truck to ship it in.

mcptoon 0.7.1 fills that gap. Same idea the CLI has always had, write every agent's native config for you, now pointed at the new plugin format.

Four commands

mcptoon plugin scan <dir>      # validate a plugin package (read-only)
mcptoon plugin install <dir>   # install into mcptoon + every synced agent
mcptoon plugin list            # what is installed
mcptoon plugin remove <name>   # remove everywhere

scan validates. install propagates. list shows what landed where. remove pulls it back out of every config it touched.

install is the one worth studying, because it makes three decisions a naive installer would get wrong.

Variables get resolved before they reach an agent. Plugin packages reference ${PLUGIN_ROOT} and ${PLUGIN_DATA}, and the spec assumes the loading agent will expand them. Most agents cannot. That is exactly why the gap exists. mcptoon is the installer, so it expands both variables into absolute paths itself and writes plain paths into every agent config. No agent ever sees a variable it cannot understand. When mcptoon launches a plugin's stdio server, it injects the same two names as environment variables, so spec-compliant plugins work both ways.

Remove reaches everywhere install reached. plugin remove does not just delete a folder. It prunes the namespaced plugin:server entries out of every agent config the install touched. One thing it keeps on purpose: the plugin's data directory under ~/.mcptoon/plugins-data/. The spec asks for persistent plugin data, so a cache survives an upgrade or a --force reinstall. Delete that folder yourself if you want a truly clean slate.

Validation fails closed. plugin scan checks the manifest against a closed schema. Unknown fields get rejected. Commands must be a single token. Remote URLs must be HTTPS unless they point at loopback. Credentials in headers get refused. Path escapes like ../ get refused. A package that fails scan never reaches an agent config.

Try it

# 1 · install (about 250KB, pure standard library, zero dependencies)
pip install mcptoon

# 2 · validate any Agent Plugins package, no side effects
mcptoon plugin scan ./my-plugin

# 3 · install it into every agent you have synced
mcptoon plugin install ./my-plugin

Because plugins land in the same config as every other MCP server, they inherit everything mcptoon already does. The compressed manifest that saves up to 99.8 percent of tool-listing tokens. mcptoon call. mcptoon health. Version 0.7.1 also picked up stdio cwd support along the way, so a plugin server can declare its own working directory.

The honest limits

This is an installer, not a marketplace. There is no registry search yet, you install from a directory you already have. The validator rejects anything the spec does not define, which is the point, but it also means creative non-standard packages bounce. Data directories persist by design. Cold starts on stdio servers still cost a few hundred milliseconds each.

The suite behind all of this is 610 tests, green in CI, plus a 19-point livefire run against real agent configs.

The vendors settled what a plugin is. Getting it onto every agent on your machine used to be your problem. Now it is one command.