← Table of Contents · Page 155 of 868
DESIGNING GOOD TOOLS
Part 2 of 10
CLEAR NAMES AND DESCRIPTIONS
Names.
A good name says what the tool does using a verb and a noun, such as create_calendar_event, search_job_posting, or get_order_status.
A poor name such as doStuff, process, or handle tells the model nothing.
Use one naming style consistently.
Avoid two tools with nearly identical names, because the model may mix them up.
Descriptions.
A description should say what the tool does, when to use it, when not to use it, what each input means, and what comes back.
Here is a weak description: "Searches."
Here is a stronger one: "Searches the company's job postings by keyword and returns up to 10 matches with title, location, and posting identifier. Use this to find postings; do not use it to read a full posting, which needs get_job_posting."
Notice that the stronger one tells the model about its neighbor tool, which prevents confusion.
Input fields should have their own short descriptions and examples, such as "query: one to five keywords, for example 'data analyst Boston'."
Remember that descriptions are part of the model's reading material, so they use up context.
Be clear, but do not be wordy.
Advertisement
Read Aloud:
0:00 / 0:00