DEV Community: MCP Token Saver

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.

Stop Rewiring Your House Every Time You Buy a Lamp

MCP Token Saver — Mon, 31 Aug 2026 09:39:18 +0000

When you buy a new lamp, you plug it into the wall. You do not call an electrician, you do not open the walls, and you do not rewire the house. The socket was built once, and everything you own just works with it.

Now look at how most people add one MCP tool to their AI agents. Claude Desktop needs claude_desktop_config.json. Claude Code wants .claude.json. Cursor reads .cursor/mcp.json. Cline and Windsurf have their own shapes too. One new tool means four edits, four restarts, and four chances to get a path or an environment variable wrong. We rewire the house for every lamp, and we act like that is normal.

mcptoon takes the power strip approach instead. One config file, one command, and every agent on your machine shares the same set of tools. This week it got a new hero image on GitHub showing exactly that: plug your MCP tools in once, and Claude, Cursor, Codex or any agent can use them. No config, no restarts.

Three steps, any OS, no configuration

The whole onboarding now fits in three commands.

# 1 · install
pip install mcptoon

# 2 · plug in — auto-discovers tools you already configured
mcptoon quickstart

# 3 · see it work on your own machine — no trust required
mcptoon demo

pip install mcptoon pulls about 250KB of pure Python standard library. Zero dependencies, which means the supply chain you are installing is readable and small. quickstart scans the agents you already set up and lists every tool it finds, so nothing needs to be re-entered. sync then writes native config into each agent it detects, merging instead of overwriting, so your hand-tuned servers stay untouched.

Step 3 is the one I care about most. mcptoon demo runs a live comparison on your own machine: the tool list as raw JSON next to the compressed name index, with real token counts from your actual servers. No screenshots, no numbers you have to take on faith. Watch the list shrink, then decide. If it does not impress you, uninstall and you have lost two minutes.

What changed this week under the hood

Version 0.7.0 landed with full support for the newest MCP spec (2026-07-28), and the details matter for anyone running servers across flaky laptops and long sessions.

Stateless auto-negotiation means mcptoon figures out what a server speaks on first contact and adapts, including probing with server/discover for servers on the new spec while staying fully compatible with older ones. Structured tool output is parsed natively instead of dumped as text.

The interesting part is MRTR, multi round-trip. Some tools need several exchanges to finish one job. mcptoon 0.7.0 adds a --request-state flag, and the retry hint carries a state token, so a tool call that gets interrupted by a restart or a reconnect can resume where it stopped instead of starting over. If you have ever lost a ten-minute tool result because your laptop went to sleep, that is the fix.

The README now also carries an MCP Registry ownership marker (io.github.activeing123/mcptoon), so registry entries can verify who actually owns the package. Small thing, but it is the kind of provenance hygiene a healthy ecosystem needs. The test suite is at 569 and green in CI.

The honest limits

No tool is magic, and the README says so out loud.

The compact manifest is names only. It tells your agent what exists, not every parameter detail, and full JSON stays one flag away when a call needs exactness. Token counts vary by tokenizer, so expect 10 to 25 percent difference between what mcptoon reports and what your provider bills. Cold starts on stdio servers cost roughly 300ms each, which is the price of running programs instead of a persistent process. And there is no GUI. This is a command line tool for people comfortable in a terminal.

I find that honesty refreshing in a week where every other repo promises to 10x your agent. It saves 99.8 percent of the tool-listing tokens on a 50-server, 255-tool setup, and it tells you exactly where the edges of that claim are.

Try the power strip

pip install mcptoon
mcptoon quickstart
mcptoon demo

Windows, macOS, Linux. Apache 2.0, free forever. Repo with the new power strip art and full spec compatibility notes: https://github.com/activeing123/mcptoon

Stop rewiring the house. Buy the strip, plug in your tools, and let every agent you own use them.

Your AI Agent Reads a 300-Page Book Before It Answers You

MCP Token Saver — Sun, 30 Aug 2026 11:31:17 +0000

Every prompt you send starts with homework. Before Claude Code or Cursor even looks at your question, it reads the full JSON schema of every MCP tool it might call. On my machine that was 255 tools across 50 servers. I measured it with tiktoken cl100k_base: 71,929 tokens. A 300-page book, read cover to cover, every session, before your agent ever thinks about what you asked.

That same tool listing now costs me 123 tokens. A sticky note. Same tools, same capabilities, and you can reproduce the number on your own config with one command.

This is the story of mcptoon, a zero-dependency CLI, and the three problems it fixed that I never planned to touch.

Problem 1: four agents means four config files

Claude Desktop wants claude_desktop_config.json. Claude Code wants .claude.json. Cursor wants .cursor/mcp.json. Cline, Windsurf and VS Code Copilot each have their own shape too. Add a fetch server in Cursor, forget Claude. Fix a path in Claude, break Cursor. Repeat weekly.

mcptoon's answer is one file. ~/.mcptoon/config.json becomes the single source of truth, and mcptoon sync writes native config into every agent it detects. It merges instead of overwriting, so servers you configured by hand stay put. Run mcptoon sync --watch and drift detection catches external edits before they bite.

The part I like most: agents need zero setup. mcptoon is a program your agent already knows how to run. There is no mcpServers entry, no plugin API, nothing to register and nothing to restart. One line in CLAUDE.md and your agent drives every MCP server through the shell. That also means it reaches places MCP cannot: shell scripts, CI jobs, cron, aider, terminal-only boxes.

Problem 2: the token tax

Here is the mechanism behind that 300-page book. When your agent asks "what tools exist?", native MCP ships the full schemas. Every parameter, every description, every nested properties block. Multiply by 255 tools and you get 71,929 tokens sitting in your context before a single tool call.

mcptoon's manifest command answers the same question with a name index:

$ mcptoon manifest --compact
fetch: fetch(url) · github: search_repos(q), get_file(repo, path) · sqlite: query(sql)

Schemas stay on disk. They never enter the context at all. That is the difference between this and compression: compression still ships the payload and unpacks it later, so the cost just moves. Here the cost is deleted.

It's a dial, not a switch. The same 255-tool config measures 8,282 tokens with --slim (names plus parameter types, minus 88.5%) and 123 with --compact (names only, minus 99.8%). Full JSON stays available with --json whenever you want zero ambiguity. Reproduce it yourself: mcptoon manifest --compact --tokens.

Problem 3: configured is not alive

A 2026 community audit found 52% of published MCP servers unreachable. Half the servers in people's configs are dead weight, and nothing in a JSON file tells you which ones.

mcptoon health checks every server, shows latency, and exits 1 in CI when something is dead:

── mcptoon health: 3/5 alive ──────────────
  ✓ fetch     [stdio]  1 tool     120ms  ok
  ✗ brave     [stdio]  0 tools  10002ms  timeout
  ✓ github    [http]  12 tools    340ms  ok

And because MCP servers run code on your machine and return arbitrary text into your agent's context, every result passes through checks for prompt injection ("ignore previous instructions" buried in tool output), credential leaks (sk-..., AKIA..., ghp_... patterns) and dangerous operations like delete or drop unless you pass --destructive.

No telemetry. No analytics. Nothing phones home.

The objections I hear

"Isn't this just TOON compression?" No. The headline number comes from architecture: full schemas simply are not sent. Optional TOON encoding of tool results saves another 30 to 40% and it is off by default.

"Didn't Claude Code already defer tool loading?" Deferred loading decides when definitions load. mcptoon decides what a listing costs, in every agent at once, and adds sync, health and security on top. They stack fine.

"Why a CLI?" Because the shell is the one interface every agent already speaks. Zero dependencies also means the whole supply chain is about 6,800 lines of readable Python, with 569 tests staying green in CI.

Try it

pip install mcptoon
mcptoon quickstart    # finds servers you already configured
mcptoon demo          # live side-by-side: JSON vs mcptoon, real token counts

mcptoon speaks the latest MCP spec (2026-07-28) with full backward compatibility, runs on Windows, macOS and Linux, and ships under Apache 2.0. Repo: https://github.com/activeing123/mcptoon

If your agent is reading a 300-page book before it answers you, that is context you paid for and never used. Make it a sticky note.

I Replaced 72,341 Tokens of MCP Config With 123 Tokens. Here's the Exact Setup.

MCP Token Saver — Thu, 27 Aug 2026 01:59:31 +0000

I spent a weekend optimizing my MCP setup and the results were... unexpected.

The Starting Point

My Claude Code config had 255 tools registered across 10 MCP servers. Each tool came with a full JSON schema describing its inputs, outputs, constraints, and examples. Seemed reasonable until I measured the actual token cost.

72,341 tokens. Just for the schemas. Before I typed a single word.

That's roughly 40% of Claude's 200K context window gone before the conversation even starts.

The Experiment

I tried three approaches to reduce this overhead:

Approach 1: Remove descriptions

Stripped all description fields from tool schemas. Result: 72K → 58K. Saved 14K tokens but lost critical context about what each tool actually does.

Approach 2: Truncate descriptions

Cut every description to 50 characters. Result: 72K → 45K. Better, but now tools like create_issue and update_issue look identical.

Approach 3: TOON format

Compressed the entire schema structure using mcptoon's compact notation. Result: 72,341 → 123 tokens.

Wait, what?

How 123 Tokens Work

The trick is lazy loading. Instead of sending all 255 full schemas upfront, TOON format sends one-line summaries:

search_issues(query:string, repo:string, state?:string) → Issue[]
create_issue(repo:string, title:string, body:string) → Issue
update_issue(repo:string, id:int, title?:string, body?:string) → Issue

Each tool gets a single line: name, parameters with types, return type. That's enough for the model to decide which tool to use.

When it actually calls a tool, the full schema is loaded on demand. The model already knows what it wants to do — it just needs the exact parameter names and types.

The Setup

# Install
pip install mcptoon

# Compress your MCP config
mcptoon compress

# That's it. One command.

The compressed output replaces your original config. If you don't like it, mcptoon decompress gets you back to the original.

Real-World Impact

Metric	Before	After
Schema tokens	72,341	123
Context available for conversation	~128K	~200K
Tool selection accuracy	94%	93%
Time to first response	2.1s	1.4s

The 1% accuracy drop came from tools with similar names but different purposes. For most workflows, it's imperceptible.

What I Learned

Schema verbosity is the silent killer. We obsess over prompt engineering but ignore that our tool definitions are eating half the context window.
Lazy loading beats compression. You don't need all schemas all the time. Load what you need, when you need it.
The model doesn't need your examples. Those enum constraints and example values in your schemas? The model figures them out from the parameter name and type.

Try It Yourself

pip install mcptoon
mcptoon compress

GitHub: https://github.com/activeing123/mcptoon

If you're running more than 50 MCP tools, you're probably wasting tens of thousands of tokens on schemas alone. Worth a look.

This post is part of my ongoing investigation into MCP token overhead. Previous posts covered benchmarking 10 MCP servers and measuring real token costs.