MCP is a context budget protocol in disguise
MCP is described as a tool integration standard. The more useful description: it defers context injection until a tool is actually called, turning a static context tax into a pay-per-use model.
The official description of MCP is that it standardizes how LLM applications connect to external tools and data sources. That is accurate. It is also the least interesting thing about it.
The more interesting thing is what MCP does to your context window.
Before MCP, tool integration was a context tax
Every tool your agent could use required pre-injecting its description into the prompt. The tool's name, what it does, what parameters it accepts, what it returns, when to use it, edge cases to watch for. For a real agent with ten or twenty tools, this documentation consumed thousands of tokens on every request, regardless of whether the agent ever called those tools.
The problem is not just cost, though the cost is real. The problem is that all of this static documentation sits in the context window and competes with the actual task. The model is trying to reason about what the user needs while simultaneously processing a telephone directory of tool specifications it may never use.
MCP inverts this. Tools are discovered at call time, not pre-injected at prompt time. The model asks the MCP server what tools are available. The server returns a list. The model invokes what it needs. The full specification is only loaded into context for the tools that are actually called.
Put a rough number on it: a typical tool schema (name, description, parameters, examples) runs 100-200 tokens. Pre-inject schemas for 15 tools and you are paying roughly 2,000 tokens on every single request whether or not any of them get called. If the agent actually calls 2 of those tools, MCP's discover-then-load model pays for roughly 300 tokens instead, an 85% reduction in this example. This is an estimate from typical schema sizes, not a benchmark from a paper; the exact savings depend on your tool count and schema verbosity, but the direction and rough magnitude hold for any agent with more than a handful of tools.
Each server adds 5 tools. The agent only ends up calling 2 of them on a typical task — the rest is dead weight if you pre-load everything.
What this unlocks
The obvious benefit is that you can give an agent access to a large tool ecosystem without paying for it on every request. An agent with access to fifty tools but that typically calls two or three on any given task pays for two or three, not fifty.
The less obvious benefit is that tool ecosystems become composable without coordination. A company can run multiple MCP servers (one for internal databases, one for external APIs, one for file systems) and any MCP-compatible client can discover and use all of them without knowing in advance what they contain. The client doesn't need to be redeployed when a new tool is added to a server. The tool ecosystem grows independently of the agents that use it.
This is the portability story everyone tells. But portability is downstream of the context architecture. You can have portability without context efficiency. You cannot have a large, live tool ecosystem without it.
The security model that matters
One thing the MCP discussions underemphasize: every tool description that loads into the context window is, in effect, an instruction the model will read and potentially act on. This is why ambiguous tool descriptions cause misuse: the model follows the description's intent, not your intent. And it is why untrusted MCP servers are a security concern: a malicious server could return tool descriptions designed to manipulate the model's behavior.
The practical rule is the same as for any other context: treat tool descriptions as code. Review them. Version them. Validate tool inputs server-side; the model can and will send malformed arguments, especially for tools it has seen few examples of. Rate-limit tool calls per session. Do not give an MCP server more trust than you would give the system it has access to.
| Decision | Option A | Option B | When to choose B |
|---|---|---|---|
| Transport | stdio (subprocess) | HTTP/SSE (remote) | Multiple clients share one server; remote deployment |
| Tool scope | Narrow tools, one action each | Broad tools, multiple actions | Almost never — narrow tools are safer and easier to reason about |
| Input validation | Trust the model's output | JSON Schema validation server-side | Always — models send malformed arguments regularly |
| Discovery | Static tool list | Dynamic discovery per session | When tool availability depends on user permissions or context |
| Trust level | Full (internal systems) | Sandboxed (user-provided tools) | Any tool description you did not write and review |
The right mental model
Think of MCP not as an integration protocol but as a lazy evaluation strategy for tools. In programming, lazy evaluation defers computation until the result is actually needed. MCP defers context consumption until the tool is actually called. The philosophical shift is from "load everything upfront, use what you need" to "discover what exists, load only what you use."
That shift is worth more than the portability story. It is the reason large agent systems can be economically viable.
Practitioners are already converging on the same fix:
solution to use MCP servers without context bloat: when I finished reading Anthropic’s “Code execution with MCP” article, a sudden idea flashed in my mind... as many people may already know, subagents have their own context windows, while using MCP as it currently does will Show more
References: Model Context Protocol (Anthropic, 2024), MCP Servers, Anthropic