MCP Context Bloat: How to Govern Tool Growth

MCP context bloat is the hidden tax of giving coding agents too many tools at once. Each enabled MCP server can add tool names, descriptions, input schemas, output schemas, and tool results to the model context before useful coding work begins. For a platform engineering lead, the fix is not simply buying a larger context window. The fix is governance: measure the tool load, scope it by workflow, defer what is not needed, cap noisy outputs, and treat tool metadata as part of the security boundary.

The problem usually starts as a success story. GitHub MCP makes repository work easier. Slack helps with incident context. Jira or Linear adds ticket history. Sentry, Grafana, Splunk, Postgres, browser automation, cloud APIs, internal docs, and internal platform tools each solve a real problem. Individually, they are useful. Combined, they can turn a coding-agent session into a crowded tool catalog with less room for code, logs, diffs, tests, and reasoning.

Why MCP context bloat happens

MCP tools are model-controlled. That means the model needs enough information to discover a tool, decide whether to call it, and construct valid arguments. In practice, clients often expose every enabled tool's name, natural-language description, and JSON Schema at session start or request time.

That design is convenient, but it scales poorly. Tool definitions are schema-heavy by nature. The research brief cites a five-server example from Anthropic where GitHub, Slack, Sentry, Grafana, and Splunk together produced 58 tools and roughly 55,000 tokens before the conversation began. Adding Jira was estimated to push the baseline toward more than 100,000 tokens. A GitHub MCP Server discussion reported an earlier default behavior that exposed 101 tools consuming 64,600 tokens.

The exact numbers vary by client, model, prompt caching, and server design. The direction does not. More servers usually mean more schemas, more overlapping verbs, more repeated fields, and more work for the model before it edits a single file.

Three kinds of bloat

Platform teams should separate MCP context bloat into three categories. They have different causes and different controls.

This distinction matters because schema reduction alone is not enough. A compact tool can still return a megabyte of logs. A low-token description can still contain misleading instructions. A fast tool can still expose credentials or sensitive data in a session where it does not belong.

The operational impact

The first impact is cost. If each session starts with tens of thousands of tool-definition tokens, every request inherits a higher baseline for attention and context use. Depending on the provider and cache behavior, the billed cost may vary. Prompt caching may reduce billed cost in some deployments, but it does not remove the attention and context-capacity problem.

The second impact is latency. Larger prompts take longer to process, and tool-heavy sessions often add extra round trips for selection, execution, and recovery from wrong calls.

The third impact is lower effective code context. Coding agents already need room for repository files, diffs, test output, build failures, instructions, review comments, and conversation history. A 30,000-token tool catalog competes directly with that material.

The fourth impact is tool confusion. When a model sees many similar tools, overlapping domains, and long schemas with repeated fields, the odds of wrong-tool calls and malformed parameters rise. Anthropic's cited internal evaluations report accuracy gains from Tool Search, but those are vendor-reported results. Treat them as a useful signal, not as a universal benchmark.

The fifth impact is security. Tool names, descriptions, schemas, and outputs are model-visible prompt content. More tools mean more metadata that can steer the model. More connected systems mean more paths for accidental disclosure or malicious instruction injection. This is why MCP security guidance around user confirmation, result validation, timeouts, and audit logging belongs in the same conversation as performance.

Set a tool budget

Treat MCP capacity like any other platform budget. You would not let every service emit unlimited logs into a hot path. Do not let every MCP server inject unlimited schema and output into coding sessions.

A practical budget starts with four numbers:

• Total loaded tools per profile: count what the model sees at session start.
• Schema tokens by server and tool: identify heavy tools and repeated schema patterns.
• Tool result size: track rows, bytes, tokens, and truncation rates.
• Wrong-tool or denied-call rate: measure confusion and policy pressure alongside speed.

Use these numbers to define thresholds. For example, a normal coding profile might keep only repository, docs, and test-related tools active. An incident profile might add observability and Slack. A migration profile might add database tools with stricter approvals. An empty or no-MCP profile should exist for sensitive code review and baseline performance testing.

MCP context bloat checklist

Use this checklist when onboarding or reviewing MCP servers:

• Inventory: list every MCP server, scope, owner, credential path, and enabled tool.
• Scope: prefer project or session configuration over global user-level installs for broad SaaS tools.
• Profile: create named profiles such as coding, incident review, design review, data migration, security review, and no-MCP.
• Allowlist: load only the tools that a workflow actually needs.
• Defer: use tool search or deferred loading when catalogs exceed roughly 10 tools, more than 10,000 tokens, or show selection errors.
• Shorten: keep descriptions concise, specific, and disambiguated. Avoid embedding manuals in tool descriptions.
• Shape responses: require pagination, field selection, limits, dry-run modes, and summaries for high-volume APIs.
• Sandbox workflows: use programmatic or code-execution patterns when multi-step workflows would otherwise dump intermediate data into context.
• Audit: log tool calls, arguments, output sizes, denied calls, and per-server context contribution.
• Review security: treat tool metadata and tool output as untrusted content that can influence model behavior.

Split responsibility between servers and clients

MCP server authors control tool design. They can split large servers by domain, use toolsets, remove redundant descriptions, design narrower schemas, paginate outputs, and expose safer summary tools for common workflows.

MCP clients and platform owners control loading behavior. They can enforce allowlists, deny risky tools, implement deferred discovery, show schema context as its own accounting category, cap responses, and require confirmation for sensitive operations.

Neither side can solve the problem alone. A concise server still becomes risky if it is globally available in every repository. A disciplined client still suffers if a server returns unbounded logs or exposes 100 loosely named tools by default.

Trade-offs to watch

Deferred loading is not free. It can add a discovery step, introduce retrieval misses, or make the agent search when direct loading would have been faster. Concise schemas are not automatically better either. If descriptions are too terse, parameter quality and tool selection can degrade.

Programmatic tool use also has an operating cost. Letting the model write code against tool APIs can reduce intermediate context pollution, but it requires sandboxing, resource limits, monitoring, and clear data-handling rules.

The right posture is conditional. Keep high-frequency, low-risk tools loaded. Defer broad or rarely used tools. Split domains when a server becomes a kitchen sink. Require response shaping for APIs that can return large datasets. Put sensitive or destructive tools behind explicit approval.

What good looks like

A healthy MCP program gives developers useful tools without turning every coding session into a general-purpose enterprise console. The platform team can answer basic questions quickly: which tools are loaded, how much context they consume, which servers are noisy, which outputs are capped, and which calls require approval.

MCP context bloat is not a reason to avoid MCP. It is a reason to operate it like infrastructure. Measure the catalog. Budget the context. Scope the credentials. Filter the outputs. Log the calls. The teams that do this will get the benefit of connected coding agents without paying an uncontrolled tax in latency, cost, reliability, and security exposure.