Tool Calling verstehen: Wie LLMs APIs und andere Systeme nutzen

Ein Large Language Model kann Texte erzeugen, Informationen strukturieren und Entscheidungen vorschlagen. Von sich aus kann es jedoch weder einen Kundendatensatz aus einer Datenbank laden noch eine E-Mail versenden oder einen Termin im Kalender anlegen.

Damit ein LLM mit der Außenwelt interagieren kann, braucht es Werkzeuge. Genau dafür gibt es Tool Calling.

Dabei erhält das Modell eine Beschreibung der verfügbaren Funktionen und kann entscheiden, welches Tool mit welchen Argumenten aufgerufen werden soll. Die eigentliche Ausführung bleibt Aufgabe der Anwendung.

---

Das Grundprinzip von Tool Calling

Nehmen wir eine einfache Anfrage:

Wie hoch ist der aktuelle offene Rechnungsbetrag von Kunde 4711?

Das Sprachmodell kennt die aktuellen Rechnungen des Unternehmens nicht. Die Anwendung stellt ihm deshalb beispielsweise ein Tool get_open_invoices zur Verfügung.

Der Ablauf besteht aus mehreren getrennten Schritten:

Wichtig ist die Trennung zwischen Entscheidung und Ausführung.

Das LLM entscheidet, dass das Tool benötigt wird. Die Anwendung führt den Aufruf aus.

---

Ein Tool ist zunächst nur eine Beschreibung

Damit ein Modell ein Tool verwenden kann, muss es wissen, dass dieses Tool existiert.

Eine Anwendung könnte beispielsweise folgende Python-Funktion besitzen:

def get_open_invoices(customer_id: int) -> list[dict]:
    """Return all open invoices for a customer."""
    ...

Für das LLM reicht die Python-Funktion allein jedoch nicht. Es benötigt eine maschinenlesbare Beschreibung ihrer Schnittstelle.

Konzeptionell könnte diese so aussehen:

{
    "name": "get_open_invoices",
    "description": "Returns all open invoices for a customer.",
    "parameters": {
        "type": "object",
        "properties": {
            "customer_id": {
                "type": "integer"
            }
        },
        "required": ["customer_id"]
    }
}

Das Modell erfährt dadurch, welche Funktion existiert, wofür sie gedacht ist und welche Argumente sie erwartet.

Viele APIs verwenden dafür Strukturen, die auf JSON Schema basieren.

---

Was das LLM tatsächlich erzeugt

Der Benutzer fragt:

Welche Rechnungen sind für Kunde 4711 noch offen?

Das Modell könnte daraufhin sinngemäß folgende strukturierte Ausgabe erzeugen:

{
    "name": "get_open_invoices",
    "arguments": {
        "customer_id": 4711
    }
}

Das ist noch kein ausgeführter Funktionsaufruf.

Das Modell hat lediglich eine strukturierte Entscheidung erzeugt:

Ich möchte das Tool get_open_invoices
mit customer_id=4711 verwenden.

Erst die Anwendung interpretiert diese Ausgabe und ruft die entsprechende Funktion auf.

Das ist ein entscheidendes Sicherheitsprinzip. Das LLM bekommt nicht automatisch Zugriff auf Datenbank, Dateisystem oder Unternehmensnetzwerk.

---

Die Anwendung bleibt zwischen LLM und System

Eine typische Architektur sieht deshalb so aus:

Die Anwendung bildet eine Kontrollschicht.

Hier können Argumente validiert, Berechtigungen überprüft und Tool-Aufrufe protokolliert werden.

Diese Schicht sollte man nicht überspringen. Ein Sprachmodell ist keine vertrauenswürdige Quelle für Funktionsargumente.

---

Strukturierte Argumente machen Tool Calling möglich

Tool Calling funktioniert besonders gut, weil das Modell nicht irgendeinen Text erzeugen soll, sondern Daten entsprechend einer vorgegebenen Struktur.

Angenommen, ein Tool erstellt einen Supportfall:

def create_ticket(
    customer_id: int,
    subject: str,
    priority: str,
) -> dict:
    ...

Das Modell könnte daraus beispielsweise erzeugen:

{
    "customer_id": 4711,
    "subject": "Login funktioniert nicht",
    "priority": "high"
}

Diese Daten können anschließend validiert werden.

Zum Beispiel mit Pydantic:

from typing import Literal

from pydantic import BaseModel


class CreateTicketInput(BaseModel):
    customer_id: int
    subject: str
    priority: Literal["low", "normal", "high"]

Bevor die eigentliche Funktion ausgeführt wird:

data = CreateTicketInput.model_validate(tool_arguments)

create_ticket(
    customer_id=data.customer_id,
    subject=data.subject,
    priority=data.priority,
)

Damit entsteht eine wichtige Grenze:

LLM Output
    ↓
Validierung
    ↓
Anwendungslogik
    ↓
externes System

Das Modell darf Vorschläge für Aktionen erzeugen. Die Anwendung entscheidet, welche davon tatsächlich zulässig sind.

---

Mehrere Tools zur Verfügung stellen

Interessanter wird Tool Calling, wenn das Modell mehrere Werkzeuge kennt.

Eine Kundenservice-Anwendung könnte beispielsweise diese Tools anbieten:

get_customer
get_open_invoices
search_documentation
create_support_ticket
send_email

Bei der Frage

Welche offenen Rechnungen hat Müller GmbH?

könnte zunächst get_customer notwendig sein, weil nur der Firmenname bekannt ist.

Danach kann die Anwendung das Ergebnis wieder an das Modell übergeben. Das Modell kennt jetzt die Kunden-ID und kann anschließend get_open_invoices auswählen.

Damit nähert man sich bereits dem Prinzip eines Agenten.

Das Modell verwendet ein Ergebnis, um über den nächsten benötigten Schritt zu entscheiden.

---

Tool Calling und Agenten sind nicht dasselbe

Die Begriffe werden häufig miteinander vermischt.

Tool Calling ist zunächst lediglich ein Mechanismus, mit dem ein Modell strukturierte Aufrufe von Werkzeugen anfordern kann.

Ein Agent verwendet diesen Mechanismus häufig innerhalb eines größeren Entscheidungsprozesses.

Ein Agent kann Tool Calling verwenden. Tool Calling allein macht eine Anwendung aber noch nicht automatisch zu einem Agenten.

---

Lesen und Schreiben sind unterschiedlich riskant

Nicht alle Tools sollten gleich behandelt werden.

Ein Tool wie

get_customer(4711)

liest lediglich Informationen.

Ein anderes Tool könnte dagegen tatsächlich etwas verändern:

delete_customer(4711)

oder:

transfer_money(...)

Für produktive Systeme ist diese Unterscheidung entscheidend.

Eine sinnvolle Architektur kann Tools beispielsweise in drei Risikoklassen einteilen:

READ
Daten lesen

WRITE
Daten verändern

CRITICAL
irreversible oder besonders sensible Aktion

Für kritische Aktionen kann eine zusätzliche Freigabe erforderlich sein.

Damit wird das LLM nicht zum unkontrollierten Akteur im System.

---

Warum generische Tools gefährlich werden können

Ein Tool könnte theoretisch sehr mächtig gestaltet werden:

def execute_sql(query: str):
    ...

Das ist flexibel, gibt dem Modell aber einen enorm großen Handlungsspielraum.

Besser sind häufig spezialisierte Tools:

def get_customer(customer_id: int):
    ...


def get_open_invoices(customer_id: int):
    ...


def update_customer_email(customer_id: int, email: str):
    ...

Die Anwendung definiert damit explizit, welche Fähigkeiten das Modell besitzt.

Das folgt einem bekannten Sicherheitsprinzip: Least Privilege.

Ein Tool sollte nur genau die Rechte besitzen, die für seine Aufgabe erforderlich sind.

---

Tool-Ergebnisse müssen ebenfalls kontrolliert werden

Nicht nur die Argumente des Modells müssen kontrolliert werden.

Auch externe Systeme können unerwartete Daten liefern.

Ein Tool könnte einen sehr großen Datensatz zurückgeben. Eine API könnte fehlschlagen. Ein Dokument könnte manipulierte Anweisungen enthalten oder ein externes System temporär nicht erreichbar sein.

Die Tool-Schicht sollte deshalb auch Ergebnisse kontrollieren.

Damit wird Tool Calling zu einer klar kontrollierten Schnittstelle zwischen probabilistischer KI und deterministischer Software.

---

Fehler gehören zum normalen Ablauf

Externe Systeme funktionieren nicht immer.

Eine API kann beispielsweise mit einem Timeout reagieren:

get_customer(4711)

→ Timeout

Die Anwendung sollte diesen Fehler nicht einfach als normalen Text verstecken.

Stattdessen kann das Modell ein strukturiertes Ergebnis erhalten:

{
    "status": "error",
    "error": "customer_service_unavailable"
}

Anschließend kann entschieden werden, ob ein erneuter Versuch sinnvoll ist oder die Aufgabe abgebrochen werden soll.

Bei agentischen Systemen muss zusätzlich verhindert werden, dass daraus Endlosschleifen entstehen.

Typische Schutzmechanismen sind:

• maximale Anzahl von Tool Calls
• Timeouts
• Retry Limits
• Kostenlimits
• Abbruchbedingungen

Die Kontrolle über den Prozess sollte weiterhin bei der Anwendung liegen.

---

Tool Calling ist eine Integrationsarchitektur

Tool Calling wird häufig nur als Feature eines Sprachmodells betrachtet.

Architektonisch ist es interessanter, es als Integrationsschicht zu betrachten.

Das Sprachmodell muss nicht wissen, wie PostgreSQL, ein CRM oder ein internes Backend technisch funktionieren.

Es benötigt lediglich eine wohldefinierte Menge von Werkzeugen.

Die eigentliche Integration bleibt klassische Softwareentwicklung.

---

Wo MCP ins Spiel kommt

An diesem Punkt entsteht ein neues Problem.

Wenn jede KI-Anwendung ihre Tools individuell definiert, müssen dieselben Integrationen möglicherweise mehrfach gebaut werden.

Eine Anwendung definiert einen Zugriff auf ein Repository, eine andere benötigt denselben Zugriff ebenfalls, verwendet aber eine andere Schnittstelle.

Das Model Context Protocol, kurz MCP, versucht diese Verbindung zwischen KI-Anwendungen und externen Fähigkeiten stärker zu standardisieren.

MCP ersetzt Tool Calling nicht.

Es kann vielmehr eine standardisierte Möglichkeit bereitstellen, Tools und andere Ressourcen für KI-Anwendungen verfügbar zu machen.

Genau deshalb ist MCP der logische nächste Schritt nach dem Verständnis von Tool Calling.

---

---

Fazit

Tool Calling verbindet ein Sprachmodell mit der Außenwelt.

Das Modell erhält eine Beschreibung verfügbarer Werkzeuge und kann strukturierte Tool-Aufrufe erzeugen. Die eigentliche Ausführung übernimmt jedoch die Anwendung.

Das grundlegende Prinzip lautet:

Benutzer
   ↓
LLM
   ↓
Tool Request
   ↓
Validierung
   ↓
Anwendung
   ↓
externes System
   ↓
Ergebnis
   ↓
LLM

Diese Trennung ist entscheidend.

Ein LLM sollte nicht beliebig auf Unternehmenssysteme zugreifen können. Es sollte innerhalb einer klar definierten Softwarearchitektur entscheiden können, welche der ihm ausdrücklich zur Verfügung gestellten Fähigkeiten für eine Aufgabe benötigt werden.

Damit bildet Tool Calling eine der wichtigsten technischen Grundlagen für KI-Workflows, Agenten und moderne KI-Integrationen.

Sie möchten diese Themen systematisch verstehen und für den Einsatz im Unternehmen einordnen? Im dreitägigen Seminar KI im Unternehmen: Von ChatGPT zu RAG, Workflows und KI-Agenten werden die wichtigsten Konzepte und Architekturen praxisnah vermittelt.