97% of MCP Tool Descriptions Have Quality Problems — and Your Agent Pays for It

The invisible tax on every MCP-powered agent ¶

Every time your agent runs, it carries its full tool manifest in the context window. Thirty tools, fifty tools, a hundred. Each description injected into every call whether the tool is relevant or not. Most developers think of this as a fixed overhead and move on.

They shouldn't. A February 2026 study, "MCP Tool Descriptions Are Smelly!" (arXiv:2602.14878), audited 856 tool descriptions across 103 MCP servers and found that 97.1% contain at least one quality defect, what the authors call a "smell." These aren't cosmetic issues. They directly affect agent behavior and, through the agent's execution path, your token bill.

What a "smell" actually means ¶

The paper identifies smell categories including: descriptions that fail to state what the tool does, ambiguous parameter explanations, missing error behavior, and overlapping functionality described with different vocabulary. The practical effect: agents with smelly tool descriptions misroute calls, retry unnecessarily, and select wrong tools, all of which expand the execution trace and inflate token consumption.

When the researchers augmented tool descriptions to remove smells, task success improved by a median of 5.85 percentage points. Partial goal completion improved by 15.12 percentage points. The cost? Augmented descriptions increased average execution steps by 67.46%: agents took more steps, but got further. 56% of tools in the corpus failed to clearly state their purpose in the description.

The tradeoff is real: better descriptions improve outcomes but also change execution patterns. The point isn't that more tokens are always bad. It's that *wasted* tokens from poor routing are pure cost with no quality return.

The three smell patterns that hurt most ¶

1. Purpose ambiguity. 56% of analyzed tools failed to clearly state what they do in the opening line. An agent scanning for a web search tool and encountering "Retrieves external data based on query parameters" cannot confidently distinguish it from a database lookup tool.

2. Parameter under-specification. When a tool description omits what a parameter's valid range or format is, the agent either guesses (and retries on error) or asks a clarifying question (adding a round-trip). Both paths cost tokens.

3. Functional overlap without disambiguation. Multiple tools with similar descriptions but different scopes cause the agent to try the wrong one first, get an error or partial result, and re-invoke. Each failed attempt recirculates full context.

What this means operationally ¶

If you run MCP-powered agents in production, your tool manifest is probably working against you, not because MCP is flawed, but because the ecosystem grew fast and description quality wasn't enforced.

The practical audit:

`` For each tool in your manifest: 1. Can you state what it does in one sentence without jargon? 2. Does every parameter have a concrete example? 3. Is there another tool it could be confused with? If yes, does the description differentiate? `

If the answer to any of these is no, that tool is a misrouting risk.

Context compression as a parallel fix ¶

Auditing tool descriptions fixes the routing problem at the source. But for agents where you don't control the tool manifest (third-party MCP servers, auto-generated descriptions, or tools you inherited) context compression at the ingestion layer is the complementary fix.

gotcontext's gc_compress_manifest tool compresses the tool schema injected into your agent's context, preserving the semantically load-bearing information while cutting the token footprint of the manifest itself. When combined with description hygiene, you get both better routing (fewer wasted calls) and smaller per-call context (lower baseline cost).

`json { "mcpServers": { "gotcontext": { "url": "https://api.gotcontext.ai/mcp", "headers": { "Authorization": "Bearer gc_live_YOUR_KEY" } } } } ``

The study is clear: 97.1% of MCP tools have quality problems, and fixing them demonstrably improves agent outcomes. Your context window is being taxed by descriptions that weren't written with token cost in mind. That's fixable starting this afternoon.

Fix your context overhead →