// blog / context engineering
Your MCP servers are silently eating your context window
The cost isn't in the tools you call. It's in the definitions of every tool you could call, loaded before you type a word.
Where the tokens go
MCP works by describing tools to the model: in most clients, every connected server contributes its tool names, descriptions, and parameter schemas to the context window up front. (Claude Code now defers full schemas by default — only tool names load until a tool is actually used — which is this post's cut #2 arriving as a platform default.) Community measurements put a single feature-rich server in the multiple-thousands of tokens, and a handful of connected servers can claim tens of thousands — before the conversation starts. The insidious part is invisibility: nothing in the chat shows the overhead, sessions just start closer to the point where context rotbegins, and your first "hi" already bills a surprisingly large prefix.
Measure before optimizing. In Claude Code, /context shows what occupies the window, including MCP tool definitions — run it once with your normal setup and the number makes the rest of this post concrete.
Three cuts, in order of leverage
1. Disconnect by default; connect per project. The database explorer you used once in March charges rent in every session since. Server lists live in config, and scoping them per project is the highest single cut.
2. Prefer deferred/on-demand tool loading where available. The pattern is spreading across clients: keep tool namesvisible, load full schemas only when a tool is actually needed. Anthropic's tool-writing guidance pushes the same economics from the server side: the quality and quantity of context a tool returns both matter.
3. Distill what tools return.A tool that dumps 10K tokens of JSON when the agent needed three fields is the same bug in a different place. Anthropic's sub-agent pattern is the endgame: heavy exploration happens in an isolated context and only a condensed summary — often 1,000–2,000 tokens — returns to the main thread.
How we apply this to our own MCP server
This economics shaped PLE's MCP server: four read-only tools with deliberately thin schemas — list, search, get, fill — so your prompt library rides along at minimal standing cost, and the heavy content (the prompt itself) enters context only when the agent actually pulls it. The same just-in-time principle as a lean CLAUDE.md: pay for what the task needs, when it needs it, and let everything else wait outside the window.