Our five connected MCP servers eat the context window before any work starts. What do we cut?

Disconnect servers before you optimize them. Tool definitions are paid on every turn whether the agent calls them or not, so removing the servers nobody actually uses is usually the largest single saving available, and it is a config edit rather than a redesign. Once the list is down to what the work needs, the remaining levers are gating tools per session, deferring schema loads until a tool is selected, and moving occasional capabilities out of the tool list entirely.

Why this happens

The cost is structural rather than a misconfiguration. Every tool a server exposes ships a name, a description, and a JSON schema, and the host loads all of them into the model’s system prompt on every turn, whether or not the model calls anything. One tool definition runs roughly 200 to 500 tokens. A server with twenty to thirty tools is therefore 5,000 to 15,000 tokens of standing overhead, and four or five connected servers can put the baseline somewhere in the 30,000 to 60,000 range before anyone types a prompt. Simon Willison measured GitHub’s official server alone at tens of thousands of tokens.

Two things make it worse than the raw number looks. It is paid per turn, so a long session multiplies it against every request. Prompt caching takes the dollar cost off the repeat turns, but the tokens still occupy the window. And it competes for the same space as the task, so retrieved documents and history get squeezed by capabilities the model may never invoke. Tool output piling up on top of the header is context bloat, and pruning history is the usual response. The header underneath is a floor that pruning does not move.

How many tokens do connected MCP servers actually cost?

Measure it, because the spread between the worst case and the practical floor is close to an order of magnitude. The protocol baseline is the sum of every mounted tool’s schema on every turn. What you pay depends on what your client does above that: some defer schemas until a tool search selects one, some let you enable and disable individual tools per session, and the protocol carries a tools/list_changed notification so a server can swap its visible surface in and out.

So two teams running the same five servers can sit anywhere between a 40,000 token standing header and close to zero for the servers they are not using this session. Get your own number before you redesign anything: most clients report token usage per request. Which server dominates is rarely the one that was about to get rewritten.

Are agent skills cheaper than MCP for the same capability?

For capabilities used occasionally, yes, by a wide margin. A skill’s base entry is a name and a one-line description, which Simon Willison put at a few dozen tokens, and the full instructions load only when the model decides the skill is relevant. A hundred installed skills cost roughly nothing for the ninety-nine you do not use this turn. A hundred mounted tools cost full schema price for all hundred, every turn.

The advantage narrows in two places. For a capability used on most turns, the repeated cost of loading the skill body competes with a schema the client could have cached, and the gap closes. Skills also trade a schema cost for a discovery cost: the model chooses from short descriptions alone, so a long tail of similar-sounding skills becomes its own failure mode, which a flat list of full schemas does not have. Skills are the right default for the occasional path rather than a replacement for the protocol.

Your options

Ordered by what they cost you to try: the first two are configuration changes available this afternoon, the rest change how capabilities reach the agent at all.

Connecting fewer servers is the move nobody wants to write down and the one that usually wins. Most stacks carry servers from an evaluation that ended months ago that the agent has never called. Removing one twenty-tool server is a config edit that takes 5,000 to 15,000 tokens off every turn permanently. It stops being the answer once every remaining server is genuinely in use.

Per-session gating and deferred loading keeps the servers and hides their schemas until something needs them. Most current clients ship a version of this: a tool search that defers definitions until one is selected, or a per-session toggle. It relocates the problem rather than removing it: the agent now has to find a tool before using it, which is why agents skip servers you have already installed, and the mechanism is progressive tool loading.

Agent skills invert the default. Instead of full schema price upfront and nothing later, you pay a few dozen tokens per skill upfront and load the body when it fires. That is the right shape for anything used on a minority of turns, and the wrong shape for a capability the agent reaches for constantly.

A CLI the agent shells out to removes the schema entirely for tools the model already knows. For mature binaries like gh, kubectl, and jq, the model arrives knowing the flag conventions and the baseline is close to zero. It needs a persistent sandboxed shell with the binary installed, a niche CLI defers its cost to a chain of --help calls, and the agent inherits whatever credentials that shell has.

A container with a fixed tool surface attacks one version of the problem: a tool list growing because the knowledge behind it is growing, not because the capabilities are. The surface stays at five tools whether ten entries sit behind it or ten thousand, so per-turn cost tracks how many you connect rather than how much is inside them. It is still a server on your list, and if your problem is five servers, this is the sixth unless it replaces some.

How to decide

Which servers has the agent actually called this month? Count invocations per server, not per tool. Anything at zero is free to remove. That often resolves the problem outright, and stops you optimizing a server you were about to delete.

Does your client gate tools, or load everything? If it defers schemas or exposes per-session toggles, the two cheap options are real and you should exhaust them before changing architecture. If it loads everything upfront, the decision moves straight to which capabilities leave the tool list.

How often does the agent need each capability, and how much does it return? Used on most turns, keep it as a tool: the per-turn cost amortizes against per-turn use. Used occasionally, a skill or a CLI is cheaper. Returning large intermediate results that the main thread only needs summarized, it belongs on a delegated agent with its own window, which is sub-agent context isolation and costs an extra model call. The mistake is picking one mechanism for everything, when the right split is usually three servers plus a handful of skills.

What to do next

Measure first. Run one representative request with every server connected and the same request with none, and the difference is the number this decision turns on. Then set a ceiling: decide what share of the context window standing tool definitions are allowed to hold, and treat a proposed sixth server as something that has to fit inside it. The practice is context budgets.

If you own the server, the lever is the shape of the tool list rather than only its length. Tools that each do one thing get called more reliably than overloaded ones, which is what we found when adding a tool cut total calls by 24 percent, and a server that exposes content behind a small stable tool surface stays cheap as the content grows.

Wire is our version of the fixed-surface row, and the case for it is narrow enough to state plainly. Each container exposes the same five tools whether it holds ten entries or ten thousand, so a growing body of shared context arrives as a constant tool header instead of a growing one, which is the comparison on agent efficiency. It does nothing for the five servers you already run. If those five are all in daily use, the recommendation on this page is per-session gating, not a sixth connection.

Sources: Claude Skills are awesome, maybe a bigger deal than MCP · MCP is dead, long live the CLI · I still prefer MCP over skills · Code execution with MCP (Anthropic) · Effective context engineering for AI agents (Anthropic)