Why MCP Tool Descriptions Determine Whether AI Agents Pick the Right Tool

When AI Agents Choose the Wrong Tool, the Description Is Usually to Blame

In the MCP (Model Context Protocol) ecosystem, there's a commonly overlooked fact: how does a large language model (LLM) actually decide which tool to call? The answer isn't mysterious — it relies on the tool's name and description. The model has no visibility into the tool's internal implementation; those two pieces of text are all it has to go on.

In other words, tool descriptions are no longer optional documentation — they're critical inputs that directly shape agent behavior. As one video puts it: "Now it's important." We used to dash off descriptions as an afterthought. Now they've become a variable that determines success or failure.

From "Documentation" to "Decision Input"

Developers generally dislike writing docs, and tool descriptions are no exception. But in an MCP architecture, the description text enters the model's context directly and becomes the primary basis for deciding "which tool to use." A vague, redundant, or semantically unclear description is like handing the model an unreadable map.

Parameter descriptions matter just as much. Even when the tool name is clear, ambiguous parameter explanations make it easy for the model to fill in arguments incorrectly, leading to failed calls or unexpected behavior.

MCP (Model Context Protocol) is an open protocol proposed by Anthropic to standardize how large language models interact with external tools and data sources. Under this framework, tools are exposed to the model in a structured way: each tool has a machine-readable JSON Schema describing its name, a functional description, and the types and constraints of its required parameters. During inference, the model receives this "metadata manifest" for all registered tools and selects the most appropriate one based on the user's intent in the current conversation. This is precisely why description text isn't a supplementary comment — it's directly incorporated into the model's reasoning context, and the precision of its wording has a direct impact on call accuracy.

Research Shows: Most Tool Descriptions Are Poor Quality

Multiple papers have been published specifically measuring the quality of tool descriptions. After analyzing roughly 100 MCP servers, researchers reached a fairly blunt conclusion: most descriptions are crap.

The problems cluster around two dimensions: the tool-level descriptions lack clarity, and the parameter descriptions are equally weak. Together, these make it very difficult for an LLM to make accurate judgments among multiple candidate tools. When a tool library is filled with semantically similar, vaguely described entries, the model is faced with a pile of options that all look roughly the same.

Why Description Quality Directly Affects Selection Accuracy

Tool selection is fundamentally a semantic matching process: the model compares the user's intent against the name and description of each tool and picks the best fit. If multiple tools have descriptions that don't clearly distinguish them, the matching outcome becomes nearly random. The more precise and well-bounded each description is, the more reliably the model can make a decision.

This semantic matching process is technically related to vector retrieval and attention mechanisms. When the model generates its "which tool to call" decision, it's essentially computing similarity between the user's intent and each tool description in a high-dimensional semantic space. When two tools' description vectors are too close together (i.e., high semantic similarity), the model's attention weights tend to equalize, making it hard to produce a clear preference — resulting in a random or incorrect selection. A counterintuitive finding: the more tools you have with similar descriptions, the lower the overall usability of the entire tool chain may be compared to a system with fewer but precisely described tools. When designing a tool library, differentiation in descriptions matters more than coverage.

Picking the Wrong Tool Is Just One Way Things Can Go Wrong

When an LLM can't identify the correct tool, several typical failure modes emerge.

The most direct failure is selecting the wrong tool — the model picks something that seems relevant but isn't right for the task, leading to a completely off-target outcome.

A subtler failure mode, highlighted in a Microsoft research study, is that agents sometimes do nothing at all. Because all the tools look roughly the same, the model can't determine what to do next and simply stalls. This "paralysis" state is just as fatal in real-world applications — the user is left with an agent that appears unresponsive.

What This Means for Developers

Since tool descriptions directly determine the quality of agent behavior, teams building MCP servers should treat descriptions as first-class citizens:

• Tool names should be distinctive — avoid semantic overlap between multiple tools;
• Descriptions should clearly state purpose and applicable scenarios, not just restate the function name;
• Parameter descriptions should be specific, explaining each parameter's meaning, format, and constraints;
• Actively differentiate — when functionally similar tools coexist in the library, highlight the boundaries between them in the descriptions.

The core takeaway in one sentence: in the age of AI agents, writing good tool descriptions is no longer nice-to-have documentation work — it's the engineering foundation that ensures agents actually work correctly.

Conclusion

MCP enables LLMs to call external tools, but a model's ability to choose well is bounded by the text it can read. Well-written descriptions lead to accurate, decisive agent actions; poorly written ones result in either selecting the wrong tool or grinding to a complete halt. For teams building MCP tool chains, reviewing and improving existing tool descriptions may be the single highest-return, lowest-cost step toward improving agent reliability.