An agent can lose nearly three-quarters of its context window to MCP tool definitions before it reads any of your code. Every connected MCP server loads all of its tool definitions up front, and GitHub's server alone runs to around 17.6K tokens. A ten-minute MCP audit of your daily agent setup recovers most of that space.
Why MCP tool definitions fill the context window
MCP, the Model Context Protocol, lets an agent call external tools such as a code host or a ticketing system. To make those tools usable, the agent receives a definition of every tool on every connected server: a description of what it does and a schema for its arguments. All of that text sits in the context window from the first turn, whether or not the task ever touches those tools.
The definitions are written in full because the model needs them to choose well. Servers that expose dozens of operations therefore carry a lot of text. Ned's note put GitHub's MCP server at around 17.6K tokens of definitions on its own. And a developer's daily setup rarely stops at one server, so the totals climb quickly.
In some setups we have seen nearly three-quarters of a context window consumed before any work began. The agent has read none of your code at that point, and most of its working memory is already spent.
The cost of MCP overhead is paid twice
The first cost is money. Those tokens are processed on every request, so a heavy setup raises the bill for every task, including the ones that need no external tools at all.
The second cost is accuracy. Ned's note makes the point that the more tools sit in context, the worse the model gets at picking the right one. A model shown fifty similar tool descriptions has more ways to choose badly than one shown five. And because the space left for your code and instructions shrinks as well, the agent has less to reason with.
That second cost is the harder one to see. Nothing fails visibly. The agent feels a little slower and a little less sharp, so people blame the model and switch to another one, when the cause was sitting in their own configuration.
A worked example of the context arithmetic
Take a context window of 200,000 tokens, which is a round figure chosen for illustration. A single server with 17.6K tokens of definitions takes 8.8 percent of it. Connect four servers of that size and 35.2 percent is gone before the first prompt.
Servers vary a great deal, so treat those numbers as a way to check your own setup. Some are far lighter than GitHub's and some are heavier. Still, the sum is simple enough to run on any machine: add up the definitions each connected server loads, then divide by the size of your window. If the answer surprises you, the audit below is worth doing this week.
How to run a ten-minute MCP audit
We ask our developers to do this for their daily agent setup. The steps run in this order:
- List every MCP server connected to your daily agent setup.
- For each one, check whether you used it in the last two weeks.
- Disconnect every server that fails that check.
- See whether the heavy servers can move to a plain command-line call.
Be strict at the second step. The question is whether you used the server, and "I might need it someday" counts as a fail. A disconnected server costs you a few seconds to reconnect on the day a task needs it, so the downside of being strict is small. The downside of keeping a dozen idle servers is paid on every single request.
The fourth step is where the heavy servers pay off. A command-line tool loads nothing into context until the agent actually runs it. If the agent only needs to open a pull request or read an issue now and then, a call to the GitHub command-line client does that job without the 17.6K-token standing charge.
Code Mode and the bigger fix for MCP context overhead
Tidying the list is the manual fix. A different approach is emerging that handles the problem structurally. Cloudflare's engineers, Kenton Varda and Sunil Pai, described it in their Code Mode post of 26 September 2025. Their argument is that models are better at writing code than at emitting tool calls directly, since they have seen far more real-world code than contrived tool-calling examples.
In their design, the MCP tools are converted into a TypeScript API and the agent receives a single tool that runs code against it inside an isolated sandbox. The sandbox has no general internet access, and its only outside connections are bindings to the connected MCP servers. Intermediate results stay inside the sandbox instead of passing through the model on every step, and the post notes that API keys stay with the supervising layer so the model cannot leak them.
Ned's note describes the same idea as a single meta tool that handles the choice of MCPs and tools outside the context window. We are still learning where it fits. Cloudflare's own post says the generated API is currently loaded into context in full, and suggests future versions could let agents browse it on demand. Code Mode is worth reading about, but it does not make the audit unnecessary today.
Your next step this week
Block ten minutes and run the four steps on the setup you use every day. Write down how many servers you started with and how many remain, because the difference tells you how much of your context you were giving away. Then notice whether your agent feels sharper over the following days.
The audit is one of several small habits we ask of developers working with agents. Our articles on spec drift and agentic UAT cover two others, and our open-source Atomic skills show how we package agent behaviour so it works across assistants.
A tidy MCP setup is the small end of a bigger question, which is how your teams build agents and govern them once they run. If you are working on that, let's talk: https://www.mission.plus/contact-us
