You install a handful of MCP servers because each one looked useful, and a week later Claude Code feels sluggish, forgets things sooner, and runs out of room on long tasks. The usual culprit isn’t the model. It’s that every connected server is spending your context window before you’ve typed a word.
This is the trade-off the “install these 20 servers” lists skip. Connected MCP servers aren’t free — they have a standing cost measured in tokens, paid up front, every session. The good news is it’s easy to see and easy to fix once you know where to look.
If you’re choosing servers in the first place, the companion piece is the best MCP servers for Claude Code in 2026, which argues the same point from the other direction: install few, on purpose.
Why connected servers cost tokens
When a session starts, Claude Code has to tell the model what tools exist. For every connected MCP server, it loads the tool definitions — each tool’s name, a description of what it does, and the schema for its parameters — into the context window. The model needs that to know what it can call.
Those definitions are text, and text is tokens. A lean server exposing two or three tools is cheap. A broad one exposing thirty tools, each with a paragraph of description and a detailed parameter schema, is not. Connect several of the broad kind and a meaningful slice of your context is gone before your first prompt — and it stays gone for the whole session.
The effect compounds on long tasks. The bigger the standing cost, the sooner you hit the edge of the window, the sooner Claude starts compacting or losing earlier context.
See the cost for yourself
Don’t guess — measure. Claude Code gives you two views.
Inside a session, run:
/contextThat shows how the context window is currently allocated — system, tools, messages — so you can see how much the tool definitions are taking. Then:
/mcplists your connected servers and the tools each one exposes. A server with a long tool list is a prime trimming candidate.
To get a real before-and-after, note your /context numbers, disable a server, restart the session, and check again. The difference is that server’s standing cost. The settings docs cover where server configuration lives.
The fixes, in order of leverage
Install fewer servers
The simplest fix and the most effective. Be honest about which servers you used this week. The rest are paying rent. Remove anything you’re not actually calling:
claude mcp remove some-unused-serverScope servers to the project that needs them
A Postgres server has no business loading in a static-site repo. Move per-project tools into a project-scoped .mcp.json at the repo root so they only load where they’re relevant, and keep user scope for the one or two servers you genuinely want everywhere.
{
"mcpServers": {
"postgres": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-postgres", "postgresql://localhost:5432/app"]
}
}
}Anything in that file loads only inside that project. Your user-scope servers stay global; everything else becomes opt-in by location. See MCP setup for Windows and WSL for how the scopes interact.
Prefer Skills for thin workflows
This is the one people miss. A lot of what gets set up as an MCP server is really just a repeatable procedure — a checklist, a formatting convention, a multi-step task you do often. That doesn’t need a live connection to an external system, and it doesn’t need to pay an upfront context cost.
Skills are loaded on demand. Claude pulls a Skill into context only when it’s relevant to what you’re doing, so a dozen Skills cost almost nothing at rest, while a dozen connected MCP servers cost you every session. If a workflow doesn’t need to reach out to GitHub or a database in real time, a Skill is usually the lighter choice. The full comparison is in Claude Code Skills vs MCP vs subagents.
The rule of thumb: MCP for live connections to external systems, Skills for procedures and knowledge. A related angle is MCP vs plugins — which to use.
Disable unused servers per project
Even servers you want sometimes don’t need to be on all the time. Remove a project-scoped server from .mcp.json when a project stops needing it, and drop user-scope servers you only use occasionally down to project scope. The goal is that any given session only loads the tools that session might actually use.
Where to put each server
| Used in every project | User scope — loads everywhere |
|---|---|
| Used in one project | Project scope (.mcp.json) — loads only there |
| Repeatable procedure, no live system | Make it a Skill instead |
| Used a few times a year | Add when needed, remove after |
A workable habit
Treat your active server list like dependencies: review it occasionally and cut what you don’t use. When you add a server, ask whether it needs to be a live connection or whether a Skill would do. When context feels tight, check /context before blaming the model.
Trim your context
- Run /context to see how the window is allocated
- Run /mcp to find servers with large tool lists
- Remove servers you didn't use this week
- Move per-project tools into .mcp.json
- Replace thin workflows with Skills
- Re-check /context after trimming to confirm the gain
Bottom line
MCP servers are powerful because they’re always available — and that’s exactly why they cost context. Every connected server loads its tool definitions up front, so a crowded setup quietly shrinks the window you have to work in. Measure it with /context and /mcp, install fewer servers, scope them to the projects that need them, and reach for Skills when you only need a procedure. The leanest setup that still does your work is the fast one.
