Command Palette

Search for a command to run...

Hectal
Phase 7Intermediate8 of 15 in LLM Engineering

Tools and Function Calling

How a model asks your code to act: the tool-call loop built by hand, schemas, validation, errors, parallel calls, dangerous tools, MCP and a safe tool runner.

A language model can only produce text. It cannot read today's weather, multiply two big numbers exactly or send an email. Tool calling (also called function calling) is the trick that fixes this: you describe functions to the model, the model answers with a request such as 'call get_weather for Pune', your program runs the function and sends the result back, and the model writes the final answer. The model never runs anything. Your code does, which is where all the safety work lives.

This phase builds the loop by hand with a scripted fake model that returns messages in the real OpenAI-compatible shape, so you see every field: the tools list in the request, the tool_calls in the reply (where arguments is a JSON string you must parse), and the tool message that carries the result back. Then it adds what production needs: good descriptions and schemas, validation of untrusted arguments, errors fed back so the model can recover, several calls in one turn, confirmation for dangerous actions, and a short, verified look at the Model Context Protocol (MCP).

Two labs let a real model call a tool and let you answer it, so you walk the whole loop with a real model once. The phase ends with the Playbook: a safe tool runner in Python, Java and JavaScript. The coming AI Agents course builds on exactly this loop.

0/9 · 0%
9 topics ~3 h 21 code blocks & diagrams
Start with the first topic
1
7.1

Why Models Need Tools

A model only produces text: it has no live data, it is unreliable at exact maths and it cannot act on the world. Tool calling lets the model ask for a function and lets your code run it, so the model supplies judgement and your code supplies facts and actions.

20 min 2 code practice

2
7.2

The Tool-Call Loop by Hand

The tool loop is: send the conversation and the tools, run any tool calls the model returns, append the results as tool messages, and ask again until the model answers in plain text. A step limit stops a model that never finishes.

22 min 3 code practice

3
7.3

Describing Tools Well

The model chooses and fills in tools using only their names, descriptions and JSON Schema parameters. Clear names, descriptions that say when to use the tool, and tight schemas (types, enums, required fields) are the main way to make tool use reliable.

22 min 3 code practice

4
7.4

Validating Arguments and Running Tools Safely

Tool arguments come from a model that users and documents can steer, so they are untrusted input. Parse them in a try block, check them against the schema, allow-list tool names and paths, and never pass them to eval, a shell or a string-built query.

21 min 2 code practice

5
7.5

Feeding Errors Back

A tool will fail: bad arguments, unknown records, outages. Catch every failure, turn it into a short tool message the model can read, and let the model correct itself, with a limit on repeats and without leaking internal details.

21 min 2 code practice

6
7.6

Several Tool Calls at Once

A model can return several tool calls in one reply. Each has its own id, they are independent of one another, so run them together to save time, and send back one tool message per call matched by id.

22 min 4 code practice

7
7.7

Dangerous Tools

Tools that change the world (refund, delete, send, deploy) turn a model mistake or a hostile instruction into a real incident. Separate read from write, ask a human before side effects, give each tool the least power it needs, make writes safe to repeat, and keep an audit log.

21 min 2 code practice

8
7.8

The Model Context Protocol in Brief

The Model Context Protocol (MCP) is an open standard that lets an AI application connect to tool servers through one common JSON-RPC protocol, instead of writing custom glue for every tool. It also covers resources and prompts. The same safety rules still apply.

21 min 1 code practice

9
7.9

Playbook: A Safe Tool Runner

One small class that does what this phase taught: a registry, schemas, argument validation, confirmation for writes, a timeout, errors fed back, an audit log, and a step-limited loop around it. Copy it, then plug the real model in.

24 min 2 code practice

Practise this phase

Hands-on exercises: write the code, run it, and press Check to have it tested automatically.

1

Parse a tool call

A model returned a tool call. Write parse_call(call) that returns a tuple (name, args): the function name and the arguments as a dict (the arguments field is a JSON string).

Intermediate
2

Validate arguments against a schema

Write validate(schema, args) that returns a list of problem strings (empty when the arguments are fine). schema has properties (each with a type of "string" or "integer") and required.

Intermediate
3

Write the tool loop

Write run_loop(script, registry, max_steps). script is a list of scripted assistant messages (the fake model's replies, one per step). registry maps a tool name to a function that takes the parsed arguments dict and returns a value.

Intermediate
4

Dispatch a call and feed errors back

Write dispatch(registry, call) that runs one tool call and returns the tool message dict {"role": "tool", "tool_call_id": <id>, "content": <JSON string>} (use json.dumps(value, separators=(",", ":"))).

Intermediate
5

Pair results with calls by id

Tools ran concurrently and their results arrived in any order. Write pair_by_id(calls, results). calls is a list of dicts with an id. results is a list of dicts {"tool_call_id": ..., "content": ...} in arrival order.

Intermediate
6

Confirm writes and keep an audit log

Write guarded_run(tool, args, confirm, audit). tool is a dict with name, risk ("read" or "write") and fn (takes args, returns a value). confirm(name, args) returns True or False. audit is a list.

Intermediate