Was ist Tool-Use und Function-Calling? LLM ruft externe APIs auf Mai 2026

Was ist Tool-Use?

Tool-Use, auch Function-Calling genannt, ist die Fähigkeit eines Sprachmodells, strukturiert externe Funktionen aufzurufen. Statt jede Aufgabe selbst zu lösen (Mathematik, Datenbank-Abfrage, Wetter-Lookup, Web-Suche), erkennt das Modell aus dem Nutzer-Prompt: "Hier brauche ich ein Tool" – und gibt einen strukturierten Funktion-Aufruf zurück (typisch in JSON-Format): "Rufe die Funktion `lookup_invoice` auf mit Parametern customer_id=12345 und month=2026-04". Die Anwendung führt den Aufruf aus (z.B. Datenbank-Query), gibt das Resultat zurück ans Modell, und das Modell formuliert die finale Antwort an den Nutzer mit den echten Daten.

Das ist die Grundlage moderner AI-Agenten (siehe was-ist-ai-agent). Ohne Tool-Use ist ein Sprachmodell nur ein Sprach-Generator. Mit Tool-Use wird es zum Mitarbeiter, der Datenbanken befragt, Belege erstellt, Termine vereinbart und Berechnungen ausführt. Mai 2026 ist diese Fähigkeit Standard bei allen ernsthaften LLMs:

- OpenAI Tools (das jeweils aktuelle GPT-Spitzenmodell, o3): Parallel Tool Calls (mehrere Tools gleichzeitig), Streaming Tool Calls (Tool-Call-Definition wird inkrementell sichtbar), Strict Mode (garantierte JSON-Schema-Befolgung). - Anthropic tool_use (das aktuelle Claude-Spitzenmodell): ähnlich strukturiert, Mai 2026 mit Parallel Tool Calls und Computer-Use-Erweiterung (Claude steuert Bildschirm). - Google Gemini function_calling: Funktionen werden im Generation-Config-Block deklariert, sehr nahe an OpenAI-Format. - Mistral function_calling (eine kommende Mistral-Large-Generation, Codestral): JSON-Mode plus Function-Schema-Beschreibung. - Open-Source (Llama 4, Qwen 3, DeepSeek): function_calling-Fähigkeit eingebaut, mit Library-Wrapper (LangChain, LlamaIndex) bedienbar.

Ein neuer Standard Mai 2026 ist MCP (Model Context Protocol), 2024 von Anthropic eingeführt und seit Anfang 2026 von OpenAI, Mistral und mehreren IDEs übernommen. MCP ist ein offenes Protokoll: ein MCP-Server stellt eine Sammlung von Tools (z.B. "Bexio-Buchhaltung", "Stripe-Zahlung", "Confluence-Dokumentation") bereit, jeder MCP-fähige Client (Claude Desktop, OpenAI Apps, Cursor IDE) kann sie nutzen. Das vermeidet vendor-spezifische Tool-Definitionen und macht Tool-Integrationen wiederverwendbar.

Für KMU-Nutzer ist die wichtigste Konsequenz: Tool-Use ist die Brücke zwischen LLM und realen Geschäftsdaten. Wer einen Buchhaltungs-Agent baut, der über Bexio-API Belege erstellt und über Stripe-API Zahlungs-Status prüft, braucht Tool-Use. Ohne diese Fähigkeit bleibt das LLM ein "schlauer Texter ohne Welt-Zugang".

Warum Tool-Use für KMU wichtig ist

Tool-Use berührt KMU-Workflows in vier konkreten Bereichen.

Erstens: zuverlässige Rechnung statt LLM-Mathe. Sprachmodelle rechnen nicht zuverlässig (siehe wie-funktioniert-ein-llm). Bei MWST-Berechnung, Mehrjahres-Diskontierung, Zinses-Zins gehen sie in 5-15% der Fälle daneben. Mit Tool-Use angebundener Taschenrechner (Python-Eval, Wolfram-Alpha, eigene Funktion `calculate_vat`) löst das: das Modell schreibt die Berechnung nicht in den Output, sondern ruft den Rechner auf. Resultat: 100% korrekte Berechnung, vorausgesetzt die Tool-Definition ist sauber. Treuhand-Anwendungen, in denen Kunden Steuer-Plan-Rechnungen verlangen, sollten Mai 2026 zwingend Tool-Use einsetzen.

Zweitens: Echtzeit-Datenbank-Abfragen. Wer einen Mandanten-Chatbot baut, der "Was ist der aktuelle Stand der Buchhaltung von Müller AG?" beantworten soll, braucht eine Verbindung zur Bexio/Abacus/Sage-API. Das geht NICHT ohne Tool-Use: das Modell erkennt die Anfrage, ruft `get_account_status(client_id="müller_ag")` auf, bekommt das Resultat, antwortet damit. Vor 2023 war das in eigenen Codes umständlich zu implementieren – Mai 2026 ist die Funktion in 50 Zeilen Python (OpenAI-SDK plus eigene Funktion) realisiert.

Drittens: Multi-Step-Workflows ohne Mensch in der Mitte. Wer eine Mahnung schicken will, braucht typisch 4-6 Schritte: Mandant identifizieren, offene Rechnung prüfen, Mahnstufe ermitteln, Brief generieren, Email versenden, Notiz im CRM. Mit Tool-Use kann ein Agent das in einem zusammenhängenden Call-Pattern abarbeiten – typisch 8-15 Sekunden Total-Latenz. Der Mensch sieht nur das End-Resultat ("Mahnung versendet") und kann eingreifen, wenn das Modell Unsicherheit signalisiert. Siehe ai-mahnwesen-automation.

Viertens: Web-Search überwindet Pretraining-Cutoff. Wenn das Modell Cutoff Januar 2026 hat und Sie nach aktuellen Steuer-Änderungen 2026 fragen, weiss es nichts. Mit Web-Search-Tool (Anthropic Brave Search Integration, OpenAI Browse Tool, Tavily-API, Perplexity-API) kann das Modell aktuelle Webseiten abrufen und in die Antwort einbauen. Das verschiebt das Cutoff-Problem effektiv auf "jederzeit aktuell" – vorausgesetzt die Such-Quellen sind vertrauenswürdig.

Kosten Mai 2026. Tool-Use selbst ist kostenfrei – das Modell rechnet keine Extra-Token-Gebühr. Aber jeder Tool-Call kostet eigene Kosten: API-Aufrufe an Bexio (typisch CHF 0.005-0.05 pro Call je nach Plan), Web-Search (Tavily USD 0.005, Perplexity USD 0.005-0.02), Datenbank-Query intern (vernachlässigbar bei eigener DB). Plus die Tokens für den Tool-Definition-Block im Prompt (typisch 100-500 Tokens pro deklarierte Funktion).

Strategische Konsequenz. Tool-Use ist nicht "nice to have", sondern die Brücke zwischen LLM und realer KMU-Arbeit. Wer Mai 2026 einen LLM-Workflow plant, der reale Datenzugriffe braucht, muss von Anfang an mit Tool-Use planen. Architektur ohne Tool-Use ist Architektur ohne Geschäfts-Anschluss.

Tool-Use im Detail

Eine Tool-Use-Interaktion zerfällt in 5 Schritte und involviert drei Parteien: Nutzer, LLM, Anwendungs-Code mit Tool-Implementationen.

Schritt 1: Tool-Definition. Im API-Request gibt die Anwendung eine Liste verfügbarer Tools mit. Jedes Tool hat: Name, Beschreibung (Natural-Language: "Ruft den Stand eines Bexio-Kontos ab"), Input-Schema (typisch JSON-Schema mit Pflicht-Feldern und Typen). Beispiel:

```json { "name": "get_bexio_account_status", "description": "Ruft den aktuellen Stand eines Bexio-Buchhaltungs-Kontos ab", "parameters": { "type": "object", "properties": { "client_id": { "type": "string", "description": "Bexio Mandanten-ID" }, "account_number": { "type": "string", "description": "Konto-Nr (z.B. 1000)" } }, "required": ["client_id", "account_number"] } } ```

Schritt 2: Modell entscheidet. Das Modell liest den Nutzer-Prompt und die Tool-Liste. Es entscheidet, ob ein oder mehrere Tools sinnvoll sind. Wenn ja, gibt es im Output statt Text einen strukturierten Tool-Call-Block zurück – typisch JSON oder eine spezielle XML-Form, je nach Anbieter. Wenn nein, antwortet es direkt im Text.

Schritt 3: Anwendung führt aus. Die Anwendung parst den Tool-Call, validiert die Argumente, ruft die echte Funktion auf. Das ist KEIN LLM-Aufruf – das ist normaler Anwendungs-Code (Python, Node, Go). Wichtig: die Anwendung muss authentifizieren, autorisieren, validieren – das Modell ist hier nicht im Pfad, also auch nicht in der Sicherheits-Prüfung.

Schritt 4: Resultat zurück ans Modell. Das Tool-Resultat (typisch JSON) wird ans Modell zurückgegeben als "tool_result"-Message. Das Modell sieht jetzt: "Du hast nach Bexio gefragt, hier ist die Antwort: {balance: 12450.50, currency: CHF, last_updated: 2026-05-22}".

Schritt 5: Final-Antwort. Das Modell formuliert die finale Antwort an den Nutzer mit den echten Daten: "Das Konto 1000 hat aktuell CHF 12.450,50 Stand vom 22. Mai 2026". Bei Multi-Step-Workflows kann das Modell mehrere Tool-Calls hintereinander oder parallel machen, bevor es die finale Antwort produziert.

Parallel vs Sequential Tool Calls. Mai 2026 Standard bei OpenAI und Anthropic: das Modell kann mehrere Tool-Calls parallel anfordern, wenn sie unabhängig sind. Beispiel: "Prüfe Bexio-Konto und Stripe-Zahlungen" → das Modell ruft beide gleichzeitig auf, die Anwendung führt parallel aus, Resultate zurück. Spart Latenz erheblich (oft Faktor 2-4 bei mehreren Tools).

MCP (Model Context Protocol) Mai 2026. Anthropic-Standard von 2024, breit adoptiert. Statt jedes Tool im Anwendungs-Code zu implementieren, deklariert ein MCP-Server eine Tool-Sammlung. Ein MCP-fähiger Client (Claude Desktop, OpenAI Apps, Cursor IDE, eigene Apps) verbindet sich mit dem Server und nutzt die Tools sofort. Vorteile: wiederverwendbare Tool-Sammlungen, keine vendor-spezifischen Adapter, einheitliches Auth-Modell. Mai 2026 gibt es über 1500 öffentliche MCP-Server: Bexio, Stripe, Notion, Confluence, GitHub, Slack, Postgres-DB, Wolfram, Brave Search, Sentry, und viele mehr. Siehe was-ist-mcp.

JSON-Schema-Striktheit. Früher (2023) waren Tool-Calls fehleranfällig – das Modell produzierte JSON mit Tippfehlern oder fehlenden Feldern. Mai 2026 Standard "Strict Mode" (OpenAI), garantierte JSON-Schema-Befolgung. Anthropic das aktuelle Claude-Spitzenmodell hat ein vergleichbares Feature über konstruktive Tool-Schema-Beschreibung. Praktisch: Tool-Call-Fehlerquote ist von ca. 5% (2023) auf < 0.5% (Mai 2026) gefallen.

Error Handling. Was passiert, wenn ein Tool-Call fehlschlägt (DB-Down, API-Auth-Fehler, Timeout)? Die Anwendung gibt einen Fehler-String als tool_result zurück. Das Modell sieht den Fehler und entscheidet: nochmal versuchen, ein anderes Tool nehmen, oder dem Nutzer mitteilen "Bexio ist gerade nicht erreichbar". Saubere Error-Pfade sind Pflicht in jeder Production-Tool-Use-Anwendung.

Tool-Use verstehen in 5 Schritten

1. 01Verstehen Sie das Prinzip: das LLM ruft Funktionen auf, statt alles selbst zu wissen. Daten und Aktionen kommen aus echten APIs.
2. 02Definieren Sie Tools sauber: Name, Beschreibung, JSON-Schema für Parameter. Klarheit der Beschreibung ist der Hauptfaktor für Aufruf-Genauigkeit.
3. 03Prüfen Sie MCP-Server: Mai 2026 sind 1500+ öffentliche Server verfügbar (Bexio, Stripe, Notion, GitHub, Postgres). Nicht selbst bauen, wo schon vorhanden.
4. 04Bauen Sie sicheren Validierungs-Pfad: jedes Tool ist API-Eintragspforte. Auth, Validation, Rate-Limit im Anwendungs-Code.
5. 05Testen Sie Tool-Calls mit echten Anfragen: 20-50 typische KMU-Anfragen über alle Tools laufen lassen, Tool-Call-Genauigkeit und Error-Pfade prüfen.

Wann Tool-Use einsetzen

Fünf konkrete KMU-Szenarien für Tool-Use.

Szenario 1: Datenbank-getriebene Mandanten-Anfragen. Mandant fragt "Wie hoch ist mein offener Posten-Betrag?". Antwort braucht aktuelle DB-Daten – Tool-Use mit get_open_amount(client_id) ist die saubere Lösung. Ohne Tool-Use müsste die Anwendung jedes Mal die Daten in den Prompt einbauen (RAG-ähnliches Pattern), oder der Mandant bekommt veraltete Antworten.

Szenario 2: Berechnungen mit Sicherheit. MWST-Quoten, Mehrjahres-Diskontierung, Lohn-Abrechnungs-Detail, Zinses-Zins. Tool-Use mit eigener calculate-Funktion (Python-Code) oder Wolfram-Alpha-Anbindung gibt 100% korrekte Ergebnisse. Wer Treuhand-Beratung gegen LLM-Halluzination absichern will, MUSS hier Tool-Use einsetzen.

Szenario 3: Multi-Step-Buchungsabläufe. "Erstelle eine Rechnung für Müller AG über CHF 4500 für den geleisteten Aufwand letzten Monat und sende sie via Email." Das Modell ruft sequenziell: create_invoice() → get_email(client_id="müller_ag") → send_email(to, body) auf, jeder Schritt mit echtem System-Effekt. Latenz typisch 8-20 Sekunden, vergleichbar mit menschlicher Bearbeitung – aber 0 manuelle Klicks.

Szenario 4: Web-Search für Aktualität. "Was sind die aktuellen Schweizer Steuer-Änderungen 2026?" Das Pretraining kennt nichts nach Jan 2026 (das aktuelle Claude-Spitzenmodell). Tool-Use mit Tavily oder Brave Search ruft Live-Webseiten ab, das Modell synthetisiert. Wichtig: Quellen-Auflistung im Output, damit Nutzer prüfen kann.

Szenario 5: MCP-Server für wiederverwendbare Integrationen. Wenn Sie 5 verschiedene Apps haben, die alle mit Bexio sprechen sollen – kein 5x reimplementieren. Stattdessen: ein MCP-Server "Bexio", alle Apps konsumieren ihn. Mai 2026 gibt es 1500+ öffentliche MCP-Server für gängige SaaS-Tools. Eigene MCP-Server für eigene Backends sind in 50-200 Zeilen Code geschrieben.

Szenario 6: Computer-Use für Legacy-Software. Anthropic das aktuelle Claude-Spitzenmodell hat seit 2024 Computer-Use – das Modell sieht den Bildschirm via Screenshot, klickt Maus, tippt Tastatur. Für Legacy-Software ohne API (alte Buchhaltungs-Programme) erlaubt das Tool-Use über UI-Steuerung. Latenz und Fehlerquote sind höher als bei API-Tool-Use, aber für Workflows ohne API-Alternative ist es Mai 2026 die einzige Option.

Wann Tool-Use nicht das Richtige ist

Drei Fälle gegen Tool-Use.

Erstens: pure Sprach-Aufgaben ohne Welt-Zugang. Email-Antwort generieren, Vertrag-Klausel prüfen, Inhalts-Zusammenfassung, Sitzungs-Protokoll formatieren. Diese Aufgaben brauchen keine externe API – das Modell hat alle Daten im Prompt. Tool-Use hier wäre überkompliziert.

Zweitens: Anwendungen, die hohe Sicherheits-Garantien brauchen, ohne sauberes Validierungs-Pfad. Ein Tool-Call ist nur so sicher wie die Anwendung, die ihn ausführt. Wer "delete_invoice(id)" als Tool deklariert, ohne Berechtigungs-Prüfung im Anwendungs-Code, baut eine Sicherheits-Lücke. Tool-Use erfordert Engineering-Disziplin: jedes Tool ist eine API-Eintragspforte und muss entsprechend abgesichert sein. Wer das nicht leisten kann, baut keine Tool-Use-Anwendung.

Drittens: Echtzeit-Anforderungen unter 1 Sekunde. Tool-Use erhöht Latenz: das Modell muss den Tool-Call generieren (300ms-2s), die Anwendung ausführen (variabel), Resultate zurück (300ms-2s zusätzlich), finale Antwort generieren. Mehrere Tool-Calls hintereinander oft 5-15 Sekunden Total. Für Sub-Sekunden-Voicebot zu langsam – nur bei Realtime-Streaming-API gut nutzbar.

Falle "Tool-Use macht das Modell intelligent". Tool-Use macht das Modell zugriffsfähig, nicht intelligenter. Ein dummes Modell, das mit Bexio-API verbunden ist, gibt nur "dumme Antworten mit echten Daten". Tool-Use löst Datenzugriffs-Probleme, nicht Verständnis-Probleme.

Falle "wir bauen alle Tools selbst". Mai 2026 mit MCP gibt es 1500+ vorgefertigte Tool-Sammlungen. Wer einen Bexio-MCP-Server selbst baut, weil "ist sicher schnell", verschwendet typisch 2-4 Wochen Engineering – bessere Optionen: existierende MCP-Server prüfen, evtl. einen erweitern, statt von Null bauen.

Falle "Tool-Definition ist Detail-Arbeit, das macht der Praktikant". Falsch – die Tool-Definition (Beschreibung, Parameter, Schema) bestimmt, wie zuverlässig das Modell den Tool-Aufruf trifft. Eine unscharfe Beschreibung ("ruft Konto-Daten ab") führt zu falschen Aufrufen. Klare Beschreibung mit Beispielen ("Ruft Bexio-Konto-Stand für Mandanten-ID müller_ag und Konto-Nr 1000 ab. Liefert balance in CHF und last_updated als ISO-Datum") führt zu korrekten Aufrufen. Tool-Definitionen sollen mit derselben Sorgfalt wie ein API-Vertrag dokumentiert werden.

Vor- und Nachteile

Häufige Fragen

Verwandte Themen

Quellen

1. OpenAI – Function Calling Guide and Strict Mode Reference · 2026-05
2. Anthropic – Tool Use with das aktuelle Claude-Spitzenmodell · 2026-05
3. Anthropic – Introducing the Model Context Protocol (MCP) · 2024-11
4. Google – Gemini Function Calling Documentation · 2026-04
5. MCP Hub – Public Server Directory · 2026-05