This article is part of The MCP Guide, our plain-English reference on the Model Context Protocol.
Every MCP tool you connect costs space in the AI's context window, the limited working memory a model reads before it answers. Connect a few busy servers and the tool definitions alone can take tens of thousands of tokens before you type a word. That makes answers slower and more expensive, and it makes the model worse at picking the right tool.
The fix is not to avoid MCP. It is to load fewer tools at once, let the client search for tools on demand, and keep tool results short. This guide explains the problem in plain English and shows what Claude, the MCP specification and server authors already do about it. Sources were checked on 2 November 2026.
Key Takeaways
- Tool definitions (names, descriptions and input schemas) are sent to the model, so every connected tool uses context.
- Anthropic says a five-server setup with 58 tools used about 55,000 tokens before the conversation started.
- Anthropic's docs say Claude's tool choice degrades once more than 30 to 50 tools are available.
- Large tool results are a second drain: each intermediate result passes through the model unless the client avoids it.
- Tool search, now on by default in Claude Code, loads tool definitions only when a task needs them.
- The simplest fix still works: connect only the servers a job needs, and turn off tools you never use.
What "context window" means here
A context window is the amount of text a model can consider at once, measured in tokens. A token is a chunk of text, roughly a short word or part of a longer one. Everything the model sees counts: your message, the system instructions, earlier turns, files and tool definitions.
When an AI app connects to an MCP server, it asks the server for its tool list with a tools/list request. Each tool comes back with a name, a description and a JSON input schema, as the MCP tools specification describes. Most clients then put those definitions in front of the model so it knows what it can call. Our explainer on MCP tools covers the format.
One tool is cheap. Hundreds are not.
How big the problem gets
Anthropic published real numbers in its advanced tool use post from 24 November 2025. A setup with five servers had "58 tools consuming approximately 55K tokens before the conversation even starts." The same post says "At Anthropic, we've seen tool definitions consume 134K tokens before optimization."
Anthropic's tool search tool docs name two separate problems:
- Context bloat. A typical multi-server setup of GitHub, Slack, Sentry, Grafana and Splunk "can consume ~55k tokens in definitions before Claude does any work."
- Tool selection accuracy. The docs say "Claude's ability to pick the right tool degrades once you exceed 30–50 available tools."
So a bloated tool list hurts twice. You pay for the tokens on every request, and the model is more likely to call the wrong tool or a near-duplicate.
The second drain: big tool results
Tool definitions are only half of it. Results also land in the context window.
Anthropic's post on code execution with MCP (4 November 2025) says "Every intermediate result must pass through the model." Its example: copying a two-hour meeting transcript from one tool to another could add "an additional 50,000 tokens."
Clients put limits on this. The Claude Code MCP docs say Claude Code "displays a warning when any MCP tool output exceeds 10,000 tokens" and that "the default maximum is 25,000 tokens." You can change the cap with the MAX_MCP_OUTPUT_TOKENS environment variable. When a text result is over the limit, Claude Code saves it to a file and gives the model the file path instead.
Signs your setup has too many tools
You do not need to count tokens to spot the problem. Watch for these symptoms:
- The AI picks a similar but wrong tool, such as a search tool from the wrong server.
- Responses start slowly even for simple questions.
- Your client warns about tool counts or large outputs. Our fix guide for the too many tools warning covers the common messages.
- Two servers expose tools with the same name, such as
search. The spec notes that clients aggregating many servers "MAY encounter naming collisions" and "SHOULD implement a disambiguation strategy such as prefixing tool names." - Your monthly API bill grows faster than your usage.
In Claude Code, the /mcp panel shows the tool count next to each connected server, per the Claude Code docs. The /context command shows what is using the context window, including tools labeled as deferred.
What fixes it
There are four practical fixes, from simplest to most technical.
1. Connect fewer servers per job
Most people do not need every server in every chat. A marketing analyst needs analytics and a spreadsheet, not GitHub and Kubernetes. Group servers by task and turn on only the group you need. Many clients let you switch off single tools inside a server too.
Some vendors make this easy. Linear's MCP docs offer a separate read-only endpoint, https://mcp.linear.app/mcp/readonly, which "only ever exposes read tools." Fewer tools means fewer definitions and less risk. Our tool permission planner helps you decide which tools each role really needs.
2. Let the client search for tools
Tool search keeps definitions out of context until they are needed. The model sees a short list or a search tool, asks for what it needs, and only those definitions load.
Anthropic's docs say tool search "typically reduces this by over 85 percent, loading only the 3–5 tools Claude needs for a given request." In Claude Code, the docs say "Tool search is enabled by default: MCP tools are deferred and discovered on demand." Our guide to tool search and code mode explains how it works and how to configure it.
3. Keep results small
Large results are often the bigger cost in long sessions. Server authors can return summaries, support pagination, and add filters so the model asks for 20 rows instead of 20,000. Users can phrase requests narrowly: "the five newest open tickets" beats "all tickets."
4. Move data handling into code
Some agents now write short programs that call MCP tools and return only the final answer to the model. Anthropic says this approach cut one example "from 150,000 tokens to 2,000 tokens." It needs a sandbox, so it is an engineering choice, not a settings toggle.
What server authors should do
If you build MCP servers, your design choices decide how much context your users burn.
- Fewer, clearer tools. Merge near-duplicates. Write short descriptions that put the key words first. See tool naming and descriptions.
- Write server instructions. Claude Code's docs say server instructions "become more useful with tool search enabled," because they tell Claude when to search for your tools.
- Respect length limits. Claude Code cuts server instructions and upfront tool descriptions at 4,096 characters by default, and tool descriptions loaded through search at 16,384 characters.
- Return deterministic order. The spec says servers "SHOULD return tools in a deterministic order," which "improves LLM prompt cache hit rates."
- Offer read-only modes. A read-only endpoint or toolset is smaller and safer.
Next step
Start by listing which servers each team actually uses and switching off the rest. Then read how to reduce MCP token costs for a step-by-step cleanup. If you want an outside review of your setup, our MCP readiness audit covers tool sprawl, permissions and cost.
More in the MCP Guide
Latest research: State of MCP: October 2026
Frequently asked questions
How many MCP tools is too many?
There is no single number. Anthropic's docs say Claude's tool selection degrades past 30 to 50 available tools, and they recommend tool search once you have 10 or more tools or definitions over 10,000 tokens. Clients with tool search can handle far larger catalogs because only a few definitions load at a time.
Does an unused MCP server still cost tokens?
Usually yes, if the client loads its tool definitions up front. With tool search on, Claude Code loads only tool names and server instructions at session start. Check your client's docs to see which behavior applies.
Is this only a Claude problem?
No. Any AI app that sends tool definitions to a model uses context for them. The numbers in this guide come from Anthropic because it published them, but the same trade-off applies to other clients and models.
Will a bigger context window solve it?
It helps with space, but not with accuracy or cost. Every token in context is billed and read on each request, and too many similar tools still confuse the model. Loading fewer tools at once is cheaper and more reliable.
