Main area
Agency
ki-konzepte

Function Calling / Tool Use

Redaktion ·

What Function Calling actually is

Function Calling — often called Tool Use, and they mean the same thing — just comes down to this: you hand the language model a list of tools it’s allowed to use. A weather lookup, a database search, a calculator, a mail sender. The model doesn’t write these tools itself, and it doesn’t run them either. It only tells you: “I’d like to use the tool get_weather now, for the city Berlin.” The actual call happens in your code.

That sounds like a small detail, but it’s the decisive step. Without tools, an LLM can only produce text — it knows nothing about the world past its training cutoff, can’t look anything up, can’t trigger anything. With tools, the text generator turns into something that can act. And that’s exactly where it clicks: the model decides what should be done, your system actually does it.

The flow in three steps

The whole mechanism is a small loop between your code and the model. It always looks the same:

  1. You describe the tools. With every call, you send the model not just the user’s question but also a list of available tools — each with a name, a short description, and its parameters. That description is a so-called JSON schema, meaning a structured statement of which fields the tool expects and what type they are.
  2. The model picks. Instead of a text reply, the model now returns a structured instruction: it wants to call tool X, with these arguments. For example get_weather({ city: "Berlin", unit: "celsius" }). The model isn’t guessing here — it fills the fields from the schema you gave it.
  3. You execute and return. Your code calls the real function, gets the result, and sends it back into the conversation as a new message. The model reads that result and turns it into the final answer — or immediately asks for the next tool.

Here’s the part most people trip over first: the model never executes anything itself. It’s a pure suggestion that your system can accept or reject. The control stays with you.

Why the JSON schema matters so much

The tool description isn’t decoration, it’s the heart of the thing. The model decides entirely from the name and description whether and when to reach for a tool. If a function is named something vague like func1 and has no description, the model guesses — and often guesses wrong. But if it clearly reads “Gets the current weather forecast for a given city,” it makes the right choice far more reliably.

The schema also defines the parameters: which fields exist, what type they are, which are required. That’s exactly what the model sticks to when it fills in the arguments. Good tool definitions are therefore half the battle — a fuzzy description produces more bad calls than a weak model does.

The building block of every agent orchestration

Function Calling is the point where a chat model becomes an agent. An AI agent is at its core nothing but this loop, repeated: the model picks a tool, your system runs it, the result goes back, the model picks the next one — until the task is done. Without Tool Use there would be no agents, only text replies.

Multi-agent orchestration and pipeline frameworks build directly on this too. Every single agent in such a system uses Function Calling to reach its tools. And the related approach of RAG works the same way — the search across your knowledge base is simply offered as a tool that the model pulls when it needs to.

The major providers all support this, with slightly different notation: OpenAI through a tools parameter, Anthropic through tool_use blocks, Google through function_declarations. The principle is the same everywhere — you describe, the model picks, you execute. If you want to go deeper into the API mechanics, the entry on working with the LLM API is the right starting point.

Where it gets tricky in practice

Function Calling is powerful, but it doesn’t run itself. Three things tend to go wrong first. One: the model doesn’t call a tool at all, or calls the wrong one — almost always a description problem, not a model problem. Two: it fills an argument with nonsense, like a city nobody asked about. The fix is a schema with clear required fields and a check in your code before you actually run the call.

Three, and this one is security-relevant: a tool result lands back in the context and can itself contain instructions. If a tool pulls foreign text from the web, a hidden command can sit inside it that the model dutifully follows. So the rule is: tool results are data, not commands — how you guard against that is covered in the entry on prompt security. Never blindly run what the model suggests, especially when a tool does something irreversible like deleting or sending.

FAQ

Does the LLM call the function itself?
No. The model only returns a structured suggestion — which tool, with which arguments. Your code makes the real call. You can accept the suggestion, check it, or reject it; the control stays fully with you.
What is the difference between Function Calling and Tool Use?
None at the core — they are two names for the same thing. OpenAI coined "Function Calling", Anthropic says "Tool Use". Both mean: give the model tools it can request through a structured instruction.
Why do I need a JSON schema for the tools?
The schema tells the model which tools exist, when to use them, and which parameters they expect. The model decides purely from name and description — so a clear schema is the biggest lever for reliable calls.
What does Function Calling have to do with AI agents?
Function Calling is the building block. An agent is at its core this loop, repeated: pick a tool, run it, return the result, pick the next. Without Tool Use a model can only produce text, not act.
What security risks does Tool Use bring?
Mainly two: wrong or invented arguments, and instructions that enter the context through a tool result (prompt injection). Treat tool results as data, not commands, and check every call that does something irreversible.

Themenuebersicht

KI-KonzepteAgentenAPI-Nutzung