October 22, 2026

We Tested mcptoon. The 99 Percent Claim Is the Menu, Not the Meal.

An agent that can use a hundred tools has a reading problem. Before it does any work, it has to read the full instructions for every tool, even the ones it will never touch. mcptoon promises to fix that. We tested it on our own machine to find out what the saving really is.

What we actually did

We installed mcptoon 0.8.22 and wired it to its own 11-tool demo server. Then we called tools through it, the way an agent would: list what is available, pick one, read its instructions only when needed, and run it. We measured the tokens at each step, then removed the demo server. The gateway was never wired into any live agent.

Think of it like a cookbook. Today, the agent reads every recipe before cooking one meal. mcptoon hands it the menu first. It only reads the full recipe for the dish it actually picks.

What the numbers actually say

The full instructions for all 11 demo tools came to 5,122 tokens. The name index, the menu, came to 42 tokens. That is where the 99 percent figure comes from, and it is real. The menu is 99 percent smaller than the full cookbook.

But nobody works from the menu alone. When an agent actually works through the gateway, the default load we measured was 2,499 tokens. That is a 51.2 percent saving against the full 5,122, not 99 percent. Every time the agent picks a tool, it pays some tokens back to read that tool's full instructions. The 99 percent measures the menu. The 51 percent is the meal.

The published benchmark rows matched our run. On a fixed set of 255 tools: JSON 71,929 tokens, TOON 47,438, slim 8,282, compact 581. On a tiny JSON sample, one conversion went from 17 tokens to 13 in TOON. The shape of the data matters; savings are not uniform.

Skills compress too. Fourteen skills came to 42,127 tokens as full text, 39 tokens as a manifest, and 1,375 tokens to resolve five of them. Same idea: a short menu up front, full text only for what you pick.

What it does better than the default

Three things, clearly.

First, it makes the common case cheap. An agent that uses two tools out of a hundred stops paying to read the other ninety-eight. That is the whole win, and it is real.

Second, the on-demand fetch works. Listing, selecting, searching, and inspecting all worked in our test. Inspect pulls the full instructions for one tool when the agent needs them, and nothing else.

Third, it is reversible. The gateway can be switched off, servers restored, and the install removed. A tool that changes how an agent reads its own instructions needs a clean undo path, and this one has it.

What we did not test, and what could go wrong

Accuracy is unmeasured. Slim descriptions could cause an agent to pick the wrong tool, or fail a call, or make extra round trips to inspect. We did not test that, and it is the question that matters most. A token saving that makes an agent dumber is not a saving.

Safety is code, not proof. The router has a dangerous-operation block, credential-leak checks, and tool-poisoning checks, with a raw bypass flag. We confirmed the code exists. We did not live-test it with a real secret, and we never would. A guard that has never been tripped is a claim, not a result.

One practical gotcha: the docs use python, and our machine only has python3. The first demo run failed with a timeout before we switched. Small thing, but it is the kind of thing that eats an afternoon if you do not know it.

And the gain depends on the server. Our agent's scheduling server already compresses 550-plus operations into four unified tools. On a server that is already compressed, mcptoon's saving may be much smaller. Measure it on the real server, not the demo.

The verdict: pilot it on one real agent, accuracy first

Do not wire this into every agent. The mechanism is proven, the 51 percent saving on a demo is real, and the headline 99 percent is the menu, not the meal.

The next step is a pilot, not an adoption: run one real agent through one real task twice, once with the gateway and once without, and compare tokens, wrong tool picks, failed calls, and extra round trips. If accuracy drops, that is a fail, even if tokens drop. Accuracy beats savings.

That is how we test. A headline percentage is not proof. A measured pilot, with the part we did not test named out loud, is.

Infanodes tests tools the way we use them: on our own machine, with numbers we measured ourselves. No sponsorships, no affiliate links.