Gepostet am 16.07.2026
Tool Calling: Wie KI-Agenten auf Zusatzwissen zugreifen

Mit dem Fernglas den vollen Überblick haben: Wenn ein KI-System weiß, wo das Fernglas liegt und wie es funktioniert, dann kann es mittels Tool Calling darauf zugreifen. Illustration: Mit KI erstellt.
Erst nachdenken, dann reden: Bevor ein KI-Agent handelt, laufen im Hintergrund zahlreiche unsichtbare Prozesse ab. Je nach Konfiguration ist einer davon Tool Calling: die Verwendung zusätzlicher Werkzeuge, die das Wissen des Sprachmodells erweitern.
Hyperspezifische und zugleich sehr vage Nutzeranfragen sind das Brot- und Buttergeschäft von KI-Chatbots. Wer gerne Zeit im Freien verbringt, könnte zum Beispiel fragen: „Wir wollen morgen wandern und danach in einer Stadt in der Nähe zu Abend essen.“ Eine sinnvolle Antwort darauf erfordert aber oft mehr Wissen als das, das einem Chatbot zur Verfügung steht.
Denn vom Wetter ist in dieser Anfrage nicht die Rede. Für die konkrete Tourenplanung ist das allerdings durchaus relevant. Ein Datenbestand, der irgendwo Mitte 2025 endet, kann aber schlecht die aktuelle Wetterprognose inkludieren.
Tool Calling: Nachschlagen statt raten
Im Gegensatz zu klassischen KI-Chatbots können agentische KI-Systeme aus dem Input ableiten, dass ihr Standardwissen nicht reicht und weitere Werkzeuge verwenden. Sie greifen zum Beispiel selbstständig auf gängige Wetterdatenbanken zu und versuchen, ihre Antwort an echte Gegebenheiten anzupassen. Diesen Prozess nennt man Tool Calling – weil der Agent Werkzeuge aufruft, um den Output zu optimieren.
Ein Tool ist ein Stück Software, das meist für exakt eine Aufgabe konzipiert ist und zuverlässig ein Ergebnis zurückgibt. Ortsname und Datum rein, Wettervorhersage raus. Der Agent bedient ein Werkzeug in etwa so, wie ein Mensch eine Fahrplanauskunft verwendet.
Er muss nur wissen, welches Werkzeug welche Aufgabe erledigt.
Was beim Tool Calling passiert
Der Ablauf durchläuft je Anfrage mehrere Durchgänge. Das Modell bewertet Kontext und Anfrage, wählt ein Werkzeug und legt fest, womit es gefüttert wird. Anschließend wertet es das Ergebnis aus und beginnt von vorn, bis die Aufgabe erledigt ist. Die Entscheidung fällt im Modell, nicht in einem vorab programmierten Ablauf.
Über einen definierten Standard im Model Context Protocoll (MCP) können Informationen zwischen Werkzeugen und Modell ausgetauscht werden, ohne dass jede Kombination einzeln programmiert werden muss. Es definiert, wie das Werkzeug zu benutzen ist.
Dieser Standard wird nicht vom Anbieter programmiert und ist nicht auf diesen beschränkt. MCP ist der Überbegriff für die Definition der Verwendung von Tools. Aber er funktioniert für jedes Modell gleichermaßen, egal ob Frontier oder auf eigener Hardware.
Ein Agent erkennt anhand der Tool-Beschreibung, welches Werkzeug sich am besten eignet. Sie gehört fest zu jedem Werkzeug und enthält gewöhnlichen Text, der Zweck, Eingabe und Ausgabe benennt.
Je nach Modell könnte eine Beschreibung folgendermaßen aussehen: „Use this tool to find out about the current weather conditions in your destination. This information is retrieved via the weather API and made available." Verfasst sind solche Beschreibungen häufig auf Englisch, weil Modelle Englisch oft besser verstehen.
In der Praxis gilt eine Tool-Beschreibung als wesentlicher Faktor für die finale Antwortqualität, weil sie definiert, ob ein Modell ausreichend Tools oder das korrekte auswählt. Für Medienhäuser ist das eine Aufgabe zwischen Entwicklung und Redaktion, die in Projekten oft niemandem zugewiesen wird. Entscheidend ist nämlich auch die Auswahl der Wissensquellen, auf die das Tool zugreift. Wer Aussagen an eine geprüfte Datenbasis bindet und Websuchen auf vertrauenswürdige Adressen beschränkt, reduziert Halluzinationen.
Wie Tool Calling im KI-Reallabor zum Einsatz kommt
Der Prototyp TrekKI aus dem KI-Reallabor stellt dem Modell zwölf Werkzeuge bereit. Jedes dieser Tools hat die Aufgabe, eine spezifische Information zu recherchieren, die nicht im Gedächtnis des Modells basierend auf seinen Trainingsdaten hinterlegt ist.
Vier davon zeigen das Prinzip: Eines holt die Wettervorhersage für einen Ort, eines die Öffnungszeiten einer Einrichtung, eines durchsucht die hinterlegten Touren nach Kriterien wie Länge oder Schwierigkeit, eines berechnet die Entfernung zwischen zwei Punkten.
TrekKI wurde für einen Reise- und Wanderkontext entwickelt. Das Prinzip hinter dem Prototypen ist aber übertragbar. Was hier eine Tourendatenbank ist, kann anderswo ein Archivsystem sein oder eine Datenbank mit Wahlergebnissen. Tool Calling wird dann wichtig, wenn Teams Daten für ein Projekt aus mehreren Quellen benötigen und Werkzeuge diese bereitstellen können.
Fazit: Tool Calling ist Redaktionsarbeit
Tool Calling ist heute eine Standardtechnik. Was ein Medienhaus daraus macht, entscheidet sich an zwei Stellen, die in ihrem eigenen Verantwortungsbereich liegen: an der Struktur der Daten und an den Beschreibungen, die dem Agenten sagen, wann er welches Werkzeug nutzt.
Zeitgleich erweitert Tool Calling den Verantwortungsbereich von Redaktionen. Es genügt nicht, die komplette Entwicklung einer KI-Anwendung an die IT-Abteilung auszulagern. Der Wert von journalistisch geprüften Inhalten liegt eben genau in dieser journalistischen Prüfung und in einem Verständnis davon, welche Quellen als vertrauenswürdig einzustufen sind und welche nicht.
Redaktionelle Mitarbeit: Felix Rieger
FAQ: Tool Calling
Worin unterscheidet sich Tool Calling von RAG?
RAG (Retrieval-Augmented Generation) ist ein Abrufverfahren. Passende Stellen aus einer eingebetteten Datenbasis werden gesucht und der Anfrage beigelegt. Tool Calling ist die Entscheidungsebene darüber. Die beiden Verfahren ergänzen einander.
Wer sollte die Tool-Beschreibungen formulieren?
In der Praxis entstehen sie an einer Schnittstelle. Die Entwicklung legt Schema und Parameter fest, die Redaktion kennt die Begriffe, unter denen Nutzer:innen fragen, und die Grenzen der eigenen Inhalte. Eine gemeinsame Abnahme mit redaktionellem Review liegt nahe, ersetzt aber keine feste Zuständigkeit im Projekt.
Welche Daten braucht ein Haus dafür?
Erschlossene. In Tests im KI-Reallabor schnitt der strukturierte Wanderführer-Bestand mit Tourlänge, Schwierigkeitsgrad und GPX-Track stabiler ab als der heterogene, narrativ organisierte Reiseführer-Bestand. Metadaten wie Orte, Kategorien oder Öffnungszeiten machen Antworten zitierfähig. Redaktionelle Qualität allein genügt nicht, wenn die technische Erschließung fehlt.
Geschrieben von

Marius Grubel
Projektmanagement KI-Reallabor
Marius Grubel ist KI-Entwickler und verantwortet das KI-Reallabor. Nach beruflichen Stationen in der Automobilindustrie bringt der Absolvent des Studiengangs AI Engineering of Autonomous Systems (THI) seine Expertise in die Medienwelt ein, um dort den Austausch zu KI-Themen und -Prozessen zu fördern.


