Tool Calling: Wie AI Agents Werkzeuge nutzen

Was ist Tool Calling?

Tool Calling (auch Function Calling oder Tool-Use) ist die Kernfähigkeit, mit der ein AI Agent über das reine Textgenerieren hinausgeht. Das LLM erhält maschinenlesbare Beschreibungen von Werkzeugen – Funktionen, APIs, Datenquellen – und erzeugt bei Bedarf einen strukturierten Aufruf mit Parametern, den die umgebende Anwendung ausführt. Das Ergebnis fließt als Beobachtung zurück ins Modell, das daraufhin den nächsten Schritt plant. So wird das LLM vom Text-Generator zum handelnden Akteur.

Die drei Kernantworten vorab:

• Was passiert technisch? Das Modell gibt nicht Fließtext, sondern einen strukturierten Aufruf zurück: einen Function-Namen plus Argumente im JSON-Format. Die Anwendung führt diesen Aufruf aus und reicht das Ergebnis ins Modell zurück.
• Wer ruft eigentlich auf? Nicht das LLM selbst. Das Modell schlägt einen Aufruf vor; die tatsächliche Ausführung – inklusive Rechteprüfung und Validierung – liegt im umgebenden Code. Diese Trennung ist die Grundlage jeder Sicherheitsarchitektur.
• Warum ist das die Kernfähigkeit von Agenten? Ohne Tool-Use bleibt ein LLM ein Berater, der nur reden kann. Erst Tool Calling macht aus der Reasoning-Engine einen Agenten, der wahrnimmt, plant, handelt und beobachtet – den vollen Loop Perceive → Reason → Act → Observe.

Ein konkretes Beispiel: Verfügbarkeit prüfen und Termin buchen

Angenommen, ein Agent soll einem Kunden einen Beratungstermin buchen. Dem Modell werden zwei Tools bereitgestellt, jeweils mit Name, Beschreibung und einem Parameter-Schema:

1. get_availability(date: string) – gibt freie Slots für ein Datum zurück.
2. book_appointment(slot_id: string, customer_email: string) – bucht einen Slot.

Der Ablauf:

1. Reason: Der Nutzer schreibt „Hätten Sie nächsten Dienstag vormittags Zeit?“. Das Modell erkennt, dass es zunächst die Verfügbarkeit braucht.
2. Act: Statt einer Textantwort gibt das Modell einen strukturierten Aufruf zurück: get_availability(date: "2026-06-16").
3. Execute: Die Anwendung – nicht das Modell – ruft die echte Kalender-API auf und erhält zwei freie Slots.
4. Observe: Das Ergebnis (["09:00", "10:30"]) wird als Beobachtung zurück ins Modell gegeben.
5. Loop: Das Modell formuliert eine Rückfrage oder ruft – nach Bestätigung – book_appointment(...) auf.

Wichtig: Der schreibende Schritt (book_appointment) ist irreversibel im Wirkungssinn. Genau hier gehört ein Human-in-the-Loop- oder Bestätigungsschritt hin, bevor der Agent die Aktion ausführt.

Die Mechanik des Function Calling

Function Calling folgt in allen gängigen LLM-APIs demselben Grundmuster, unabhängig vom Anbieter:

1. Tool-Definition: Jedes Tool wird über ein JSON-Schema beschrieben – Name, eine natürlichsprachliche Beschreibung des Zwecks und die typisierten Parameter. Diese Beschreibung ist die einzige Information, anhand derer das Modell entscheidet, ob und wie es das Tool nutzt.
2. Tool-Selection: Das Modell wählt im Reasoning-Schritt das passende Tool und füllt die Parameter. Es nutzt dafür ausschließlich die mitgelieferten Beschreibungen plus den Konversationskontext.
3. Strukturierter Output: Statt Prosa liefert das Modell ein maschinenlesbares Objekt. Constrained Decoding bzw. schema-gebundene Generierung stellt sicher, dass der Output dem erwarteten Format entspricht.
4. Execution & Observation: Der Aufruf wird ausgeführt, das Ergebnis zurückgegeben, der Loop läuft weiter, bis das Ziel erreicht oder ein Abbruchkriterium (Loop-Limit, Fehler, Guardrail) greift.

Der wichtigste Praxisbefund: Wenn ein Agent falsch handelt, liegt die Ursache meist nicht beim Modell, sondern bei der Tool-Definition. Anthropic formuliert die Leitlinie scharf – wenn ein menschlicher Engineer nicht eindeutig sagen kann, welches Tool in einer Situation zu nutzen ist, kann ein Agent es auch nicht.

Daraus folgen drei Designregeln:

• Tool-Count begrenzen: 3-7 aktiv geladene Tools sind 2026 Best Practice; ab etwa 10 Tools beginnt messbare Degradation der Tool-Wahl. In Anthropics internen MCP-Evals stieg die Tool-Selection-Accuracy mit dynamischer Tool-Suche von 49 % auf 74 % (Opus 4) bzw. von 79,5 % auf 88,1 % (Opus 4.5).
• Überlappung vermeiden: Zwei Tools, die plausibel dieselbe Anfrage beantworten könnten, sind das Problem, das kein Prompt löst. Eine klare „Wann-nicht-nutzen“-Klausel in der Beschreibung ist die wirkungsvollste, oft vergessene Komponente.
• Eindeutige Namen und Parameter: Sprechende Namen und eng typisierte Parameter reduzieren Fehlinterpretationen, bevor sie entstehen.

Der Bezug zu MCP: ein Standard für die Tool-Anbindung

Ohne Standard muss jede Tool-Integration einzeln verdrahtet werden – pro Agent, pro API, pro Datenquelle eigener Glue-Code. Das Model Context Protocol (MCP) löst dieses M-zu-N-Problem: Es definiert ein einheitliches Protokoll, über das ein Agent (MCP-Client) standardisiert mit Werkzeugen und Datenquellen (MCP-Server) spricht.

MCP ist damit das „Wie“ hinter dem Tool Calling, sobald Tools nicht mehr im eigenen Code liegen, sondern als wiederverwendbare Server bereitgestellt werden. Ein MCP-Server stellt Tools, Ressourcen und Prompts bereit; der Agent entdeckt sie zur Laufzeit und ruft sie über dasselbe Function-Calling-Muster auf. Der Reifegrad ist hoch: Die MCP-Spezifikation liegt in der Version 2025-11-25 vor; das Projekt wurde im Dezember 2025 an die Linux Foundation (Agentic AI Foundation) übergeben, und es existieren bereits über 10.000 MCP-Server.

Während MCP die Verbindung Agent ↔ Tool standardisiert, regelt das komplementäre Protokoll A2A (Agent-to-Agent) die Kommunikation Agent ↔ Agent in Multi-Agent-Systemen. A2A liegt seit Juni 2025 ebenfalls bei der Linux Foundation und wird von über 150 Organisationen getragen. Für reines Tool Calling ist MCP der relevante Standard; A2A wird erst auf Ebene L5 (Multi-Agent) wichtig.

Sicherheit: Tool-Permissions als Pflicht, nicht als Option

Sobald ein Agent echte Systeme berührt – Datenbanken schreibt, E-Mails versendet, Code ausführt – wird Tool-Sicherheit zur zentralen Anforderung. Die gute Nachricht: Weil das LLM Aufrufe nur vorschlägt und der umgebende Code sie ausführt, liegt der Kontrollpunkt genau dort, wo er hingehört.

Drei Pitfalls aus der Praxis sind besonders häufig: Agenten deterministisch zu behandeln, obwohl Tool-Wahl probabilistisch ist; keine Observability zu betreiben, sodass Fehler im Loop unsichtbar bleiben; und kein Human-in-the-Loop bei irreversiblen Aktionen vorzusehen. In compliance-sensiblen DACH-Kontexten kommt hinzu: Schreibende Aktionen auf Personendaten berühren DSGVO-Pflichten, und automatisierte Entscheidungen mit Rechtswirkung können unter Art. 22 DSGVO fallen (informational, keine Rechtsberatung).

Fazit

Tool Calling ist der Mechanismus, der ein LLM in einen Agenten verwandelt: Das Modell schlägt strukturierte Aufrufe vor, der Code führt sie aus, das Ergebnis treibt den nächsten Schritt. Die Qualität entscheidet sich an drei Stellen – an präzisen, überschneidungsfreien Tool-Definitionen, an einem schlanken aktiven Tool-Set (3-7) mit dynamischer Discovery, und an einer Sicherheitsarchitektur aus Least Privilege, Validierung, Bestätigungsschritten und Observability. MCP liefert dafür den offenen Standard, der die Tool-Anbindung von Einzelintegrationen zu wiederverwendbaren Servern hebt. Wer diese Grundlagen beherrscht, baut Agenten, die in Produktion zuverlässig und kontrolliert handeln.