Phase 03 · Talking to models: the API layer Core

Tool use / function calling

Letting the model request actions - search, calculate, query a database - by emitting structured calls to functions you define and execute.

In plain terms

The model is a brilliant advisor locked in a room with no phone and no internet. Tool use slides a phone under the door: you tell it 'you can dial weather(city) or search(query)', and instead of guessing, it says 'call weather("Pune") for me', you run it, hand back the result, and it answers with real data.

Why it matters

Models can't know today's stock price, your database contents, or the result of 7,839 x 4,521 reliably - knowledge is frozen at training time and arithmetic isn't their skill. Tools bolt real-time information and real actions onto pure language ability. This is the atom that agents are built from.

How it works

1) You send tool definitions (name, description, JSON-schema parameters) with your request. 2) The model, if it decides a tool helps, responds with a structured call: {name: "get_weather", input: {city: "Pune"}}. 3) Your code executes the real function - the model never runs anything itself. 4) You send the result back as a new message. 5) The model produces the final answer. The loop can repeat with multiple tools.

When you use it

Live data (weather, prices, search), private data (your DB), precise operations (math, code execution), and side effects (send email, create ticket). If the answer must be true right now, you need a tool.

Common mistakes

  • Vague tool descriptions - the description is the model's ONLY manual; 'search(q)' gets misused, 'searches product catalog by keyword, returns top 5 with prices' gets used well.
  • Letting the model's arguments hit real systems unvalidated (it can and will produce odd values).
  • Twenty overlapping tools - the model dithers; fewer, sharper tools win.

Best practices

  • Write tool descriptions like documentation for a smart intern: purpose, when to use, when NOT to.
  • Validate every argument; make destructive tools require confirmation.
  • Return errors from tools as informative text - models actually read and recover from good error messages.

Try it yourself

Define a calculator(expression) tool, ask the model 'What is 12.5% of 8,742?', watch it emit a call, execute it with Python's eval (toy only!), return the result, and get the final sentence. That round trip is the heart of all agents.

Resources