Module 4 — Tool Use (Function Calling) 🛠️

Goal of this module: Understand how an agent actually does things — by calling tools. We’ll cover what a tool is, how the model decides to use one, what “function calling” means, and how to design good tools. This is where the LLM stops just talking and starts acting.

4.1 The big idea: tools are the agent’s hands

From Module 2 you know the LLM is just a text predictor. By itself it can’t search the web, do reliable math, send an email, or read a file. Tools fix that.

Definition: A tool (also called a function) is a piece of code the agent can call to perform an action or fetch information it can’t do on its own.

Examples of tools:

web_search(query) — look something up online
calculator(expression) — do exact math
get_weather(city) — fetch current weather
send_email(to, subject, body) — send an email
run_python(code) — execute code
read_file(path) / write_file(path, text) — work with files
query_database(sql) — get data from a database

Analogy: The LLM is a brilliant brain in a jar. Tools are the robot arms, eyes, and phone you bolt onto the jar so it can affect the world.

4.2 How tool use works, step by step

Here’s the crucial part: the LLM does not run the tool itself. It can only output text. So the flow is a little dance between the model and the program around it (the “agent runtime”):

1. You tell the model what tools exist (name + what they do + inputs).
2. The model, when it wants a tool, OUTPUTS a request:
      "Call calculator with expression = '84 * 0.15'"
3. Your PROGRAM sees that request, actually runs the calculator,
   and gets the result: 12.6
4. Your program feeds the result BACK to the model as a tool message.
5. The model reads the result and continues (answer or another tool).

So the model asks to use a tool, and the surrounding code does it and reports back. This back-and-forth is the heartbeat of tool use.

   MODEL            RUNTIME (your code)         TOOL
     │  "call calc('84*0.15')" │                   │
     │ ───────────────────────►│                   │
     │                         │ ─── run it ──────►│
     │                         │ ◄── "12.6" ───────│
     │ ◄── "result: 12.6" ─────│                   │
     │  "The tip is $12.60"    │                   │

4.3 What is “function calling”?

Function calling (or tool calling) is the standard, modern way models request tools. Instead of the model writing messy text like “please search for cats,” it outputs a clean, structured request — usually JSON — that your program can reliably read.

A tool-call request looks like this:

{
  "tool": "get_weather",
  "arguments": { "city": "Paris" }
}

Your program reads that JSON, sees it should call get_weather("Paris"), runs it, and returns the result. The structured format is the key — it makes the model’s intentions machine-readable instead of fuzzy text.

Why JSON matters: Programs need exact, predictable input. “I think you should maybe check Paris weather” is hard to parse; {"city": "Paris"} is trivial to parse. Function calling = the model speaking the program’s language.

4.4 How the model knows which tools exist: the tool schema

You describe each tool to the model using a schema — a structured description of the tool’s name, purpose, and inputs. Here’s a beginner-friendly example:

{
  "name": "get_weather",
  "description": "Get the current weather for a city. Use this whenever the user asks about weather.",
  "parameters": {
    "city": {
      "type": "string",
      "description": "The city name, e.g. 'Paris' or 'New York'"
    }
  }
}

The model reads this and now knows:

What the tool is called (get_weather)
When to use it (the description — “whenever the user asks about weather”)
What inputs it needs (city, a string)

Pro tip: The description is HUGELY important. The model decides whether to use a tool based largely on its description. A vague description = the model uses the tool wrong or not at all. Write descriptions like you’re explaining to a smart new intern.

4.5 A complete example in pseudo-code

Let’s see the whole loop in simple Python-like pseudo-code (don’t worry about exact syntax — read it like a story):

# 1. Define a real tool (just a normal function)
def calculator(expression):
    return eval(expression)   # in real life, use a safe math parser!

# 2. Describe it to the model
tools = [{
    "name": "calculator",
    "description": "Evaluate a math expression. Use for any arithmetic.",
    "parameters": {"expression": {"type": "string"}}
}]

# 3. The agent loop
user_message = "What is 15% of 240?"
while True:
    response = model.chat(user_message, tools=tools)

    if response.wants_tool:                      # model asked for a tool
        name = response.tool_name                # "calculator"
        args = response.tool_args                # {"expression": "240 * 0.15"}
        result = calculator(**args)              # we run it → 36.0
        model.add_tool_result(result)            # feed 36.0 back
        continue                                 # loop again
    else:
        print(response.text)                     # final answer
        break

Read it as: the model asks → we run the function → we hand back the result → repeat until the model is done. That’s tool use in a nutshell.

4.6 Designing good tools (the expert part)

Whether a tool-using agent succeeds depends heavily on how you design the tools. Here are the rules pros follow:

(a) One tool, one clear job

A tool should do one thing well. search_flights is good. do_everything_travel is bad — the model won’t know how to use it.

(b) Crystal-clear descriptions

Tell the model exactly when to use the tool and what each input means. Ambiguity causes misuse.

(c) Simple, well-named inputs

city (string) is easy. A nested blob of 12 optional fields is hard. Keep inputs minimal.

(d) Helpful, structured outputs

Return results the model can easily read. Instead of a giant dump, return the relevant fields. Good: {"temp": "18°C", "condition": "rainy"}.

(e) Clear, friendly errors

When a tool fails, return a message the model can act on: "Error: city not found. Check spelling." This lets the agent recover and re-plan (Module 3), instead of crashing.

(f) Make dangerous tools require confirmation

Tools that spend money, delete data, or send messages should be designed so a human approves them first. (More in Module 11.)

4.7 Common tool categories

As you build agents, you’ll reach for these families of tools:

Information tools: web search, database queries, document lookup (read-only — safe).
Computation tools: calculator, code execution, data analysis.
Action tools: send email, create calendar event, post to Slack, make a purchase (these change the world — handle with care).
File tools: read, write, edit files.
Memory tools: save and retrieve facts (the bridge to Module 6).

A rule of thumb: read-only tools are low-risk; world-changing tools are high-risk and need guardrails.

4.8 What is MCP? (a term you’ll hear)

MCP = Model Context Protocol. It’s a recent, popular standard for connecting agents to tools and data sources. Instead of every developer hand-coding every tool, MCP lets tools be packaged as reusable “servers” that any compatible agent can plug into — like USB for AI tools.

You don’t need to master MCP as a beginner. Just know:

MCP is a standard way to give an agent a set of tools (e.g., a “GitHub MCP server” gives an agent GitHub tools; a “Slack MCP server” gives it Slack tools). It saves you from reinventing the wheel.

4.9 Common mistakes with tools

Mistake	Result	Fix
Vague tool description	Model misuses or ignores the tool	Write a precise, example-rich description
Too many tools at once	Model gets confused, picks wrong one	Give only the tools the task needs
Tool returns a giant blob	Wastes context, confuses model	Return only the relevant fields
No error handling	Agent crashes on first hiccup	Return clear error messages the agent can react to
Unsafe action tools	Agent sends bad emails / deletes data	Require confirmation for risky actions
Trusting LLM math	Wrong numbers	Always route math through a calculator tool

4.10 Check yourself ✅

Why can’t the LLM run a tool by itself?
What is “function calling” and why is JSON involved?
What’s the single most important part of a tool’s schema for getting the model to use it correctly?
Why should risky tools (like sending money) be designed differently from read-only tools?

Answers

The LLM only outputs text. It can ask to use a tool, but the surrounding program must actually run the tool and feed the result back.
Function calling is the model outputting a structured (usually JSON) request to use a tool. JSON makes the request machine-readable so the program can reliably run it.
The description — it tells the model when and how to use the tool.
Risky tools change the real world (spend money, delete data); they should require human confirmation, while read-only tools are safe to run automatically.

4.11 Summary

Tools are the agent’s hands — code it can call to act or fetch info the LLM can’t.
The model asks for a tool (via structured function calling); your program runs it and feeds the result back. Repeat.
Tools are described with a schema (name, description, inputs); the description is what makes or breaks correct use.
Design tools to be single-purpose, clearly described, simple in/out, with friendly errors, and require confirmation for risky actions.
MCP is a standard way to package and share tools.

Next up: Module 5 — Multi-Step Reasoning. We’ve seen planning and tools separately; now let’s see the famous ReAct loop that fuses reasoning and acting into one powerful pattern. 👉 05_Multi_Step_Reasoning.md