The description is a prompt

The single most important idea in tool design: a tool description is a mini system prompt for that capability. The model decides whether and how to call a tool almost entirely from its description. So descriptions should:

• State when to use the tool, not just what it does. "Always call this before answering questions about a document" is far more effective than "reads a document."
• State how to use it well. "Make minimal substitutions of specific words, not whole-line replacements" shapes the model's behaviour decisively.
• Encode the intended workflow. If tool B should follow tool A, say so in both descriptions ("after searching, call read_X with the id from the results"). The model learns the sequence.

I would say - Time spent sharpening descriptions usually beats time spent tweaking the system prompt, because descriptions are read exactly when the decision is being made, so think wisely here.