Part 1 of 5 · 1 min read
Overview
In this module you will
- Write a tool's name, description and parameters so a model picks it at the right time.
- Spot overlapping tools and fix them before they cause wrong calls.
- Write error messages a model can act on, and measure the difference.
- Put checks in code (schema, business rules, previews, idempotency) between the model and any real effect.
- Test descriptions on requests you did not write them for.
An agent is only as good as its tools, and the model meets each tool only as text: a name, a description, a parameter list and whatever the tool prints back. The model never sees your code. If the text is vague, the model picks the wrong tool; if the error is vague, it cannot recover; if the code behind the tool trusts its input, a bad call does real damage. Tool design is therefore mostly writing and defensive programming, and it is where many agent improvements come from, cheaper than a bigger model.
About the examples
The "model" that chooses tools is a word-matching scorer (request words against tool name and description, rarer words count more, ties go to the earlier tool). The "model" that repairs bad calls is a rule program that can only use what the error message says. Real models read meaning, handle phrasing you did not anticipate, and also fail in less predictable ways. The toolbox is an invented order desk with 12 tools, 24 requests I wrote while writing the descriptions, and 12 more written afterwards. Treat the percentages as the shape of an effect, not as benchmarks. No real model or service was called.