TL;DR: MCP tool descriptions act like load-bearing prompt fragments, according to Archestra, because the model reads the description, schema names and parameter text at selection time and often skips tools when the copy is hedged or vague. Tight, opinionated descriptions change tool choice, reduce wrong calls and make the trigger, negative case and return shape explicit.
Editorial analysis by NHI Mgmt Group, based on content published by Archestra: “MCP Tool Description: Why It Is a Prompt, Not Documentation”.
Key questions
Q: What breaks when MCP tool descriptions are treated as harmless documentation?
A: Security teams miss a second instruction channel that can steer the model even when the package is clean.
Q: Why do hedged MCP descriptions reduce reliable tool use?
A: Hedged wording lowers the model’s confidence about when a tool is appropriate, especially when another tool has a sharper trigger phrase or a more direct description.
Q: How should teams write MCP descriptions for overlapping tools?
A: Describe the specific job, the user signal that should trigger the call, the cases where the tool should not be used, and the shape of the output.
Practitioner guidance
- Audit every MCP tool description for selection clarity Replace hedged copy with a verb-led statement, a concrete trigger, a clear do-not-use condition and a short return shape.
- Add negative cases to overlapping tools Where two tools can plausibly satisfy the same request, specify the boundary between them so the model knows which one to choose first.
- Review schema property descriptions as routing signals Make parameter descriptions explicit enough that the model can infer required inputs without treating the field as a generic hint.
Bottom line: Weak MCP descriptions can suppress correct tool selection even when the schema and backend are sound.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →