The MCP conversation in developer communities right now focuses heavily on enterprise governance and permission models. Those are real concerns. But there's a more immediate constraint that gets less attention: for anyone running smaller local models, MCP's token consumption pattern is a structural problem, not just an inconvenience.
Here's the shape of the issue.
Context windows are not equal
A cloud-hosted model with 128k context can absorb verbose tool descriptions from three or four MCP servers and still have room for a real conversation. A locally-run 7B model with 8k context cannot. When a single MCP server pushes 30 tool descriptions into your context, you've consumed a meaningful fraction of your budget before the first user message.
This isn't a hypothetical. Tool descriptions in practice are verbose because they need to be — the model uses them to decide when and how to invoke each tool. A terse description saves tokens but degrades routing accuracy. A thorough description costs tokens but works better. The tradeoff is real and there's no free solution.
Teams working on this have landed on a few approaches: stripping descriptions to a minimum and accepting some mis-routing, implementing dynamic tool loading that only injects relevant tools based on detected task context, or hard-capping the number of active servers per session. None of these is clean.
The permission model problem is different for local deployments
Much of the permission discussion frames MCP's all-or-nothing trust model as an enterprise security concern. For local deployments, the concern is more immediate and personal: if you're running an MCP server against your local filesystem or a local database, there's no granular scope between "the agent can read this directory" and "the agent can do anything the server exposes."
Some practitioners have built lightweight gateway layers that intercept MCP calls and apply scope rules before they reach the server. This works, but it adds a component that needs maintenance and introduces its own failure modes. The protocol not solving this at the spec level means every team that cares about it solves it differently.
Server quality varies in ways that matter for smaller models
Most published MCP servers are REST API wrappers. The tool surface reflects the original API's design, which was built for human developers, not for language model consumption. Good tool design for LLMs is different: tools should be narrow, names should be unambiguous, descriptions should front-load the most discriminating information.
For a large model with strong instruction following, a mediocre tool description is recoverable. For a smaller local model, a poorly described tool that looks similar to another tool produces consistent mis-routing. The quality gap in the ecosystem hits smaller models harder.
What the protocol actually gets right
The case for MCP is the glue-code argument, and it holds. Before a common standard, connecting an agent to multiple heterogeneous data sources meant writing custom integration logic for each one. Different auth patterns, different error handling, different tool surface conventions. MCP collapses that into a single interface pattern. Even with the current rough edges, the reduction in integration overhead is real and measurable once you're past the initial setup.
Where this leaves practitioners
The protocol is doing something genuinely useful. The implementation has concrete problems that hit local model users harder than cloud users. The ecosystem is early enough that server quality and tool design norms haven't stabilized.
The practical question for anyone building with local models right now: what's your actual strategy for keeping MCP tool descriptions from consuming your context budget, and does it hold up when you add a third or fourth server to the mix?
Top comments (1)
The context window asymmetry is real but it is not the whole story. Even with unlimited context, the problem is that every tool description competes for the model's attention at generation time. A local model with limited attention (fewer parameters, fewer heads) struggles more not because the token budget is smaller, but because the signal-to-noise ratio of the tool descriptions relative to the actual task is worse.
The better fix is not more efficient tool descriptions. It is routing fewer tools per step. If the agent only sees the 3 tools that are relevant to the current state instead of all 30, the context consumption drops and the attention improves. That is a routing problem, not a context problem.