Field note

Context rot can start before the first prompt

My LLM session loaded 276,989 tool-schema tokens before I typed anything - eleven MCP servers, 609 tool definitions, 27.7 percent of a million-token window spent on payload the model might never call. A bigger context window did not fix that, it gave the problem more room. So I built mcp-broker, PgBouncer for MCP, and the always-loaded tool payload dropped by more than 80 percent.

May 27, 2026 · Navin Agrawal · AI systems · 3 min read

Context rot can start before the first prompt

Visual brief

Visual brief

Context rot can start before the first prompt

As of May 2026

My LLM session loaded 276,989 tool-schema tokens before I typed anything. Eleven MCP servers, 609 tool definitions, 27.7 percent of a million-token window spent on tool payload the model might never call.

A bigger context window did not fix that. It gave the problem more room. The fix was not more context, it was loading less of it until the task actually needed it.

Tool loading is context architecture. The schemas you load before the first prompt are a design decision, and most agents make it by accident.

The broker pattern, applied to MCP

So I built mcp-broker, PgBouncer for MCP. The agent sees four broker tools: search_tools, describe_tool, call_tool, and status. The upstream MCP servers still exist, but their full schemas load only when the task needs them, instead of front-loading every definition into the window before the session has a single instruction to act on. The thin stable interface sits at the front, and the brokered complexity stays behind it until something asks.

Measured on my own setup on 24 May 2026, the always-loaded tool definitions dropped from 609 to 43, a 92.94 percent cut. The serialized tool tokens fell from 276,989 to 45,281, down 83.65 percent. The tool payload share of the window went from 27.7 percent to 4.5 percent. Your numbers will differ depending on how many servers you run, and that is the point: the ratio is the lesson, not the absolute figure.

What it ships as

mcp-broker is open source under the MIT license. Version 1.1.0 is published on PyPI, Homebrew, NPM, Docker Hub, GHCR, and the MCP Registry. The release gate includes coverage and a 100 percent mutation score, because a broker that sits in front of every tool call is not a place to be loose about correctness.

Before I typed

276,989

tool-schema tokens loaded before the first prompt - 27.7 percent of a million-token window.

The payload

609 tools

eleven MCP servers and 609 tool definitions, most of which the model would never call.

After the broker

4.5%

tool payload share fell from 27.7 to 4.5 percent, with 609 always-loaded tools cut to 43.

Context rot can start before the first prompt (as of May 2026): an LLM session loaded 276,989 tool-schema tokens before anything was typed, which is 27.7 percent of a million-token window; eleven MCP servers contributed 609 tool definitions, most of which the model would never call; mcp-broker exposes four tools - search_tools, describe_tool, call_tool, and status - and loads upstream schemas on demand; and the result measured on 24 May 2026 was 609 always-loaded tools cut to 43, 276,989 tokens cut to 45,281, and tool payload share dropping from 27.7 percent to 4.5 percent of the window.
The schemas loaded before the first prompt are pure overhead until a tool is called. The broker defers them.

Was this useful?

Choose once.

Related Posts

View All Posts »
Payment APIs are having their USB-C moment with MCP

Payment APIs are having their USB-C moment with MCP

Most payment integrations still look like 2015 - custom code per platform, months-long builds. The Model Context Protocol turns MxN integrations into M+N, and payment platforms are starting to ship it. The promise is real; so are the enterprise security gaps.

Most AI agents never reach production. Payments is where that gets expensive

Most AI agents never reach production. Payments is where that gets expensive

The widely cited figure is that 88 percent of AI proofs of concept never reach production. Agentic payments inherit that gap, and the teams that cross it are not winning on model selection. They are winning on payments-specific infrastructure that makes an agent idempotent, governable, and rollback-safe at the rail boundary.

Multi-model is the new multi-rail

Multi-model is the new multi-rail

Every payment system routes across multiple rails - ACH fails, traffic moves to wire, and wire is dear for small amounts so you route to RTP. Most AI systems still call one model and hope it stays up. The LLM gateway is the same routing engine payments has run for decades, and it needs the same three things to count.

AI agents get two payment rails, card and stablecoin

AI agents get two payment rails, card and stablecoin

Visa and Coinbase are building competing payment rails for machines, not people. Coinbase's x402 puts stablecoins on HTTP's long-reserved 402 status code for sub-cent agent payments. Visa keeps the card rails and their dispute resolution. The split is real, because a 10,000-call-an-hour agent and a $4,000 flight want opposite things.