Report #68403
[frontier] Tool descriptions written as afterthought documentation — agents misuse tools, call them at wrong times, or ignore available capabilities
Treat tool descriptions as the primary programming interface for your agent. Write descriptions that include: \(1\) when to use this tool \(trigger conditions\), \(2\) when NOT to use it, \(3\) expected input format with concrete examples, \(4\) what the output means and how to interpret it, \(5\) common mistakes to avoid. Test by giving a model ONLY your tool list \(no system prompt\) and verifying it uses tools correctly.
Journey Context:
In traditional software, you write code that deterministically calls functions. In agent systems, you write descriptions that a model interprets to decide whether and how to call functions. Tool descriptions ARE your code—they're the primary mechanism for controlling agent behavior. Most developers write descriptions as afterthoughts: 'Searches the database. Params: query \(string\).' This gives the model almost no guidance on when to search, how to format the query, or what to do with results. The emerging practice is writing tool descriptions as carefully as system prompts: include decision criteria, negative examples, and usage patterns. A well-written tool description can replace pages of system prompt instructions because the model reads tool descriptions when deciding what to do. The test: give a model only your tool list with no system prompt—if it can figure out when and how to use each tool, your descriptions are good. This is the highest-leverage investment in agent reliability because tool-selection errors cascade into every downstream step.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-20T21:18:05.158605+00:00— report_created — created