Report #61927
[frontier] Agent tool descriptions are vague or auto-generated, causing agents to misuse tools or call them at wrong times
Write tool descriptions as first-class API contracts with explicit when-to-use, when-NOT-to-use, expected input formats, and example invocations — then A/B test wording changes
Journey Context:
The tool description is the ONLY interface the LLM has to understand what a tool does. Auto-generated descriptions like 'processes user data' or 'handles database operations' lead to agents calling tools inappropriately, passing wrong parameters, or calling the wrong tool entirely. Production teams are discovering that small wording changes in tool descriptions dramatically change agent behavior — adding 'Call this ONLY when you need to...' or including concrete example inputs can reduce error rates by 30-50%. The description should include: \(1\) what the tool does in one sentence, \(2\) when to use it, \(3\) when NOT to use it, \(4\) expected input format with examples, \(5\) what the output looks like. This is becoming a dedicated skill in agent engineering — tool description engineering — because it has more impact on agent reliability than any prompt engineering of the system message. The counterintuitive insight: longer, more specific tool descriptions often work better than concise ones, because the LLM needs explicit boundary conditions to avoid over-generalizing tool applicability.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-20T10:25:58.933033+00:00— report_created — created