MCP Servers Do Cost You Tokens. The Question Is How Much, and Who's Choosing.

Connect enough Model Context Protocol servers to Claude Code and someone will eventually tell you it’s eating your context window. The claim floats around as an anecdote: MCP costs tokens, full stop. That version is close enough to be believable and vague enough to be useless. The real answer is more specific, and more useful, because the size of the cost turns out to be something you can see, and in most configurations, control, not a fixed toll you pay for connecting a tool.

Start with what the protocol actually specifies, because that part isn’t in dispute. The Model Context Protocol defines tools as things a server exposes with a name and a schema describing what they do and what they take as input. That’s it. The spec says how a server describes and exposes a tool. It doesn’t mandate how a client puts that description in front of a model, or when. Whether a full schema sits in context on a given turn is a decision the client makes, not something MCP requires.

In practice, loading everything upfront has been a common client-side default, documented across implementations rather than something the protocol requires. Hasan et al.’s 2026 study of MCP tool descriptions opens from that same premise: tool metadata “repeatedly injected into the [foundation model’s] context during a typical interaction… is inflating token usage.” Amazon Web Services (AWS)‘s own machine learning engineering blog describes the same default from the vendor side: “tool definitions load into the LLM’s [large language model’s] context on every call, whether the tool is used or not.” That’s a description of how eager-loading clients behave, not a rule the protocol imposes. Claude Code, as it turns out, is a case where the client’s own default has moved away from it.

Before Tool Search, which Anthropic introduced on November 24, 2025, eager loading was the default in Claude Code: connecting a server meant paying for its entire tool catalog on every turn, whether you used any of it or not. One developer’s own measured /context output from Claude Code, taken about two months before Tool Search existed, showed MCP tools jumping from 2.8% of a 200,000-token window with one server enabled to 41% with several enabled at once. GitHub’s own maintainers documented a concrete, dated example of the same effect on their most popular official server: cutting the default toolset from 101 tools and 64.6k tokens down to 52 tools and 30.3k tokens, a 53% token reduction, in an October 2025 update aimed squarely at this cost. Separately, Anthropic’s engineering team described a related but distinct approach, exposing tools as code rather than deferring their schemas, that cut one workflow’s tool-definition overhead from 150,000 tokens to 2,000. That’s not a universal number, it’s one workflow using a different mechanism than what Claude Code ships by default, but the direction matches everything else here: loading less upfront saves real tokens.

The fix Claude Code actually ships as its default is Tool Search, on by default for Claude 4.5-generation models and later, which defers full tool schemas until Claude actually needs one. At session start, only tool names and server instructions load, not the full catalog of parameters and descriptions. Anthropic’s own documentation for exploring the context window confirms the same behavior from the other side: “by default, full schemas stay deferred and Claude loads specific ones on demand” rather than all at once. Anthropic’s own numbers for Tool Search specifically, not the separate code-execution example above, describe an overall “up to 85% reduction in token usage” in one comparison. A different breakdown in the same Tool Search announcement puts a traditional upfront-loading setup at roughly 77,000 tokens before any work begins against roughly 8,700 tokens with Tool Search enabled. The two figures come from different comparisons in the same piece, not one clean before-and-after, but both land in the same range and point the same direction. Two different Anthropic teams solved a version of the same problem two different ways, and Tool Search is the one that became Claude Code’s default.

Whether connecting an MCP server to Claude Code still increases your token usage depends entirely on the client’s configuration, which is exactly the point: this used to be a fixed cost, and now it’s a setting you can inspect. Claude Code’s actual default behavior is to defer every eligible MCP tool unconditionally, no percentage threshold involved at all. A separate, optional auto mode exists for anyone who wants a middle ground: set explicitly, it loads tool definitions upfront while they total less than a configurable share of the context window (10% unless you change it) and defers them once they cross it, but that’s a choice you opt into, not what happens by default. Tool Search’s unconditional deferral itself doesn’t run in every configuration. On Google Cloud’s Agent Platform specifically, Claude Code falls back to loading everything upfront for models that predate the 4.5 generation. More generally, it also falls back when ANTHROPIC_BASE_URL points to a non-first-party host, and on Microsoft Foundry deployments hosted on Azure, which reject the required request format server-side. In any of those fallback cases, the pre-mitigation math is exactly the math above: more servers and more tools connected in that mode means more context occupied on every turn, though what that costs in billed tokens can still vary with caching and which tools actually get used. Even description quality carries a real cost independent of connection count. Hasan et al. found that across the model-and-domain combinations they tested, the median change in average execution steps rose 67.46% when tool descriptions were made more thorough, meant to help the model use them correctly, a real tradeoff between clarity and overhead in that study, not necessarily a universal law.

It’s tempting to hear “Anthropic already fixed this” and conclude the original question is moot. That’s too fast: an older model, a base-URL proxy, or a Microsoft Foundry deployment are all documented ways Claude Code falls back to eager loading regardless of what you’d otherwise choose, and anyone who deliberately opts into the optional auto threshold mode with several modest servers connected is choosing a version of the same tradeoff on purpose. It’s just as tempting, in the other direction, to treat every number floating around the internet as gospel. It isn’t. Several widely repeated figures, a flat “15,000 to 20,000 tokens per turn” per server, a claim that multiple servers “eat 30% to 50%” of a context window, a specific threshold where “context rot” sets in around 50,000 tokens, showed up only in an AI search summary during this piece’s research, and I could not independently verify them against a primary source. One related figure I did verify, MindStudio’s “roughly 18,000 tokens per turn” estimate, turned out to be that site’s own self-described “realistic mid-range estimate,” built from illustrative component numbers rather than a measurement method or dataset. The others may be similarly soft, or they may not be. Without tracing them, there’s no way to say. Repeating unverified figures as fact does the same disservice as the original vague anecdote this piece started with.

The honest version of the claim, then, is narrower and more actionable than either extreme. MCP integrations can add real context overhead, and how much depends on the client’s tool-discovery and loading strategy, Claude Code’s own included. That’s the settled part. How much context your setup is currently using is something Claude Code will show you directly if you ask, the same /context command behind the concrete before-and-after numbers earlier in this piece, rather than something you have to take on faith from a blog post. The practical move isn’t to avoid MCP or to shrug off the cost. It’s to check what’s actually loaded before assuming the worst, or before assuming there’s nothing to check at all.