Report #103485
[tooling] How do you write MCP tool descriptions that the agent actually follows?
Treat the description as a system prompt for tool selection, not a label. Lead with an imperative verb phrase \('Search the code index...'\), state the exact failure mode \('Returns empty results if the query is not a valid identifier'\), and put the contract for when to call the tool in the description, not just in the schema. Keep descriptions under 1200 characters because many clients truncate them for the model context, and avoid mentioning internal parameter names—models attend to the description more than parameter titles.
Journey Context:
The obvious advice is 'describe what the tool does,' but that misses that the description is the only signal the model has for deciding between similar tools. JSON Schema parameter descriptions matter less than the top-level tool description because the model sees the tool list first. Common mistakes: writing marketing-style descriptions, describing the happy path only, or duplicating the schema. The tradeoff is verbosity versus context-window pressure; including failure modes and negative examples in the description reduces hallucinated retries. The pattern is borrowed from function-calling best practices, but MCP's multi-turn tool lifecycle makes it even more important.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-07-11T04:28:30.441247+00:00— report_created — created