Tool calling lets a language model trigger real actions — by emitting structured data, not by running code itself. You hand the model a set of tools, each described by a schema; it answers a request by choosing a tool and filling in the arguments as JSON. Your code runs the actual function and feeds the result back.

Where you meet it

• AI assistants that fetch live data — weather, prices, your calendar — instead of guessing.
• Agents that act: send an email, query a database, hit an API, run code.
• The same mechanism behind web_search, MCP servers, and most "the model used a tool" features.

What it does

It turns the model from a text generator into something closer to a typed function caller. Instead of producing prose you have to parse, the model returns a structured request whose shape you defined in advance. The model decides what to call; your code stays in control of what actually happens.

The model never runs anything — it only proposes a structured call. Whether it executes is entirely your code's decision.

How it works

You describe each tool to the model: a name, a plain-language description of when to use it, and a parameter schema (JSON Schema) listing the arguments and their types. A weather tool might look like this:

{
  "name": "get_weather",
  "description": "Get current weather for a city",
  "input_schema": {
    "type": "object",
    "properties": {
      "city": { "type": "string", "description": "City name, e.g. Tokyo" }
    },
    "required": ["city"]
  }
}

The loop then runs in five moves:

1. The user asks something the model can't answer from training alone ("weather in Tokyo right now?").
2. Instead of replying, the model emits a tool call — the tool name plus arguments as JSON: { "name": "get_weather", "input": { "city": "Tokyo" } }.
3. Your code reads that, runs the real get_weather("Tokyo"), and gets back { "temp_c": 18, "condition": "rain" }.
4. You append that result to the conversation as a tool message, so it flows back into the context the model reads.
5. The model now has the fact and writes the final answer in natural language.

The key idea: the model never executes anything. It only proposes a structured call. Whether it really runs — and with what permissions — is entirely your decision.

Watch out

Go deeper

• Anthropic — Tool use with Claude (overview)
• Anthropic — How tool use works (the loop & the contract)
• OpenAI — Function calling guide (strict mode, validation)
• JSON Schema — what it is and how it validates structure

Tool Calling lässt ein Sprachmodell echte Aktionen auslösen — durch strukturierte Daten, nicht indem es selbst Code ausführt. Du gibst dem Modell eine Reihe von Tools, jedes per Schema beschrieben; es beantwortet eine Anfrage, indem es ein Tool wählt und die Argumente als JSON füllt. Dein Code führt die eigentliche Funktion aus und speist das Ergebnis zurück.

Wo es vorkommt

• KI-Assistenten, die Live-Daten holen — Wetter, Preise, deinen Kalender — statt zu raten.
• Agenten, die handeln: eine Mail senden, eine Datenbank abfragen, eine API aufrufen, Code ausführen.
• Derselbe Mechanismus hinter web_search, MCP-Servern und den meisten "das Modell hat ein Tool genutzt"-Features.

Was es tut

Es verwandelt das Modell von einem Textgenerator in etwas, das eher einem typisierten Funktionsaufruf gleicht. Statt Prosa, die du parsen musst, liefert das Modell eine strukturierte Anfrage, deren Form du vorab definiert hast. Das Modell entscheidet, was aufgerufen wird; dein Code behält die Kontrolle über was wirklich passiert.

Das Modell führt nie etwas aus — es schlägt nur einen strukturierten Call vor. Ob er läuft, entscheidet allein dein Code.

Wie es funktioniert

Du beschreibst dem Modell jedes Tool: einen Namen, eine Beschreibung in Klartext (wann es zu nutzen ist) und ein Parameter-Schema (JSON Schema) mit den Argumenten und ihren Typen. Ein Wetter-Tool sieht etwa so aus:

{
  "name": "get_weather",
  "description": "Aktuelles Wetter für eine Stadt holen",
  "input_schema": {
    "type": "object",
    "properties": {
      "city": { "type": "string", "description": "Stadtname, z. B. Tokio" }
    },
    "required": ["city"]
  }
}

Die Schleife läuft dann in fünf Schritten:

1. Der User fragt etwas, das das Modell nicht aus dem Training beantworten kann ("Wetter in Tokio gerade?").
2. Statt zu antworten, gibt das Modell einen Tool-Call aus — Tool-Name plus Argumente als JSON: { "name": "get_weather", "input": { "city": "Tokyo" } }.
3. Dein Code liest das, führt das echte get_weather("Tokyo") aus und erhält { "temp_c": 18, "condition": "rain" }.
4. Du hängst dieses Ergebnis als Tool-Nachricht an die Konversation — es fließt zurück in den Kontext, den das Modell liest.
5. Das Modell hat nun den Fakt und formuliert die finale Antwort in natürlicher Sprache.

Der Kern: das Modell führt nichts aus. Es schlägt nur einen strukturierten Aufruf vor. Ob er wirklich läuft — und mit welchen Berechtigungen — ist allein deine Entscheidung.

Worauf achten

Mehr dazu

• Anthropic — Tool use with Claude (Überblick)
• Anthropic — How tool use works (die Schleife & der Vertrag)
• OpenAI — Function calling guide (Strict-Mode, Validierung)
• JSON Schema — was es ist und wie es Struktur validiert