MCP tools are eating the whole context window in Claude Code. How do other teams give agents company context?
Claude Code now defers MCP tool definitions by default, so a full window usually means tool search is switched off or raw tool results are piling up. Teams fix it in three moves: run /context to see which it is, push bulky lookups into subagents or CLI tools, and replace a stack of search servers with one context server that returns a short, cited answer.
If MCP tools are filling the context window in Claude Code, find out which part of MCP is doing it before you remove anything. Current versions load only tool names at startup and fetch the full definitions when Claude needs them, so the usual causes are tool search being switched off or tool results accumulating across turns. Teams that have this under control do three things. They run /context to see where the space goes, they keep bulky lookups out of the main conversation, and they give the agent company context as one short answer rather than as raw search results. Tool search is the Claude Code feature that keeps MCP tool definitions out of the window until Claude searches for one.
Check whether it is definitions or results#
Anthropic's docs say tool search "keeps MCP context usage low by deferring tool definitions until Claude needs them. Only tool names and server instructions load at session start" (Claude Code MCP docs). It is on by default. So if /context shows MCP definitions taking a large slice at startup, something has turned tool search off. A tool result is the text an MCP tool sends back after a call, such as a list of Slack messages or a whole Confluence page. Results are the other place the space goes. This table, from the same docs page, tells the two apart:
| What fills the window | How it shows up | What to change |
|---|---|---|
| Definitions, because ENABLE_TOOL_SEARCH=false | Large MCP share in /context before you type | Unset it so tools are deferred again |
| Definitions, because of auto mode | Tools load upfront while they total under 10% of the window (Claude Code MCP docs) | Unset it, or lower the threshold with auto:5 |
| Definitions, because a server sets alwaysLoad: true | One server's tools always listed in full | Keep it for the few tools Claude needs every turn |
| Definitions, because the setup cannot defer | Foundry on Azure, an older model, or CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS | Trim servers, since tool search is off |
| Results | Startup looks lean, then the window fills mid-task | See the next two sections |
If startup looks lean and the window still fills by mid-task, the problem is results.
Why tool results fill the window#
Claude Code sends the full conversation, tool results included, with every request (Claude Code costs docs). It warns when one MCP result passes 10,000 tokens. Past 25,000 tokens by default, or past 50,000 characters of text, it saves the result to a file and gives Claude the path instead (Claude Code MCP docs). The caps prevent a single runaway result, but they do nothing about a dozen ordinary ones.
For example, an engineer asks Claude to change how the billing service handles retries. The agent searches Slack for "retry", pulls two Confluence pages, lists the related Jira tickets and reads a pull request. That is five results of several thousand tokens each. Most of it is outdated threads and documentation the agent reads once and never uses, yet each result stays in context until Claude Code compacts or clears it. Our Claude Code context window guide shows how to read the /context breakdown line by line.
More servers make this worse, because each one is another place the agent may search, and each search adds raw text to the window. Advidi ran into this after wiring up the native MCP servers for GitHub, Confluence and Jira, then replaced them with one context engine. Jorden van Breemen, CTO at Advidi, said afterwards: "It saves tokens on scanning repositories, and it saves a lot of time for the people who use it. Before, they had to scour every place context lives in our company. Now Unblocked guides them in the right direction: in development, in data, in product refinement, and in the business problems people have." (Advidi customer story)
What other teams do inside Claude Code#
Most of the fixes are in Anthropic's own cost guide (Claude Code costs docs). Use all four.
- Prefer a CLI when one exists. The guide says tools like
ghandaws"are still more context-efficient than MCP servers because they don't add any per-tool listing." - Disable servers you are not using. Run
/mcpand switch them off. The choice is saved per project. - Send research to a subagent. The guide says verbose output "stays in the subagent's context while only a summary returns to your main conversation," which keeps your own window small.
- Move long instructions into skills. Skills load when invoked, and the guide's target for CLAUDE.md is under 200 lines.
Our MCP token budget autopsy shows what common servers cost when their definitions load upfront. These steps keep the window clean. They do not change how much the agent has to read to learn how your company works. A subagent that runs six searches still runs six searches; it simply pays for them in a separate context window.
Give the agent answers, not search results#
The step that shrinks the problem itself is changing what a tool returns. The MCP specification already allows a tool to return a short text answer plus resource links that "can be subscribed to or fetched by the client" (MCP specification). The agent then fetches a full thread or doc only when it needs that source.
A context engine is a service that reads your company's sources ahead of time and answers a question with one cited result. Unblocked is one. It reads across code, PRs, issues, docs, Slack or Teams and incidents, keeps each person's permissions from the source systems (how that works), and answers through one MCP server. Its main tool, context_research, returns "a synthesized answer with citations," and a second tool fetches what a citation points to (Unblocked MCP docs). For the made-up retry question above, one call would return the current retry count, the PR that changed it and the Slack thread that explains why.
We measured this in one 2026 run, with the same prompt, model and repo. With Unblocked attached, tool calls fell from 80 to 29 and the agent used 42% fewer tokens (run of 2026-04-16, written up in same prompt, same model, different context). One run is not a benchmark. The arXiv paper shows the same principle on the definition side: sending only the most relevant tools per query, typically 3 to 5, cut tool-related token consumption by 99.6% on its 140-query benchmark (arXiv 2603.20313).
When trimming servers is enough#
Not every engineering organization needs a context engine. If you have one repository, a small wiki and a few months of Slack history, re-enabling tool search and disabling unused servers may be sufficient. The signal to change approach is when the agent needs five lookups to answer one question about your own system. Another is when it acts on an old wiki page because it never found the newer thread. If you are weighing the two setups directly, our answer on a context engine versus direct GitHub, Confluence and Slack MCPs walks through the trade.
