The Engine Room · The Bill
Why Alex carries a light kit bag: 1,365 tokens versus 44,026 for the same job
Alex carries only the tools each job needs, because standing context is one of the easiest bills to waste.

The Team Talk (Alex's version)
Picture a Sunday-league coach who drags the entire equipment room to every match. Every ball, every bib, every cone, the corner flags, the winter jackets in July. The kit bag is so heavy that by the time it reaches the pitch, the warm-up is half over. A good coach packs for the game in front of them: one bag, today's kit, nothing else.
Our robot helpers had the same problem. The standard way of connecting them to tools makes each helper carry a full instruction manual for every tool it might ever touch, before it does a single minute of work. One published test measured it: a job that needs 1,365 words of instruction the light way needed 44,026 words the heavy way. Same job, thirty-two times the carrying.
So we packed lighter. Our helpers now pick up the one instruction card the task needs, use it, and put it back. The manual stays on the shelf until somebody actually needs it.
For the person on the pitch it means the tools behind SHOT waste less, cost less, and think about your session instead of their own luggage. The coaching gets the attention, not the kit bag.

The Deep Dive
The most expensive thing in an agent's context window is often work it never does. Connect a standard MCP tool server and the agent receives the full JSON schema for every tool on that server, in every message, whether it calls one of them or none. Before your request gets a single token of attention, the agent has paid to read the whole equipment room.
The numbers are not subtle. The Playwright MCP server ships 22 tools whose schemas cost roughly 15,400 tokens of standing overhead. A TypeScript class file exposing the same core capability reads at about 1,000 tokens: a 15x difference before any work happens. Scalekit's benchmark of CLI-versus-MCP task costs found the same shape from the other direction: one representative task cost 1,365 tokens via CLI and 44,026 via MCP, a 32x gap on identical work. Playwright's own team effectively conceded the point by shipping a CLI alternative; their published figures put a test at 114,000 tokens via MCP versus 27,000 via the CLI. And these servers stack. Playwright is 22 tools, GitHub's server is 51, MySQL's is 106. Wire up a handful of them and on a 200k context window you can lose 25 to 35 per cent of the model's working memory to schemas before the first line of your actual request. (All figures above from the linked essay; the Scalekit and Playwright numbers are their published benchmarks, the rest are measured directly.)
We did not need convincing, because we had already paid the bill ourselves. In our token-economics article, we found one browser-automation server costing us around 15,000 tokens per message as pure standing overhead, carried silently in every exchange of every session that had it connected. Nothing about those sessions looked wasteful from the outside. The waste was in what the agent carried, not what it did.

Why code-writing agents make the protocol redundant
MCP solves a real problem: giving a non-technical chat surface a safe, uniform way to reach external systems. The mistake is applying it to agents that write code for a living. A coding agent does not need a 700-token schema explaining how to click a button; it can read a class file, import it, and call the method. It does not need a wrapped filesystem tool; it has a shell. The interfaces that code-writing agents handle best are the ones software engineering already optimised over decades: modules, CLIs, and documentation that loads when you open it.
That gives you a replacement stack with three shelves:
- Class files and modules. Import the capability, call it. The interface costs what the code costs to read, roughly 1,000 tokens for the Playwright example above, not 15,400.
- CLIs.
gh,curl,jq,aws: tools the model already knows, invoked in tens of tokens, no schema tax at all. - On-demand skills. Packaged instructions that load into context when a task matches and stay on the shelf otherwise. The agent pays for the one card it takes down, not the whole filing cabinet.
What this looks like at SHOT
Our monorepo carries 15 packaged skills and 42 slash-commands (counted from .agents/skills/ and .claude/commands/ at time of writing). None of them cost a token until invoked. The webapp-testing skill, the RLS optimiser, the swarm-orchestration playbook, the deploy and validate commands: each one is a card the agent takes down when the task calls for it and puts back after. A standing tool-server equivalent of that catalogue would tax every message in every session, all day, for capabilities most sessions never touch.
The same discipline runs through the pipeline. When we rebuilt our agentic PR-review flow from 7 sessions per review to 4 (covered in our review-pipeline article), part of the win was exactly this: fewer contexts stood up, each carrying only what its stage needs. And the PERFORM fleet, 4,600+ worker sessions across four days for the initial build (described in our first fleet article), ran as headless CLI workers with no standing tool servers at all. Each worker got a prompt, a file contract, and a shell. At fleet scale, per-message schema overhead multiplies by every worker and every message; the cheapest schema is the one never loaded.
The industry caught up, which proves the point
Through 2026 the vendors moved. Claude Code added tool search with automatic deferral: when connected tool definitions exceed roughly 10 per cent of the context window, schemas are held back and fetched on demand rather than front-loaded. The mcporter project converts MCP servers into plain TypeScript libraries. Playwright shipped the CLI mentioned above. When the tooling that grows up around an abstraction starts shipping converters, slimmers, and escape hatches, that is not the abstraction winning, that is the market routing around its cost. Deferred loading is a genuinely good mitigation, and we use it where servers remain connected. But it is a patch on the protocol's economics, and it lands on the same conclusion this post argues from first principles: load what the task needs, when it needs it, and nothing else.

Scars and trade-offs
Honesty section. We ran standing MCP servers for months before measuring what they cost, and the 15,000-token browser server sat in our sessions the whole time; the lesson from our token-economics article stands, you cannot trim what you have not metered. The skills approach has its own bill: 57 skills and commands is 57 documents to keep truthful, and a stale skill misleads an agent more quietly than a broken tool errors out. Discoverability is real work too; an agent must know the shelf exists to take a card from it. And MCP remains the right answer where its assumptions hold: non-code-writing surfaces, hosted chat products, anywhere a user cannot audit generated code and needs the protocol's auth and isolation guarantees. Our claim is narrower and matches our receipts: for agents that write code, on our workloads, the equipment room stays at the club and the kit bag stays light.
Next in The Engine Room: 134 ways to attack Alex (we wrote them ourselves).
Read more from SHOT.