Description as Trigger

A description is the trigger for on-demand capability: wherever capability loads on demand, a name and a few sentences per option are all the model holds when it decides what to reach for, so the description does the selecting. A description that does not match the task in front of the model means the capability never fires and everything behind it is never read. The same holds for tools: at selection time the model reads the description, and the implementation is invisible. When options overlap or a purpose is vague, the model confuses them, so distinct names and consistent prefixes are part of the same surface.

The writing rule: describe the thing as you would to a new hire. Three kinds of implicit knowledge have to be made explicit, because the model starts with none of them: special query formats, niche terms, and how the underlying resources relate. Say what the thing does, then when to reach for it, with the trigger phrased in words a task would contain: a description that fires on “write tests” or “add coverage” beats one that offers to assist with quality engineering.

Misuse is usually a description bug too. A model that kept appending the current year to search queries, quietly degrading every result, was fixed by rewriting the tool’s description. The code never changed. Watch how the model actually uses the capability, and debug an unused or misused capability at its description first.