Tool Use bei LLMs: Definition, Ablauf und Abgrenzung

Tool Use bezeichnet die Fähigkeit eines Large Language Model (LLM, Sprachmodell wie ChatGPT oder Claude), während der Antwort externe Funktionen aufzurufen: eine Websuche, eine Datenbankabfrage, den Aufruf einer fremden Programm-Schnittstelle (API-Call), eine Berechnung oder das Ausführen von Code. Das Modell bekommt eine Liste verfügbarer Werkzeuge (Tools) mitgeliefert und entscheidet pro Anfrage, ob und welches es nutzt; die eigentliche Ausführung übernimmt die Anwendung, die das Modell aufruft.

Was ist Tool Use?

Tool Use trennt zwei Rollen: Das Sprachmodell denkt und entscheidet, die Anwendung führt aus. Ein reines Sprachmodell kann nichts nachschlagen, keine verlässliche Rechnung garantieren und in keinem externen System etwas verändern; es kennt nur den Text aus seinem Training. Mit Tool Use wird das Modell zum Entscheider darüber, welches Werkzeug (Tool) für die vorliegende Frage passt, formuliert einen strukturierten Aufruf und übergibt die Ausführung an die Anwendung (die Runtime, also der Programmcode, in dem das Modell läuft). Das Ergebnis fließt zurück ins Gespräch, das Modell liest es und schreibt daraus die Antwort für den Nutzer.

Der Ablauf pro Turn hat vier Schritte. Die Anwendung registriert ein oder mehrere Tool-Schemas mit Name, Beschreibung und JSON-Schema der Argumente. Das Modell erhält diese Schemas zusammen mit der Nutzer-Anfrage und entscheidet, ob ein Tool nötig ist; wenn ja, gibt es den Aufruf als strukturiertes Objekt zurück statt einer Text-Antwort. Die Anwendung führt das Tool aus, sammelt das Ergebnis und schickt es als neue Nachricht ins Modell. Das Modell formuliert daraus die finale Antwort oder entscheidet, dass ein weiterer Tool-Aufruf nötig ist.

Der Begriff existiert, um das Pattern von seinen Ausprägungen zu trennen. Auf der Anbieter-Ebene ist Tool Use bei Anthropic die native Bezeichnung; OpenAI und Google sprechen von Function Calling für denselben Mechanismus. Auf der Standard-Ebene definiert das Model Context Protocol (MCP), wie Tools anbieter- und modellunabhängig exponiert werden. Tool Use ist der Baustein, aus dem ein Agent wird: Kombiniert mit einer Kontroll-Schleife, Fehlerbehandlung und Zustandsverwaltung entsteht ein Agentic Workflow.

Abgrenzung zu Function Calling, MCP, Agentic Workflow und RAG

Die vier Begriffe liegen auf unterschiedlichen Ebenen und werden im Alltag häufig vermischt.

Begriff	Rolle	Ebene
Tool Use	Pattern: Modell entscheidet über und ruft externe Werkzeuge auf	Modell-Verhalten
Function Calling	Provider-spezifische API-Mechanik für den strukturierten Aufruf	LLM-API
Model Context Protocol (MCP)	Anbieterunabhängiger Server-Standard für Tools, Ressourcen, Prompts	Server-Ebene
Agentic Workflow	Nutzung von Tool Use in einer Kontroll-Schleife über mehrere Turns	Ablauf-Muster
Retrieval-Augmented Generation (RAG)	Tool-basierte Retrieval-Variante zur Kontext-Ergänzung	Anwendungsmuster

Function Calling ist die Provider-Bezeichnung für die technische Umsetzung: OpenAI, Google und Anthropic dokumentieren jeweils eine API, mit der ein Modell strukturierte Aufrufe als JSON zurückgibt. Tool Use umfasst diese Mechanik, adressiert aber das übergeordnete Pattern und ist damit anbieterneutral. Wer über die Fähigkeit spricht, spricht von Tool Use; wer die konkrete API-Signatur beschreibt, meint Function Calling.

Das Model Context Protocol liegt eine Ebene über der LLM-API. MCP standardisiert, wie ein Server Tools und Ressourcen exponiert, und wie ein Client die Verbindung zu diesem Server aufbaut. Tool Use nutzt die vom MCP-Client bereitgestellten Tools; MCP löst das N-mal-M-Integrationsproblem zwischen LLM-Anbietern und externen Systemen.

Ein Agentic Workflow ist der Ablauf, in dem Tool Use wiederholt und kontrolliert stattfindet. Tool Use beschreibt einen einzelnen Turn: Modell entscheidet, Runtime führt aus, Ergebnis kommt zurück. Ein Agentic Workflow verkettet mehrere solche Turns, verwaltet Zwischenzustände, behandelt Fehler und terminiert erst, wenn die Aufgabe erledigt ist. Tool Use ohne Schleife bleibt eine Einzel-Aktion; erst die Schleife macht daraus einen Agenten.

RAG lässt sich als spezialisiertes Tool Use realisieren, bei dem das Modell ein Retrieval-Tool für eine Wissensbasis-Suche aufruft. Historisch ist RAG älter und wird oft ohne Modell-Entscheidung gebaut („immer retrieven, dann antworten"). Moderne RAG-Systeme setzen jedoch verstärkt auf Tool Use als Router: Das Modell entscheidet, ob eine Suche nötig ist, welche Wissensbasis passt und welche Query sinnvoll ist.

Beispiel: Support-Assistent mit drei Tools

Ein Support-Assistent hat Zugriff auf drei Tools: search_tickets, get_ticket_status und create_ticket. Jedes Tool ist als JSON-Schema definiert (Name, Beschreibung, Argumente mit Typ und Constraints). Die Schemas gehen bei jedem Modell-Aufruf mit in den Kontext.

Auf die Anfrage „Wie ist der Status meines Tickets 4711?" entscheidet das Modell, dass get_ticket_status mit dem Argument id: 4711 passt, und gibt statt einer Text-Antwort den strukturierten Aufruf zurück. Die Runtime führt den Call gegen das Ticket-System aus, erhält als Ergebnis „offen, in Bearbeitung durch L2, letzte Aktivität heute 09:14" und schickt das Ergebnis als neue Turn-Nachricht ins Modell. Das Modell formuliert daraus die Antwort für den Nutzer.

Ohne Tool Use hätte das Modell die Antwort aus dem Trainingsstand halluzinieren müssen, mit einer hohen Wahrscheinlichkeit für falsche oder erfundene Ticket-Nummern. Typische Einsatzfelder sind Retrieval-Augmented Generation mit Tool-Router, Agent-Runtimes in LangGraph, CrewAI oder dem Claude Agent SDK, Enterprise-System-Anbindung über MCP-Server sowie strukturierte Datenbank-Abfragen aus Chat-Interfaces.