A tool is any capability you expose to the model.
Common tools are web search, database queries, calculators and file operations.
The description you write is what the model uses to decide when to call it.
Vague descriptions are the most common reason tools get called wrongly.
Every tool should validate its inputs, because the model can and will pass odd arguments.
A tool is any capability you expose to a model, and the word covers a lot.
Web search, a database query, a calculator, a file read, an email send.
Anything your code can do can be offered, which is both the power and the risk.
The description is the entire interface, since the model sees nothing else.
Write it for a competent stranger with no context about your system.
Say what the tool does, when to use it, and just as importantly when not to.
Vague descriptions are the most common cause of wrongly chosen tools.
Parameter descriptions matter as much as the tool description.
Say that a date must be ISO format, or you will receive next Tuesday.
Keep the return value small and readable, since it is consuming context.
Dumping a hundred rows of JSON wastes budget and buries the useful part.
Every tool must validate its own inputs, because the model will pass odd arguments.
Give each the narrowest permissions it needs and no more.
Assume any content a tool returns may contain an injection attempt.
A read-only tool is a fundamentally safer thing than one that writes.
One question on this card. Every option explains itself once you pick, right or wrong.
17 concepts in this module, then a graded test with every answer explained.