Why Your MCP Servers Eat Your Context Window (and How to Get It Back) (Oct 2026)

Your MCP servers cost context before you type a word. Each connected server sends a description of every tool it has, and the client puts those descriptions into the model's context window. Measure what each server costs, then turn off, scope, or filter the expensive ones.

This is one of the most common complaints on MCP forums right now. One r/ClaudeAI user said new sessions start with 56% of context already used. Another person counted the tool-definition tokens of the 50 most-used servers. The median was small, around 3,900 tokens, but 14 servers were over 10,000 and three were over 50,000. On one thread about measuring this, a commenter said their always-loaded context dropped from about 200K to about 10K tokens after removing a single large server. That's one person's setup, but it shows the size of the effect.

Why tool definitions use up context

The model can only call a tool it knows about. So when a client connects to a server, it asks for the tool list, and each tool comes with:

• a name,
• a description in plain language (often several paragraphs), and
• a JSON schema for every parameter.

All of that goes into the context with every conversation, whether you use the tool or not. Twenty tools with detailed schemas can easily cost more than the code you're asking about.

The cost isn't just tokens and money. A crowded tool list also makes the model worse at picking the right tool, and it leaves less room for your actual files and conversation before the client starts compacting.

Step 1: Measure it

Don't guess which server is heavy. Look:

• Claude Code: run /context. It breaks your context down by category, including MCP tools, so you can see what each server costs. /mcp lists your connected servers.
• Other clients: most show the tool list per server. Count the tools and look at how long their descriptions are. Big tool counts and long schemas are the usual suspects.

Note your numbers before you change anything, so you can see what each fix saved.

Step 2: Cut it down

Work through these in order. The first two usually fix most of the problem.

1. Turn off servers you don't use every day

A server you used once for a migration doesn't need to load in every session. Remove it or disable it (in Claude Code, /mcp), and re-add it when you need it.

2. Configure servers per project, not globally

Put a server in the project's own config (.mcp.json for Claude Code, .vscode/mcp.json for VS Code, .cursor/mcp.json for Cursor) instead of your user config. Then the database server only loads in the repo that talks to that database. In Claude Code, claude mcp add --scope project … does this.

3. Filter tools down to the ones you use

Many servers let you pick which tools they expose:

• Supabase takes a features= list in the URL (for example features=database,docs), so you don't load account and billing tools.
• PayPal's local server takes a --tools= list. Pass only the read tools you need instead of --tools=all.

Check the server's README for flags like --tools, --toolsets, or features. One r/mcp post found that many servers give you no way to limit their tools at all. If yours is one of them, that's a reason to pick a leaner alternative.

4. Use the read-only variant

Read-only modes usually drop every create, update and delete tool:

• Linear has a separate read-only endpoint: https://mcp.linear.app/mcp/readonly.
• MongoDB takes --readOnly.
• Supabase takes read_only=true in the URL.
• Salesforce has a separate read-only server, sobject-reads.

5. Let the client load tools on demand

Some clients can defer tool definitions and load them only when the model searches for a tool. Recent Claude Code versions do this for MCP tools ("tool search"). Run /context to check whether your tools are being deferred. If your client doesn't support it, steps 1–4 are your options.

The trust angle: fewer tools, smaller attack surface

Every tool you load is also something that can go wrong:

• Tool descriptions come from the server and go straight into the model's context. A malicious or compromised update can change them to steer your agent. Fewer tools means fewer descriptions to trust.
• Write tools are where the damage happens. Turning off write tools you don't use (step 4) removes the most dangerous calls an injected instruction could make.
• Every server is software you have to keep patched. Fewer servers means fewer things to watch.

So trimming for context and trimming for security are the same job. Before you add a server back, run the 5-minute safety check, and look it up on Registry Watch for reported issues.

Frequently asked questions

How many tokens does an MCP server use?

It varies a lot. In one count of 50 popular servers, the median was about 3,900 tokens, and a few were over 50,000. Tool count alone doesn't predict it, because some servers have a few tools with very long descriptions. Measure your own setup with /context or your client's equivalent.

Is it the MCP tools or something else filling my context?

Often both. Tool definitions load all at once at the start. Project instructions (like CLAUDE.md), skills, open files and conversation history add to it. /context in Claude Code shows each category separately, so you can see which one to cut.

Will removing tools make my agent less capable?

Usually the opposite, for the work you actually do. With fewer, more relevant tools, the model picks the right one more often and has more room for your code. Keep the tools you use weekly and load the rest per project.

Which servers in the directory have read-only or filtering options?

Among the servers we grade: Linear (read-only endpoint), Supabase (read_only and features), MongoDB (--readOnly), Salesforce (read-only server) and PayPal (--tools list). See the full directory.