02.02 · Concept · Free
Designing a tool the model can use
Write a tool description precise enough that the model picks it for the right reason.
Curated for this lesson1/2
Tools and function calling
Anthropic function calling for structured LLM outputs
Directly targets function calling and structured outputs, the closest match to designing model-usable tools.
A model-usable tool description is an interface contract: it tells the model what capability exists, when to call it, what arguments are valid, and what result to expect. Clear names, bounded scope, explicit constraints and output semantics reduce wrong tool calls, bad arguments and guesswork around overlapping capabilities.
What this lesson answers
- how to write llm tool descriptions
- what makes a function callable by a model
- why does my agent choose the wrong tool
Notes
A tool for a language model is not just a function in your codebase. It is a capability advertised to the model in words: what the tool does, when to use it, what inputs it needs, and what it returns. The model decides from the description whether calling the tool is better than answering directly, so the description is part of the interface, not decoration.
A good mental model is writing documentation for a very literal junior developer who cannot inspect your implementation. The tool name should be specific, the description should say the job it performs, and the input schema should use clear field names and constraints. If a tool searches invoices, say whether it searches by invoice id, customer, date range, or all of those. If it cannot modify data, say it is read-only. If it returns raw records rather than a final answer, say that too.
The common misconception is that the model will infer the right use from the function name or from your application context. It often will not. Vague tools like lookup_data or process_request force the model to guess, and overlapping tools make that worse. Precision helps the model pick the tool for the right reason, avoid calling it when it already knows the answer, and pass arguments your code can actually validate.
After this lesson, you should be able to write a tool description that includes purpose, appropriate use cases, non-use cases, required inputs, and expected output. You should also be able to spot ambiguous descriptions and improve them before debugging model behavior in production.
Common questions
- What should an LLM tool description include?
- Include the tool’s purpose, the situations where it should be used, situations where it should not be used, required inputs, constraints on those inputs, and the shape of the returned data. The model cannot inspect your implementation, so the description and schema are the API it uses to decide whether the call is appropriate.
- Why is a function name not enough for tool calling?
- A function name rarely communicates boundaries, input requirements, side effects or return semantics. Names like lookup_data or process_request make the model infer intent from weak signals. A precise description tells the model whether the tool reads or changes data, what domain it applies to, and when answering directly is better.
- How do overlapping tools confuse an agent?
- If several tools appear to solve similar problems, the model may pick one for the wrong reason or pass arguments that fit another tool. You reduce that by giving each tool a distinct purpose, explicit non-use cases, and field names that match the exact operation your code validates.
Short definition: what is Designing a tool the model can use?