Function Calling vs. Tool Use: Begriffsklärung und Implementierungen

Function Calling und Tool Use bezeichnen im Kern dieselbe Fähigkeit: Ein Large Language Model gibt an einer bestimmten Stelle nicht Fließtext aus, sondern einen strukturierten, schema-konformen Aufruf einer extern definierten Funktion – inklusive der passenden Argumente. OpenAI führte den Begriff „Function Calling" ein, Anthropic spricht von „Tool Use". Technisch sind beide JSON-Schema-basiert und nahezu deckungsgleich. Die Unterschiede liegen in der Benennung von Schema-Feldern und in einigen API-Mechaniken – nicht im Grundprinzip.

Dieser Artikel ist Teil des Clusters rund um die Pillar „LLM-Grundlagen für Agenten" und vertieft, was im Schwester-Beitrag zu den Tool-Calling-Grundlagen angerissen wird. Alle technischen Angaben beziehen sich auf den Stand 2026.

• Synonym mit Nuance: „Tool Use" ist der etwas breitere Begriff, weil ein Tool bei Anthropic auch ein serverseitiger Dienst (Web-Suche, Code-Ausführung) oder ein MCP-Server sein kann. „Function Calling" meint im engeren Sinn den Aufruf einer reinen Funktion.
• Das Modell führt nichts aus: Es liefert nur den Aufruf. Ihr Code validiert die Argumente, führt sie aus und gibt das Ergebnis zurück. Erst dann formuliert das LLM die Antwort.
• Wichtigster Implementierungsunterschied: OpenAI nutzt im Tool-Schema das Feld parameters, Anthropic input_schema. Beide bauen darunter auf JSON Schema auf.

Wie ein LLM strukturierte Tool-Aufrufe erzeugt

Der Mechanismus ist in beiden Ökosystemen identisch aufgebaut. Sie übergeben dem Modell eine Liste von Tool-Definitionen zusätzlich zur eigentlichen Nutzeranfrage. Jede Definition beschreibt einen Namen, eine Beschreibung (wann das Tool zu nutzen ist und wann nicht) und ein Eingabe-Schema mit typisierten, teils erforderlichen Parametern.

Anthropic injiziert die Tool-Definitionen über einen API-internen Wrapper-Prompt in den Kontext – in etwa nach folgendem Muster:

```
In this environment you have access to a set of tools you can use to answer the user's question.
{{ FORMATTING INSTRUCTIONS }}
String and scalar parameters should be specified as is, while lists and objects should use JSON format.
Here are the functions available in JSONSchema format:
{{ TOOL DEFINITIONS IN JSON SCHEMA }}
{{ USER SYSTEM PROMPT }}
{{ TOOL CONFIGURATION }}
```

Daraus folgt eine oft übersehene wirtschaftliche Konsequenz: Jedes Tool kostet als Schema dauerhaft Tokens (Größenordnung typischerweise rund 100–300 pro Tool, je nach Schema-Komplexität), weil das Modell die Definitionen in jedem Inference-Turn mitliest. Ein Katalog mit zehn Tools liegt damit grob bei 1.000–3.000 Tokens pro Aufruf. Bei 100.000 Aufrufen monatlich sind das 100–300 Millionen Tokens reine Schema-Last – wirtschaftlich nur über Prompt Caching darstellbar.

Im 12-Factor-Agents-Framing von Dex Horthy gilt deshalb der Leitsatz: Tools sind nur strukturierte Outputs. Was das LLM produziert, ist schema-konformes JSON; was ausgeführt wird, ist deterministischer Code, den Sie selbst besitzen und kontrollieren.

Schema-Definition: die gemeinsame Sprache JSON Schema

Beide Anbieter setzen unter der Haube auf JSON Schema als Lingua franca. Code-first-Werkzeuge wie Pydantic (Python) oder Zod (TypeScript) generieren dieses Schema automatisch aus Typdefinitionen.

Eine belastbare Tool-Definition lebt von ihrer Beschreibung – auf Tool- wie auf Feldebene. Ein Parameter recipient_email mit der Beschreibung „RFC-5321-konforme E-Mail-Adresse des Empfängers; muss einem bestehenden Kundendatensatz entsprechen" ist deutlich zuverlässiger als dasselbe Feld ohne Beschreibung. Als belastbare Praxisregel gilt: Die Beschreibung sollte nicht nur sagen, was ein Tool tut, sondern vor allem wann es aufgerufen werden soll und wie die Argumente zu konstruieren sind. Sie ist der dauerhafte Schnittstellenvertrag zwischen Modell und API – und auf den jüngeren, beim Tool-Greifen eher zurückhaltenden Modellen messbar wirksamer als eine reine Funktionsbeschreibung.

DACH-spezifischer Hinweis: Tool-Namen und Parameter-Bezeichner in Englisch halten (Interoperabilität mit Bibliotheken, Logs, OpenAPI), die Beschreibungen aber in der Laufzeitsprache des Agenten verfassen. Gemischtsprachige Kataloge funktionieren mit Frontier-Modellen, sind aber eine vermeidbare Quelle für Inkonsistenzen.

Implementierungsunterschiede: OpenAI vs. Anthropic

Die folgende Tabelle fasst die praktisch relevanten Unterschiede zusammen (Stand 2026). Wichtig: Die Gemeinsamkeiten überwiegen. In Produktion verwenden viele Teams eine Abstraktionsschicht (etwa LiteLLM oder das Vercel AI SDK), um die Feldnamen-Unterschiede zu kapseln.

Bei Anthropic stehen für tool_choice vier Modi zur Verfügung: {"type": "auto"} (Modell entscheidet, Default), {"type": "any"} (mindestens ein Tool muss genutzt werden), {"type": "tool", "name": "..."} (ein bestimmtes Tool wird erzwungen) und {"type": "none"} (keine Tools). Jeder dieser Werte kann zusätzlich disable_parallel_tool_use: true tragen, um höchstens einen Aufruf pro Antwort zu erzwingen.

Parallele Tool-Calls und der Agent-Loop

Frontier-Modelle können in einer einzigen Antwort mehrere Tool-Aufrufe gleichzeitig anfordern – etwa „Profil abrufen", „letzte Bestellungen laden" und „Lagerbestand prüfen" parallel. Das reduziert Round-Trips und Latenz spürbar. Ihre Harness muss alle angeforderten Aufrufe abarbeiten und die Ergebnisse gesammelt in einer einzigen Folge-Nachricht zurückgeben.

Der manuelle Agent-Loop bei Anthropic läuft nach diesem Muster: API aufrufen, Antwort prüfen – solange stop_reason gleich tool_use ist, werden die Tool-Use-Blöcke ausgeführt, die vollständige Modellantwort sowie die tool_result-Blöcke (jeweils mit passender tool_use_id) an die Nachrichtenhistorie angehängt und der nächste API-Aufruf gestartet. Der Loop endet, wenn stop_reason gleich end_turn ist. Die offiziellen SDKs bieten alternativ einen automatischen „Tool Runner", der diesen Loop kapselt; den manuellen Loop nutzt man für Feingranularität, etwa Freigabe-Gates oder eigenes Logging.

Fehlerbehandlung: robust statt fragil

Die zweithäufigste Ursache für instabile Produktions-Agenten – nach mehrdeutigen Tool-Definitionen – ist schlechte Fehlerbehandlung. Drei Prinzipien gelten branchenübergreifend:

• Fehler als strukturiertes Tool-Result zurückgeben, nicht als Exception werfen, die den Loop abbricht. Ein verdichtetes { "error": "code", "message": "...", "retry_after_seconds": 30 } lässt das Modell entscheiden, ob es die Argumente korrigiert, eine andere Strategie wählt oder eskaliert. Bei Anthropic setzen Sie zusätzlich is_error: true im tool_result-Block.
• Fehlerkontext kompakt halten. Keine rohen Stack-Traces ins Kontextfenster kippen – das verschmutzt den Kontext und verschlechtert die Folgeantworten. Verdichten Sie.
• Retries deckeln. Drei Versuche sind typisch. Differenzieren Sie nach Fehlertyp: Tool-Fehler (500/Timeout) mit Backoff erneut versuchen, Validierungsfehler (400) mit angepassten Argumenten, Permission-Fehler (403) ohne Retry an den Menschen eskalieren, Rate-Limits (429) mit Backoff und gegebenenfalls Modell-Wechsel.

Ein hartnäckiges Anti-Pattern ist die stille Fehlerunterdrückung, bei der Tool-Aufrufe fehlschlagen, der Agent aber weiterläuft, als sei alles in Ordnung. Geben Sie Fehler stets explizit an das Modell zurück.

Eine zweite, praktische Regel: Tool-Inputs immer mit einem JSON-Parser auslesen, nie per String-Matching auf dem serialisierten Input. Die Modelle der aktuellen Generation (etwa Opus 4.6, 4.7 und 4.8 sowie Sonnet 4.6, Stand 2026) können das JSON-Escaping zwischen Versionen unterschiedlich handhaben – Unicode- oder Slash-Escaping etwa. Wer roh string-matcht, baut sich einen schwer auffindbaren Bug.

Konkretes Pseudocode-Beispiel

Das folgende Pseudocode-Beispiel zeigt eine Tool-Definition und einen manuellen Loop in der Anthropic-Schreibweise. Der Unterschied zu OpenAI besteht im Wesentlichen darin, dass input_schema dort parameters hieße.

```
tool = {
"name": "fetch_recent_orders",
"description": "Lädt die letzten Bestellungen eines Kunden. "
"Nutzen, wenn der Nutzer nach Bestellhistorie, Status "
"oder Lieferungen fragt. NICHT nutzen für reine "
"Produktsuche – dafür search_products verwenden. "
"Returns: Liste von {id, total, status, items}.",
"input_schema": {
"type": "object",
"properties": {
"user_id": {"type": "string", "description": "Interne Kunden-ID"},
"limit": {"type": "integer", "description": "Max. Anzahl (Default 10)"}
},
"required": ["user_id"]
}
}

messages = [{"role": "user", "content": "Wo ist meine letzte Bestellung?"}]

while True:
response = client.messages.create(
model="claude-opus-4-8", # Stand 2026
max_tokens=1024,
tools=[tool],
messages=messages,
)
if response.stop_reason != "tool_use":
break # end_turn -> fertig

messages.append({"role": "assistant", "content": response.content})
results = []
for block in response.content:
if block.type == "tool_use": # ggf. mehrere -> parallel
try:
data = run_tool(block.name, block.input) # eigener Code
results.append({
"type": "tool_result",
"tool_use_id": block.id,
"content": to_json(data),
})
except ToolError as e:
results.append({
"type": "tool_result",
"tool_use_id": block.id,
"content": str(e),
"is_error": True,
})
messages.append({"role": "user", "content": results})
```

Rechenbeispiel zur Tool-Last: Angenommen, dieser Agent läuft mit fünf Tools à ~200 Tokens Schema (1.000 Tokens) plus 800 Tokens System-Prompt. Bei 100.000 Aufrufen pro Monat fallen allein für den stabilen Präfix rund 180 Millionen Input-Tokens an. Über Anthropics Prompt Caching kostet ein Cache-Read nur etwa 10 Prozent der Standard-Input-Rate (Stand 2026: z. B. rund 0,30 statt 3,00 US-Dollar pro Mio. Tokens bei Sonnet 4.6) – vorausgesetzt, der Tool-Katalog bleibt stabil. Jede Änderung an Tool-Definitionen, auch nur der Reihenfolge, invalidiert den Cache vollständig. Daraus folgt das Produktions-Pattern: Tool-Kataloge in geplanten Releases ausrollen, keine Hotfixes an Tool-Defs.

Wie viele Tools – und die Überlappungsfalle

Die Tool-Auswahlgenauigkeit skaliert nicht beliebig. Bewährt hat sich, nur eine kleine Kernmenge dauerhaft zu laden und weitere Tools dynamisch über ein Tool-Search-Tool nachzuladen – das hält den Fixkontext klein und schont den Cache, weil Schemas angehängt statt ausgetauscht werden. Der eigentliche Engpass ist jedoch nicht die reine Anzahl, sondern die Überlappung: Schon eine Handvoll klar abgegrenzter Tools lässt sich sauber managen, während wenige überlappende ein Modell zuverlässig ins Raten bringen.

Zwei Tools, die plausibel dieselbe Anfrage beantworten könnten – etwa search_documents und search_knowledge_base –, sind das Problem, das kein noch so guter Prompt löst. Bei „Finde Informationen zu X" rät das Modell. Die wirksamste, meist vergessene Gegenmaßnahme ist die Wann-nicht-nutzen-Klausel in jeder Beschreibung. Als öffentliche Benchmark-Referenz für die Auswahlgenauigkeit dient die Berkeley Function-Calling Leaderboard (BFCL); deren Werte schwanken jedoch und sollten gegen das eigene Eval-Set rebenchmarkt werden, nicht gegen einen Marketing-Blogpost.

Für Agenturen und B2B-Entscheider

Function Calling beziehungsweise Tool Use ist die Brücke zwischen Sprachmodell und Ihren realen Systemen – CRM, Buchhaltung, Versand, Wissensdatenbank. Die Begriffsverwirrung ist harmlos; die Implementierungsdisziplin ist es nicht. Ob ein Agent in Produktion zuverlässig läuft, entscheidet sich an sauber abgegrenzten Tool-Definitionen, robuster Fehlerbehandlung als strukturierte Results, kontrollierten Termination-Bedingungen und einer cache-bewussten Katalog-Strategie – nicht an der Wahl zwischen OpenAI und Anthropic.

Als Wiener Agentur mit Fokus auf KI-Agenten begleiten wir DACH-Unternehmen vom Tool-Schema-Design über die Anbieter-Abstraktion bis zum produktionsreifen, auditierbaren Agent-Loop. Wenn Sie strukturierte Tool-Aufrufe verlässlich in Ihre Geschäftsprozesse einbinden wollen, sprechen Sie uns an.