Flashcard: what does it mean when an LLM 'makes a tool call'?

Flashcard·Easy·4.0 · 0·~30s

Attempt it

Your answer

**A tool call** is a special kind of response from the LLM. Most of the time the model returns plain text: a sentence, a paragraph, a final answer. A tool call is what comes out instead when the model decides it needs to use a tool. Instead of words for the user, the model emits a small JSON-shaped block that says which tool to use and what arguments to pass. For example, if the model is solving a math problem and needs the calculator tool, it emits something like `{ "tool": "calculator", "args": { "expression": "3.14 * 17^2" } }`. That JSON is the tool call. The model has not actually computed anything. It has written down a request. The runtime around the model is what makes the request real. It sees the structured block, looks up the calculator function in its tool registry, runs it with the given arguments, captures the result, and feeds it back to the model on the next turn as a new observation. The model never touches the calculator directly. It only describes the calculation it wants done. This indirection is on purpose. The model is non-deterministic and untrusted. By making it emit a structured request the runtime has to execute, you get a clean place for permission checks, validation, and logging.

**A tool call** is a structured output the model emits in place of plain text, naming a specific tool and the arguments to pass. The runtime parses that structured block, actually executes the tool, and feeds the result back as the next observation. The model itself does not run any code. At the API level, both Anthropic and OpenAI return a tool-use block as a typed message in the response. It contains the tool name, the call id (for matching the response later), and a JSON object of arguments. Your code receives this block and is responsible for everything that happens next: parsing it, validating the arguments against the tool schema, executing the corresponding function in trusted code, and packaging the return value as a tool-result message for the next API call. This matters because it is the cleanest boundary in the whole agent stack. The model is non-deterministic, and under prompt injection its output can be steered by content it just read from a tool result. So you never want the model's text to directly cause an HTTP call, a file write, or a shell command. The tool call indirection forces every effect to flow through code you wrote and can audit. Permission checks, argument validation, retries, idempotency keys, and observability all live in the runtime, not in the model. In the loop, a tool call is the signal to keep going. The runtime detects a tool-use block and executes the tool, then calls the model again with the result. If the model emits no tool call and returns plain text, the runtime treats that as a final answer and exits.

Quick reference

TL;DR

A tool call is the model emitting structured JSON naming a tool and arguments instead of returning final text; the runtime parses and executes it, then feeds the result back.

Memory aid

Easy to grasp

Imagine asking a friend to fix your laptop. Instead of fixing it themselves, they hand you a sticky note that says 'open the lid, press F2 at boot.' They have not done anything yet. They have just written down very specific instructions on a small piece of paper. You take the note, follow the instructions, and tell them what happened. Then they write another note. A tool call is exactly that sticky note. The language model writes a tiny, very structured note that says 'please call the search tool with this query' or 'please run this Python code.' Nothing has actually run yet. The runtime around the model takes the note, follows the instructions, and writes back what happened so the model can decide the next step.

Key concepts

Tool Call Function Calling Tool Use

Detailed answer & concept explanation

~6 min read

Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.

Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example.

Quick scan · 2–4 min

Everything important, quickly.

5 min: define a tool call as structured JSON output, walk through what the API returns (name, id, arguments), explain the runtime side (parse, validate, execute, return), contrast against a final-answer response, and note parallel calls and validation-error recovery.

Real-world examples

Real products, models, and research that use this idea.

Anthropic's API returns a tool_use block (type, id, name, input) when Claude decides to use a tool; your code executes the tool and sends back a tool_result block with the matching id.
OpenAI's responses API returns a tool_calls array; the SDK helpers parse the JSON arguments, but it is still your code that runs the actual function.
Cursor's agent receives a tool_use for edit_file with a path and diff; the editor applies the diff and feeds back the new file content as the observation.
LangGraph's tool node consumes a parsed tool call from the model node, dispatches to the registered function, and emits the observation as the next state update.

Interviewer follow-ups

What an interviewer would ask next. Try answering before peeking at the approach.

QHow does the runtime match a tool call request to the tool result it sends back?

QWhat happens if the model emits arguments that fail schema validation?

QHow do parallel tool calls change the loop topology?

Don't say this

Red flags and common mistakes that signal junior thinking. Click to expand.

Most common mistake

Thinking the LLM directly invokes the function. The model only emits a structured request; an HTTP call, a file write, or a code execution only happens when the runtime parses that request and acts on it.

60-second cheat sheet

The night-before-the-interview bullets. Scan these on the way to the call.

References

Primary sources. Skim if you want the original framing.