There is a number that changed how I install MCP servers. In late 2025, one developer ran a health check on his Claude Code setup and found 81,986 tokens of tool definitions loading before he typed a single word. That was 41% of a 200K context window, gone on introductions.
Now, MCP servers are genuinely exciting. Every week there is a new one — browser control, databases, design tools, email — and the temptation is to install them all and keep them handy. I did exactly that in my early setup. It felt like giving my agent superpowers.
But every server you connect can charge rent in the one currency your agent cannot earn more of: the context window. In this article, I’ll explain where the MCP context window cost comes from, what the MCP 2.0 protocol did and did not fix, how the major clients handle it today, and the habit that still saves me the most — installing MCP servers per project instead of globally.
How Does an MCP Server Load Its Tools?
Let’s start with the mechanics, because the cost only makes sense once you see how the loading works.
When your AI client starts a session, it connects to every MCP server in its configuration and asks each one a simple question: “what can you do?” The server answers with its full tool list — every tool’s name, its description, and a complete schema of every parameter it accepts. The client then decides how much of that text to put in front of the model.
Here is the part most people miss: the server always sends the whole menu. Whether the model reads the whole menu, or just the names on the cover, is entirely up to the client. For most of MCP’s short life, every client put the whole menu in the system prompt, in every session, whether you ordered anything or not.
What Is MCP Context Window Bloat?
MCP context window bloat is the token overhead created when connected MCP servers load their tool definitions into an AI agent’s context at session start, consuming working memory before the conversation begins. The cost applies to every session, including ones that never use those tools.
I have written before about why this matters beyond money in my skills vs MCP token comparison — tokens are the working memory of your agent. Every token spent on an unused tool schema is memory the agent cannot spend on your files, your instructions, and your actual task.
Did MCP 2.0 Fix This?
This is the question I get asked most now, so let me answer it directly. No, the MCP 2.0 protocol did not reduce the context cost of tool definitions. It changed how servers and clients talk to each other, not how much the model has to read.
The 2026-07-28 specification, which the 2.0 SDKs implement, made the protocol stateless. There is no more session handshake, each request carries its own identity, and servers can sit behind an ordinary load balancer. The tool list response now carries caching hints, so a client can reuse a catalogue it fetched earlier instead of asking again. Those are real improvements for people running servers at scale.
Though, look at what stayed the same. A tool listing still returns the name, description, and full input schema for every tool. The spec even recommends servers return tools in a stable order specifically because it improves prompt cache hits “when tools are included in model context” — which tells you the protocol still assumes the tools are in there. A proposal to define a lightweight discovery schema separate from the full invocation schema was raised on the specification repository in May 2026 and closed the next day without a change.
So the fix, where one exists, lives in the client. That is where the picture has actually changed.
The Numbers: What Idle Tools Actually Cost
The scale here surprised me when I first measured it, so let me put real figures on it.
A single MCP tool definition costs anywhere from a few dozen tokens for a minimal one to over 800 for a verbose one with a rich parameter schema, and most land in the few-hundred range. Anthropic’s own documentation puts 50 typical tools at 10,000 to 20,000 tokens. Individually, that is small. Connect a big server and it stops being small fast.
The full GitHub MCP server is the usual example. With all 93 tools exposed, its definitions alone have been measured at around 55,000 tokens. Connect three servers of that size and you have spent roughly 143,000 tokens of a 200K window — over 70% — before your first prompt, in a session where you might only need one tool from one of them.
Though, the waste is not even the worst part. Agents get measurably worse at picking the right tool when too many options sit in front of them. Anthropic’s documentation states that tool selection accuracy degrades once more than 30 to 50 tools are loaded at once, and older versions of Cursor warned users to stay under 40 for the same reason. A crowded toolbox does not just cost tokens; it makes your agent fumble.
How the Major Clients Handle It Today
Here is where I have to update my own advice, because the clients have moved. Some now hide the menu until the agent asks for it. Some still dump the whole thing.
| Client | What loads at session start | Project-level scope? |
|---|---|---|
| Claude Code | Tool names and server instructions only; full definitions load on demand via tool search (default) | Yes — local, project, and user scopes |
| Codex CLI | Full definitions until they pass 10% of context, then a search tool; servers can be loaded explicitly per session | Yes — project config |
| Cursor | Full definitions, trimmed by its dynamic context discovery; no true deferral | Yes — per-workspace config file |
| Claude Desktop / claude.ai connectors | Full definitions for every enabled connector | No — connectors are account-wide |
Claude Code is the most aggressive. Tool search is on by default, which means MCP tool definitions are deferred and only the tool names plus each server’s short instructions enter the context at startup. When Claude needs a capability, it searches the catalogue, pulls in up to five matching definitions, and calls them. Anthropic’s documentation is blunt about the result: there is no fixed per-server tool cap anymore, and the practical limit is your context budget.
You can tune this. Setting ENABLE_TOOL_SEARCH=auto loads everything upfront until the definitions reach 10% of the window and only then switches to deferral, and auto:5 moves that line to 5%. Setting it to false restores the old load-everything behaviour. If one server has tools Claude needs on every single turn, an alwaysLoad: true entry in its config exempts just that server from deferral.
The one I want you to notice is the last row of that table. The connectors I switch on at claude.ai show up in every Claude Code session on my machine as well, and Claude Desktop has no notion of a project folder at all. If your MCP usage lives in the desktop app, nothing is scoping anything for you.
Install MCP Servers Per Project, Not Globally
Here is the change that fixed this for me, and it is embarrassingly simple: I stopped installing MCP servers at user scope.
Claude Code has three scopes, and this is where I had the mechanics wrong for a while.
Local scope is the default — a server added without a scope flag loads only in the project where you added it and stays private to you.
Project scope stores the server in a .mcp.json file in the project folder, so it loads in that folder and is shared with anyone who clones it.
User scope, which you get with --scope user, loads in every project you open.
So the global install is not the default. It is a choice — one that people make, as I did, by running claude mcp add --scope user because it felt tidy to configure a server once. That single flag is where most Claude Code context bloat comes from.
Now I match the server to the folder that needs it. My WordPress project carries the browser-automation server, because that is where I test the site. This content workspace carries none, because writing articles needs files and skills, not live connections. Each project pays only for the tools it actually uses, and my everyday sessions start light.
The mental shift is treating MCP servers like project dependencies rather than system utilities. You would not add every library you own to every codebase. Treat tool servers the same way. If you are still setting up your environment, my guide to setting up MCP servers covers the install commands, and my getting started with Claude Code guide covers where the configuration files live.
Why Scoping Still Matters When Your Client Defers Tools
You might be thinking: if Claude Code hides the definitions anyway, why bother? I asked myself the same thing, and there are five reasons I kept the habit.
- Names and instructions still load. Every deferred tool still contributes its name, and each server’s instructions can run to 2KB, so twenty idle servers is still a page of text on every turn.
- Selection accuracy is about choice, not tokens. A wider catalogue gives the search step more near-misses to pick between, and the 30-to-50-tool degradation applies to whatever ends up loaded.
- Every search is a round trip. Anthropic’s own guidance says that for under about ten tools, loading upfront is faster, so a lean project setup often skips the search step entirely.
- Startup and approvals. Each configured server is another process to connect and, for project-scoped
.mcp.jsonentries, another approval prompt in a fresh session. - Not every client defers. The same server list in Claude Desktop, or on a proxy that disables tool search, pays the full price.
Deferred loading lowers the cost of clutter. It does not remove the reason to avoid it. Scoping servers to the projects that need them is free, works in every client today, and keeps working no matter how the protocol evolves.
How to Audit Your MCP Setup
If you already have a pile of servers installed, here is the MCP context window cleanup I would do. It takes about fifteen minutes.
Step 1: Measure what you are paying
Run /context in a fresh Claude Code session and note how many tokens MCP tools consume before any conversation. If you want to know which servers actually earn their place, /usage breaks recent consumption down per MCP server, though it only counts requests that used one of that server’s results. Other clients have their own context inspector; the number is what matters.
Step 2: List servers you used this month
Go through your installed servers honestly. Anything you have not called in the last month is a candidate for removal — you can always reinstall in minutes when a real need returns. In Claude Code, /mcp lets you toggle a server off per project without deleting its configuration, which is a good halfway house for the ones you are unsure about.
Step 3: Move project-specific servers to local or project scope
For each survivor, ask: do I need this everywhere, or in one project? Re-add the one-project servers without the --scope user flag, or put them in that project’s .mcp.json, so every other session stops paying for them.
Step 4: Reserve upfront loading for the essentials
If you have set alwaysLoad on a server, or turned tool search off, check whether you still need to. I keep upfront loading for nothing; the search round trip is cheaper than the standing cost for every server I own.
Step 5: Watch the output side too
Definitions are only half the budget. A single chatty tool result can be bigger than every schema combined, which is why Claude Code warns at 10,000 tokens of tool output and caps it at 25,000 by default. If a server keeps tripping that warning, the fix is usually a narrower query, not a bigger limit.
Step 6: Set a budget and recheck
Keep a rough budget — I aim for under 10% of the context window on tool definitions and server instructions combined — and rerun the context check whenever you add a new server. New installs are the moment bloat sneaks back in. If you want the broader token habits around this, my guide to saving AI tokens covers the rest of the session.
Conclusion
MCP servers are dependencies, not decorations. The 2.0 protocol did not make their tool definitions cheaper, the clients are doing the real work, and the cheapest fix is still the one you control: install only what the current project needs and keep the rest off until a real task calls for them.
Run your client’s context check today; if tool definitions are eating more than 10% of your window, fifteen minutes of scoping will buy your agent room to think.
FAQ about MCP Context Window
How much of the context window do MCP servers use?
MCP servers use anywhere from a few hundred tokens to over 50,000 each when their full tool definitions load upfront. The full GitHub server has been measured at around 55,000 tokens, and setups with several large servers have exceeded 80,000 tokens before the first prompt. Clients with deferred loading, such as Claude Code, cut this to the tool names and server instructions.
Do MCP tools use tokens even when I don’t call them?
Yes, MCP tools cost tokens even when never called in any client that loads definitions upfront. That still includes Claude Desktop, claude.ai connectors, and Cursor. Claude Code defers definitions by default and Codex CLI defers them past 10% of context, but even then each tool’s name and each server’s instructions still sit in the context on every turn.
Did MCP 2.0 reduce tool definition token usage?
No, MCP 2.0 did not reduce tool definition token usage. The 2026-07-28 specification made the protocol stateless, added caching hints to the tool list, and added multi-step requests, but a tool listing still returns every tool’s full schema. Any token savings come from how your client loads those definitions, not from the protocol.
How many MCP servers should I install?
Three to five actively used servers is a sensible ceiling for most setups, even with deferred loading. Keep only the servers every project genuinely needs at user scope, put project-specific ones in local or project scope, and disable anything you have not used in a month.
What is the difference between local, project, and user scope MCP servers?
Local scope MCP servers load only in the project where you added them and stay private to you, and this is Claude Code’s default. Project scope servers live in a .mcp.json file in the project folder and are shared with anyone who clones it. User scope servers load in every project on your machine, which is why they should be reserved for tools you need everywhere.
How do I check my MCP token usage in Claude Code?
The /context command in Claude Code shows a breakdown of what is consuming your context window, including MCP tools. Run it at the start of a fresh session to see your standing overhead, then run /usage to see which MCP servers your recent sessions actually drew on.
