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

Flashcard·Easy·4.0 · 0·~30s·Asked atElastic Kpmg Samsung·Relevant atLangChain OpenAI

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.

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

Concept explanation~2 min read

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

Tool call is one of those phrases that sounds self-explanatory and is constantly misunderstood. People hear it and picture the LLM directly calling a function, like a Python interpreter dispatching search('foo'). That is not what happens. The model never calls anything. A tool call is a description, and the actual execution happens in a separate piece of code that reads the description and acts on it.

Getting this mental model right is the difference between reasoning about agents correctly and being surprised when prompt injection turns into a real incident. This deep dive walks through what a tool call physically looks like on the wire, who reads it, who runs the function, how the result returns, and what the production realities are around parallelism, validation, and safety.

What the model actually emits

When an LLM "makes a tool call," the bytes that come out of the API are structured JSON. There is no syscall, no HTTP request to an external service, no function invocation. The model's output for that turn is a typed block that names a tool and supplies arguments.

The exact shape depends on the provider but the spirit is identical. Anthropic returns content blocks of type tool_use, each carrying an id, a name, and an input object holding the arguments. OpenAI returns a tool_calls array where each entry has an id, a type, and a function object with name and arguments (the arguments are a JSON string the SDK helpers parse for you). Google's Gemini and the open-source Model Context Protocol use their own variants of the same idea.

What all of these have in common is that the model has just produced text. Very structured, very specific text, with an id so the runtime can match it to the eventual result, but still just text. Nothing in the world has changed yet. The search has not happened. The file has not been read. The email has not been sent. There is only a description of a request.

Who actually runs the tool

How the result returns to the model

Parallel tool calls and malformed calls

Why the tool-call indirection is a safety boundary

Situations where this technique stops working.

2–4 min · Everything important, quickly.

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.

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?

Each tool call carries an id assigned by the model API. The runtime echoes that id in the tool_result message so the model can pair them across many parallel calls in the same turn.

2 more follow-ups an interviewer would ask next. Sign in to reveal them.

Red flags & common mistakes

The phrases 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 bullets to scan on the way to the call.

State that a tool call is a structured request, not an executed function.
Describe the JSON shape (name, arguments, call id) at a high level.

Primary sources. Browse if you want the original framing.