The Context Cost of Idle MCP Servers

What the cost is

An MCP client sends the definitions of every tool exposed by every connected server to the model as part of the request. Leaving servers connected that a project does not use spends context window on those definitions on every turn, and widens the set of tools the model chooses from.

The cost lands before the first message

The MCP tools concept documentation describes the flow: the client calls tools/list, the server returns each tool’s name, description and JSON Schema inputSchema, and the client makes those definitions available to the model. That happens at connection time. The tokens are spent whether the conversation ever calls a tool or not — an unused server is not free, it is a fixed subscription paid once per turn for the life of the session.

Schema size is what varies. A tool with two string parameters costs little; a tool whose input schema carries a dozen optional fields, each with a description, costs considerably more. Two servers exposing the same number of tools can differ several-fold in tokens.

Selection accuracy degrades before cost does

The token bill is the visible cost and usually not the binding one. The binding one is that a larger tool surface means more plausible-but-wrong choices. When two servers expose tools with overlapping vocabulary — anything named around “search”, “get”, “list”, or “upload” — the model has to discriminate between them on description text alone, and it will sometimes pick the wrong one.

A wrong call is not a free retry. It is a round trip to the server, an error or an irrelevant result coming back into the window, and a recovery turn to correct course. That is three costs where the misjudgement looks like one, and the returned payload stays in the context for the rest of the session. Accuracy degrades on a curve that bends earlier than the token curve, which is why “I still have plenty of context left” is the wrong test for whether a server should stay connected.

Vendors say the same thing

Cloudinary publishes five MCP servers — Asset Management, Environment Config, Structured Metadata, Analysis, and MediaFlows — and its MCP server documentation advises disabling the servers a given task does not need rather than running all five. That is a vendor recommending against maximal use of its own surface, which is a reasonable signal about where the tradeoff sits. A project doing transformation work needs Asset Management; it almost certainly does not need Structured Metadata and Environment Config loaded at the same time. Related reading covers configuring the MediaFlows MCP server if that is the one you keep.

Two instruments, different precision

Disabling a whole server is the coarse instrument. It is available in every client, it is reversible in a config edit, and it takes the server’s entire tool set to zero — which is the wrong outcome when a project needs two tools out of fifteen.

The fine instrument is a per-connection tool allowlist: the client filters the tools/list response and presents only the named tools to the model. That cuts a fifteen-tool server to the three tools a project actually uses, keeping the capability while dropping the schemas of everything else. The specification defines tool discovery at the protocol level; filtering is a client-side concern layered on top, so support and syntax vary by client rather than being guaranteed by the protocol. The mechanics are covered in restricting which tools an MCP server exposes.

An allowlist also has a second effect: it removes the near-synonym tools that caused the ambiguity in the first place. Cutting a server from fifteen tools to three usually removes more selection error than it removes tokens.

The judgement is per workspace, not global

There is no correct server set to configure once. A media-heavy project — one whose daily work is uploads, transformations and asset lookups — is right to keep several media servers connected and take the token cost, because the tools get called. A project that touches media twice a year is paying that cost on every turn of every unrelated session to save two minutes of configuration on the two days it needs them.

This argues for per-workspace or per-project client configuration over a single global one. It also argues for periodic review: a server added for a migration that finished six months ago is still being loaded. Where a vendor ships both an MCP server and an agent skill, the choice between them is partly this same question, since a skill is loaded on demand while a connected server is loaded always. The same applies to choosing a CLI over an MCP server for bulk operations — a one-off bulk job does not justify a permanent connection.

What to check next

To act on any of this you need your client’s actual numbers, which are client-specific: how it reports per-server token usage, whether it supports a tool allowlist and in what syntax, and whether its configuration is global or per workspace. From there, the adjacent decisions are how a server is authenticated and which transport its endpoints use, both of which affect whether a connection is cheap enough to leave in place.