Tool-Use und Function Calling: wie KI-Systeme mit bestehenden Anwendungen sprechen

Was Tool-Use und Function Calling wirklich sind

Im Kern bedeutet Tool-Use, dass ein Sprachmodell neben dem Formulieren von Antworten auch Funktionen aufrufen kann. Statt einen Wert zu „wissen", fragt das Modell eine Funktion, die diesen Wert verlässlich liefert. Die Funktion gibt ein Ergebnis zurück, das Modell verarbeitet es und liefert eine Antwort. Function Calling ist die technische Umsetzung dieses Konzepts: Das Modell erzeugt einen strukturierten Aufruf, der von der umgebenden Anwendung an die richtige Stelle geleitet wird.

Das klingt einfach, ist aber ein fundamentaler Unterschied zu reiner Textgenerierung. Ein Modell ohne Tool-Use muss raten. Ein Modell mit Tool-Use kann einen Bestellstatus abrufen, eine Kennzahl aus dem DWH lesen, ein Ticket anlegen oder einen Kalendereintrag erzeugen. Die „Intelligenz" verlagert sich damit vom Generieren ins Orchestrieren — und genau dort wird KI für Unternehmen wirklich nützlich.

Warum Tool-Use der wichtigste Hebel für Unternehmens-KI ist

In Unternehmen liegt der Wert selten in allgemeinen Antworten, sondern in konkreten Aktionen auf definierten Daten. Ein Chatbot, der Kennzahlen schätzt, ist wenig hilfreich. Ein Assistent, der die aktuelle Zahl aus dem richtigen System holt, ist Arbeit, die sonst Menschen machen. Tool-Use macht aus einem allgemein gebildeten Modell ein domänenspezifisches Werkzeug.

Damit verschiebt sich auch das Risikoprofil. Reines Textgenerieren ist anfällig für Halluzinationen. Tool-Use zwingt das Modell dazu, Fakten aus definierten Quellen zu beziehen. Diese Architekturentscheidung ist einer der wichtigsten Hebel, um Halluzinationen systematisch zu reduzieren: Was nachprüfbar beschaffbar ist, sollte nicht vom Modell erfunden werden dürfen.

Was ein gutes Tool ausmacht

Aus Sicht des Modells ist ein Tool ein Stück Code mit Name, Beschreibung und Parameter-Schema. Je klarer diese Spezifikation, desto stabiler ruft das Modell das Tool auf. Drei Eigenschaften zeichnen gute Tools aus. Erstens: eine präzise, handlungsorientierte Beschreibung. „Liefert den aktuellen Bestand eines Artikels im Standortlager" ist besser als „Bestandsabfrage-Funktion".

Zweitens: enge, typisierte Parameter. Ein Feld, das nur gültige Werte erlaubt, reduziert die Fehlinterpretationen drastisch. Dritte: ein klar definiertes Rückgabeformat. Ein Tool, das strukturierte Daten zurückgibt, ist für das Modell leichter zu integrieren als eines, das einen Textblock liefert. Und weniger ist mehr: Zehn gut beschriebene Tools sind robuster als dreißig, die das Modell nicht sicher auseinanderhalten kann.

Fehlerbehandlung und Rückfälle

In der Praxis laufen Tools nicht immer sauber. Eine API ist kurz nicht erreichbar, ein Parameter fehlt, ein Datensatz ist nicht vorhanden. Die Qualität einer Tool-Use-Anwendung zeigt sich weniger an Schönwetter-Fällen als am Umgang mit diesen Fehlern. Wichtig ist, dass Fehler strukturiert an das Modell zurückgegeben werden, nicht als kryptische Stacktraces. Eine Meldung wie „Artikel nicht gefunden, bitte Prüfung der Artikelnummer vorschlagen" ist für das Modell umsetzbar, ein Java-Exception nicht.

Darüber hinaus lohnt sich eine klare Trennung zwischen lesenden und schreibenden Tools. Schreibende Operationen — Tickets anlegen, Einträge ändern, Rechnungen freigeben — brauchen ein anderes Sicherheitsniveau als reine Abfragen. Häufig ist hier ein zweistufiges Modell sinnvoll: Das Modell bereitet eine Aktion vor, und eine Person oder ein deterministischer Schritt bestätigt, bevor der Aufruf tatsächlich ausgeführt wird.

Sicherheit und Berechtigungen

Ein Modell, das Tools aufrufen kann, ist nur so privilegiert wie diese Tools. Das klingt banal, ist aber oft der Kern von Sicherheitsproblemen. Wer einem Assistenten Zugriff auf ein Tool gibt, das Daten aus einem Quellsystem ohne Berechtigungsfilter zurückgibt, hat die Zugriffskontrolle faktisch abgeschaltet.

In tragfähigen Setups setzt der Assistent die Identität des aufrufenden Nutzers bis zur Tool-Ebene durch. Das heißt: Das Tool arbeitet mit dem Token der Nutzerin, nicht mit einem System-Token, und sieht nur die Daten, auf die diese Nutzerin ohnehin Zugriff hätte. Diese architektonische Entscheidung ist häufig aufwändiger als erwartet, aber in sensiblen Umgebungen nicht verhandelbar. Sie gehört in die Kerngrundlagen bei AI Engineering.

Tool-Use in Agenten und festen Workflows

Tool-Use taucht in zwei sehr unterschiedlichen Architekturen auf. In festen Workflows ruft ein definierter Ablauf gezielt Tools an bestimmten Stellen auf. Das Modell ist dort ein Teilnehmer, kein Entscheider. In echten KI-Agenten entscheidet das Modell selbst, welche Tools in welcher Reihenfolge aufgerufen werden. Beide Setups haben ihre Berechtigung, und die Wahl hängt stark vom Aufgabentyp ab.

Für die Gestaltung der Tools macht das einen Unterschied. In festen Workflows reicht eine enge Tool-Menge pro Kontext. In agentischen Setups sollten Tools so gestaltet sein, dass das Modell ihre Rollen eindeutig unterscheiden kann. Überlappende Zuständigkeiten — zwei Tools, die fast dasselbe tun — sind in Agenten-Umgebungen regelmäßig eine Fehlerquelle.

Monitoring und Nachvollziehbarkeit

Tool-Aufrufe sind die handelnden Momente einer KI-Anwendung. Sie gehören deshalb unbedingt vollständig protokolliert: welches Tool mit welchen Parametern von welchem Modell für welche Nutzeranfrage aufgerufen wurde und was zurückkam. Ohne diese Spur ist Debugging eines komplexen Setups praktisch unmöglich — und jede Rechenschaftsfrage wird zur Zitterpartie.

Über das reine Logging hinaus lohnt sich eine systematische Auswertung: Welche Tools werden häufig aufgerufen, welche kaum, welche enden in Fehlern, wo entstehen Zeitverluste? Diese Auswertung überschneidet sich mit dem Feld LLM-Monitoring und Observability und liefert konkrete Anhaltspunkte für Verbesserung.

Protokolle und Standards

Rund um Tool-Use ist ein Ökosystem an Standards entstanden. Anbieter-eigene Function-Calling-Formate, offene Protokolle wie das Model Context Protocol, OpenAPI-basierte Tool-Beschreibungen und verschiedene Frameworks konkurrieren um die gleiche Rolle: eine standardisierte Brücke zwischen Modell und Anwendung. Welches Protokoll im konkreten Fall sinnvoll ist, hängt stark von Modell, Stack und Zielarchitektur ab.

Wichtiger als die Wahl eines Protokolls ist, dass die Tool-Definitionen abstrahiert vom konkreten Modell liegen. Wer Tools eng an einen Anbieter bindet, macht sich unnötig abhängig. Eine saubere Trennung zwischen Tool- Definitionen, Modellanbindung und Anwendungslogik erlaubt, das Modell zu wechseln, ohne die Tool-Ebene neu bauen zu müssen. Diese Frage überschneidet sich direkt mit der Modellauswahl im Unternehmen.

Typische Fehler in Tool-Use-Projekten

Der häufigste Fehler ist, zu viele Tools zu geben. Ein Modell, das aus dreißig Funktionen wählen soll, trifft regelmäßig die zweitbeste Wahl. Eine klare Priorisierung und eine enge, gut beschriebene Tool-Menge schlägt in der Praxis fast immer einen breit gestreuten Werkzeugkasten.

Der zweite Fehler ist, die Parameterschemata unscharf zu halten. Freie Stringparameter, fehlende Validierung und optionale Felder, die in Wahrheit nicht optional sind, sorgen dafür, dass Aufrufe zufällig scheitern oder falsch laufen. Je strenger das Schema, desto stabiler die Anwendung.

Der dritte Fehler ist, Tool-Use einzuführen, ohne Prompts und System-Prompt darauf anzupassen. Ein Modell, das Tools zur Verfügung hat, aber nicht weiß, wann es sie nutzen soll, nutzt sie oft zu selten oder zu viel. Klare Anweisungen, welche Fragen mit Tools beantwortet werden sollen und welche nicht, sind Teil guter Prompt-Arbeit.

Der vierte Fehler ist, schreibende Tools nicht durch einen Kontrollschritt zu sichern. Ein Assistent, der ohne Rückfrage Rechnungen freigibt oder Kundendatensätze ändert, ist eine Haftungsquelle. Sichere Setups machen Wirkungsaktionen sichtbar und bestätigungspflichtig — auch wenn das ein paar Klicks mehr bedeutet.

Wann professionelle Unterstützung sinnvoll ist

Ein einfaches Tool-Use-Setup mit wenigen Funktionen und klarer Fachlogik lässt sich intern in überschaubarer Zeit aufbauen. Sobald aber mehrere Quellsysteme, verschiedene Berechtigungsmodelle, schreibende Aktionen und eine nachvollziehbare Protokollierung zusammenkommen, wird aus einem Feature eine Architektur, die Erfahrung verlangt.

Wir begleiten Unternehmen dabei, Tool-Use sauber zu gestalten: vom Zuschnitt der Tool-Menge über sichere Zugriffe auf Bestandssysteme bis zu den Betriebsfragen, die aus dem Zusammenspiel mit KI-Agenten entstehen. Wenn Sie gerade eine Anwendung mit Systemzugriff bauen, lohnt es sich, diese Architekturfragen früh zu klären, bevor die erste Sicherheitslücke oder das erste stille Qualitätsproblem entsteht.