Tool Use
Beginner 11 min read Tool Use

Tool Use Overview

Capabilities beyond the weights

Tools extend a model beyond its weights: search, code, retrieval, computation. Function calling gives the interface; tool-use patterns turn that interface into real capabilities with constraints and feedback loops.

tool usetoolscapabilitiessearchcoderetrieval
Prerequisites: Function Calling
Before we start

What you will learn

  • Classify the major tool categories
  • Decide which tools a product needs
  • Design tool feedback loops
Introduction

What is this?

Tool use is the practice of giving a model instruments — web search, code executors, RAG retrievers, calculators, internal APIs — invoked via function calling and fed back as results. The model's static knowledge becomes an orchestration layer over living systems.

Motivation

Why do you need it?

  • Fresh data and private data live outside weights.
  • Tools turn 'I don't have access' into 'let me check'.
  • Each tool is independently testable and governable.
  • Tool mix IS product scope: search vs write changes the UX.
Think about it

Mental model

Imagine

An assistant with a desk full of instruments

Think of

Tool use

Phone (web search), computer (code), filing cabinet (retrieval), calculator (math). Each tool is familiar and rehearsed; the assistant decides which to reach for, and you, the manager, decide which tools stay on the desk at all.

Mechanics

How it works

  • Pick capabilities aligned to user tasks.
  • Implement each as a safe tool with a clear description.
  • Expose them through the function-calling loop.
  • Feed results back so downstream reasoning uses them.
  • Govern access: read vs write, scoping, rate limits.

Tools on the desk.

Search
Code
Retrieve
Compute
Act
Real world

In production

  • Customer support assistants combine retrieval + read tools.
  • Data analysis products pair SQL + code rendering tools.
  • Dev tools add code search and file-read tools.
Guidelines

Best practices

  • Add tools for capabilities you actually want shipped.
  • Keep descriptions tight; fewer, sharper tools win.
  • Return concise, faithful results; never fabricate externally.
  • Log tool outcomes for eval and tuning.
Watch out

Common mistakes

  • Over-exposing tools 'just in case'.
  • Granting write tools casually.
  • Feeding back raw, huge tool outputs that bloat context.
Root cause analysis

Common issues

Error
Tool off while prompts reference it
Root cause

Registry vs tool list drift

Fix

Generate the model tool list from the registry.

Error
Tool results bloat tokens
Root cause

Returning raw payloads

Fix

Summarize or trim results before feeding back.

When things break

Debugging tips

  • Tool chosen rarely → description or value unclear.
  • Wrong tool chosen → overlapping descriptions; disambiguate.
  • Feature unused though built → no task triggers it; check UX.
Interviews

Interview checkpoint

Test yourself

Quick quiz

0/2
1

Which is NOT a typical tool category?

2

Tool results should always be fed back into the loop.

Go deeper

Official documentation

Tools (AI SDK)
docs