Un outil mal décrit sera mal appelé, systématiquement. La description n'est pas de la documentation destinée à des humains : c'est l'interface de programmation que le modèle lit avant de décider. Elle mérite autant de soin qu'une signature de fonction publique.
Trois principes tiennent la plupart des cas. D'abord, un outil fait une chose ; si sa description contient un « ou », coupez-le en deux. Ensuite, les paramètres portent des noms explicites et des types contraints — un enum vaut mieux qu'une chaîne libre, toujours. Enfin, le message d'erreur est pédagogique : il explique quoi corriger, parce que le modèle va le lire et réessayer.
Le test qui ne trompe pas : donnez la description de votre outil à un développeur qui ne connaît pas le projet, sans autre contexte. S'il hésite sur quand l'appeler ou sur ce qu'il doit passer en paramètre, le modèle hésitera aussi — mais lui ne viendra pas vous poser la question.