Tool Use
Letting a model call real software — a search, a calculator, your database — instead of trying to answer everything from memory.
When not to use it
- When one lookup would do. If your code already knows it needs the weather, call the weather API. Asking a model to decide adds latency, cost, and a chance of it deciding wrong.
- For anything irreversible without a confirmation step. A tool that sends, pays, or deletes should not fire on a model's judgement alone.
- When the tool's output is untrusted. Web pages and user documents can carry instructions the model may follow. If you can't sanitise it, don't hand it to a model with tools.
Reach for something else instead
- Hardcoded calls — if the sequence is known, write the sequence. It's faster, cheaper, and testable.
- Structured output when you only need the model to fill in a form and your code does the rest.
- RAG when the real need was reading documents, not taking actions.
Sources & further reading
- Schick et al. (2023), Toolformer: Language Models Can Teach Themselves to Use Tools — models learning when to call, not just how.
- Yao et al. (2022), ReAct: Synergizing Reasoning and Acting in Language Models — the reason-then-act loop underneath most agent frameworks.
- Greshake et al. (2023), Not what you've signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection — why tool results are an attack surface.
Primary sources, listed so you can check the claims on this page rather than take them on trust.
Where people go wrong
- Writing tool descriptions for yourself instead of for the model. It only sees that text; ambiguity there becomes wrong calls at runtime.
- Giving the model twenty tools and blaming it for confusion. Selection degrades with count — group them, or route to a subset first.
- Treating tool errors as rare. In production they're constant, and a model that gets an unhandled exception back will improvise something.