Was ist Function Calling? Wie rufen OpenAI, Gemini und Claude über JSON APIs und externe Tools auf?

Ein von OpenAI dokumentierter Funktionsname darf höchstens 64 Zeichen lang sein. Dieses kleine, aber aussagekräftige Detail zeigt: Function Calling ist kein freies Gespräch, sondern ein strikt beschriebenes Schnittstellenproblem. Ihre wichtigste Entscheidung lautet daher: Für einen einzelnen Anbieter genügt zunächst das offizielle SDK; sobald OpenAI, Google Gemini und Claude parallel dieselben Tools nutzen sollen, benötigen Sie eine eigene Adapter-Schicht. Das Modell erzeugt eine JSON-Anforderung. Ihre Anwendung prüft und führt sie aus.

Diese Erklärung richtet sich an Sie, wenn Sie zum ersten Mal eine toolfähige KI-Anwendung bauen, mehrere Modelle hinter einer Plattform betreiben oder die Sicherheitsgrenzen zwischen Modell und API sauber festlegen müssen. Im Mittelpunkt steht nicht die Frage, welches Modell „gewinnt“, sondern wer in einem Entwicklungsteam welche Verantwortung trägt.

Die gemeinsame Datenkette ist ähnlich, die Verantwortlichkeiten sind es nicht

Function Calling verbindet natürliche Sprache mit einer kontrollierten Programmschnittstelle. Der Ablauf sieht bei allen drei Plattformen grundsätzlich so aus:

1. Sie deklarieren ein Tool mit Namen, Zweck und Eingabe-Schema.
2. Sie senden Nutzeranfrage und Toolbeschreibung an das Modell.
3. Das Modell erzeugt einen strukturierten Aufruf.
4. Ihre Anwendung validiert und führt die Funktion aus.
5. Das Ergebnis wird als Tool-Ergebnis an das Modell zurückgesendet.
6. Das Modell formuliert die Antwort oder fordert ein weiteres Tool an.

Google beschreibt diesen Ablauf als Trennung zwischen Modellentscheidung und Anwendungsausführung: Das Modell entscheidet, wann eine Funktion sinnvoll ist, liefert strukturierte Argumente und Ihre Anwendung führt den Code aus. Function Calling kann dabei externe Aktionen, zusätzliche Datenquellen oder weitere Rechen- und Verarbeitungsschritte auslösen. Google: Function Calling mit der Gemini API

Der wichtigste Satz für Ihre Architektur lautet deshalb:

Das Modell schlägt einen Aufruf vor. Der Ausführungsdienst entscheidet, ob dieser Aufruf erlaubt ist.

Damit vermeiden Sie einen häufigen Denkfehler. Function Calling ist keine direkte API-Verbindung vom Modell zu Ihrem Zahlungssystem, Ihrer Datenbank oder Ihrem Mac. Zwischen Modell und Zielsystem muss ein von Ihnen kontrollierter Dienst liegen.

Verantwortung der Modell- und Integrationsentwickler

Die Modellschicht beschreibt vier Dinge:

• einen stabilen Tool-Namen,
• eine klare Funktionsbeschreibung,
• ein JSON Schema für die Eingaben,
• eine Strategie für automatische, erzwungene oder verbotene Aufrufe.

Die Beschreibung ist kein dekorativer Text. Sie beeinflusst, ob das Modell das richtige Tool auswählt. „Verarbeitet Daten“ ist zu unpräzise. „Liest den Status eines Auftrags anhand einer internen Auftragsnummer; verändert keine Daten“ setzt dagegen eine klare Grenze.

OpenAI beschreibt Function Tools als Objekte mit Namen, Beschreibung und JSON-Schema-Parametern. Die Dokumentation weist außerdem darauf hin, dass generierte Argumente in Ihrem Code validiert werden müssen, weil ungültiges JSON oder nicht definierte Parameter trotz Schema weiterhin auftreten können. Eine strengere Schema-Konfiguration kann die strukturelle Zuverlässigkeit erhöhen, ersetzt aber nicht Ihre fachliche Prüfung. OpenAI: Function Calling

Bei Google Gemini begegnen Ihnen je nach API-Einstieg andere Begriffe. In aktuellen Schnittstellen können Funktionsaufrufe als eigene strukturierte Schritte erscheinen. In anderen Generate-Content-Abläufen werden sie als Inhaltsteile innerhalb einer Modellantwort abgebildet. Diese Varianten dürfen Sie nicht zu einer angeblich universellen Anfrage zusammenkopieren.

Claude verwendet bei eigenen Client-Tools tool_use-Blöcke und erwartet anschließend tool_result-Blöcke. Die Anwendung führt den Aufruf aus und sendet das Ergebnis in einer weiteren Nachricht zurück. Anthropic beschreibt zusätzlich stop_reason: "tool_use" als Signal dafür, dass Claude einen Werkzeugaufruf erzeugt hat. Anthropic: Tool Use mit Claude

Direkte SDK-Nutzung oder Adapter-Schicht: Welche Architektur passt?

Für einen Prototypen ist die direkte Nutzung eines offiziellen SDKs meistens der schnellste Weg. Sie sehen die Originalantwort, übernehmen die Beispiele aus der Dokumentation und müssen zunächst keine eigene Abstraktion pflegen.

Diese Entscheidung passt, wenn:

• Sie nur einen Anbieter verwenden.
• Die Tool-Sammlung klein bleibt.
• Keine gemeinsame Ausführungsschicht für mehrere Modelle nötig ist.
• Sie Anbieteränderungen direkt im Anwendungscode akzeptieren.
• Fehler und Zustände in einem einzelnen Prozess überschaubar bleiben.

Eine interne Adapter-Schicht ist dagegen sinnvoll, wenn:

• dasselbe Tool von mehreren Modellen aufgerufen werden soll,
• Sie Anbieter austauschen oder parallel evaluieren,
• zentrale Berechtigungs- und Auditregeln gelten,
• Streaming, Parallelaufrufe und Wiederholungen vereinheitlicht werden müssen,
• mehrere Teams Tools bereitstellen und nutzen.

Die Adapter-Schicht sollte nicht nur name und arguments vereinheitlichen. Sie braucht mindestens folgende interne Ereignisse:

• tool_proposed: Das Modell hat einen möglichen Aufruf erzeugt.
• tool_validated: Syntax und Schema wurden geprüft.
• tool_authorized: Berechtigung und Risikostufe wurden bestätigt.
• tool_started: Die Ausführung wurde gestartet.
• tool_succeeded oder tool_failed: Das Tool lieferte ein Ergebnis oder einen Fehler.
• model_followup_requested: Das Ergebnis wird für die nächste Modellrunde verwendet.

Speichern Sie neben dem internen Ereignis immer die vollständige Originalantwort. Sonst verlieren Sie wichtige Details: OpenAI-Call-IDs, Gemini-spezifische Status- oder Kontextinformationen und Claude-Content-Blöcke können für Wiederholungen, Debugging oder spätere Migration notwendig sein.

Wenn Sie sich zusätzlich mit agentischen Entwicklungsumgebungen beschäftigen, hilft Ihnen der Überblick zu Entwicklungsmodi für AI Agents, die Orchestrierung von Modell, Werkzeug und Ausführungsumgebung getrennt zu betrachten.

JSON Schema begrenzt Eingaben, aber nicht die Geschäftsentscheidung

Ein JSON Schema beantwortet die Frage: „Wie muss die Eingabe strukturell aussehen?“ Es beantwortet nicht automatisch:

• Darf dieser Benutzer die Ressource verändern?
• Gehört die angegebene Ressource wirklich zu diesem Mandanten?
• Ist die Aktion zum aktuellen Zeitpunkt zulässig?
• Darf ein Betrag diese Größenordnung erreichen?
• Muss vor der Ausführung eine Freigabe erfolgen?
• Ist die externe API erreichbar und für diese Datenverarbeitung freigegeben?

Das offizielle Verständnisdokument zu JSON Schema beschreibt Schema als Regelwerk, das Struktur und zulässige Datentypen eines JSON-Dokuments festlegt. Für Function Calling ist das nützlich, weil Ihr Executor dadurch Pflichtfelder, Typen und bestimmte Wertebereiche vor dem API-Aufruf prüfen kann. Die Regeln bleiben jedoch deklarativ: JSON Schema führt keinen Code aus und entscheidet nicht über Besitz, Identität oder geschäftliche Berechtigung.

Nehmen Sie ein Tool create_invoice. Das Schema kann customer_id, currency und amount als Pflichtfelder definieren. Trotzdem darf der Executor nicht einfach jede vom Modell gelieferte customer_id verwenden. Er muss prüfen, ob der angemeldete Benutzer Zugriff auf diesen Kunden besitzt. Ebenso muss die Währung zur Organisation passen und der Betrag gegen Geschäftsregeln geprüft werden.

Für die Ausführungsschicht gelten daher eigene Regeln:

• API-Schlüssel und langfristige Zugangsdaten bleiben im Secret-Management.
• Zugangsdaten gehören nicht in Prompts, Tool-Beschreibungen oder modelllesbare Dateien.
• Netzwerkzugriffe erhalten Ziel-, Methoden- und Zeitlimits.
• Schreibende und destruktive Aktionen werden getrennt behandelt.
• Wiederholungen brauchen Idempotenzschlüssel.
• Ergebnisse werden auf sensible Inhalte, Größe und erwartete Struktur geprüft.
• Zeitüberschreitungen werden als kontrollierte Tool-Fehler zurückgegeben.

Gerade bei DSGVO-relevanten Anwendungen müssen Sie zusätzlich festlegen, welche Eingaben, Tool-Ergebnisse und Gesprächsverläufe gespeichert werden. Die Anbieter unterscheiden sich bei Zustandsverwaltung, Server-Tools und Datenkontrollen. Diese Einstellungen gehören in Ihre Datenschutzprüfung und dürfen nicht stillschweigend aus dem SDK-Verhalten abgeleitet werden.

OpenAI, Google Gemini und Claude API im technischen Vergleich

Die Gemeinsamkeit liegt im Konzept, nicht im Nachrichtenformat.

OpenAI: Funktionsaufruf als eigenes Antwort- oder Tool-Element

In aktuellen OpenAI-Abläufen können Funktionsaufrufe als strukturierte Response-Elemente erscheinen. Bei Streaming werden Argumente in Teilstücken übertragen und später als vollständige Argumente abgeschlossen. Das bedeutet für Ihren Adapter: Sie dürfen einen Stream nicht bei jedem Fragment ausführen. Sie müssen Argumentteile nach call_id oder dem jeweiligen Antwortobjekt sammeln und erst nach erfolgreicher Rekonstruktion parsen. OpenAI: Streaming-Ereignisse für Function-Call-Argumente

Für die interne Verarbeitung sollten Sie deshalb unterscheiden zwischen:

• einem begonnenen Aufruf,
• partiellen Argumenten,
• vollständig empfangenen Argumenten,
• validierten Argumenten,
• dem Ergebnis des Executors.

Google Gemini: Function-Call- und Function-Result-Schritte

Google Gemini dokumentiert einen Ablauf, bei dem das Modell einen Funktionsaufruf erzeugt. Ihre Anwendung führt die Funktion aus und sendet ein Ergebnis mit dem passenden Aufrufbezug zurück. Gemini unterstützt außerdem parallele Aufrufe für unabhängige Aufgaben und verkettete Aufrufe, bei denen das Ergebnis eines Tools die Eingabe für ein weiteres Tool bildet.

Bei zustandslosen Interaktionen müssen Sie die vollständige Historie korrekt verwalten. Dazu gehören Nutzereingabe, ursprüngliche Modellschritte und Tool-Ergebnis. Werden einzelne Modellblöcke ausgelassen, kann der nächste Aufruf den Zusammenhang verlieren.

Claude API: Content-Blöcke und Tool-Use-Status

Bei der Claude API befindet sich der Werkzeugaufruf in einem tool_use-Block. Die Anwendung übernimmt die ID, führt die Operation aus und sendet einen tool_result-Block zurück. Bei mehreren Werkzeugen kann Claude mehrere Aufrufe in derselben Antwort erzeugen. Über tool_choice lässt sich außerdem steuern, ob Claude automatisch entscheidet, ein bestimmtes Tool verwenden muss oder kein Tool verwenden darf.

Anthropic unterscheidet zudem zwischen Client-Tools, deren Code in Ihrer Anwendung läuft, und Server-Tools, die auf der Infrastruktur von Anthropic ausgeführt werden. Diese Unterscheidung ist für Datenschutz, Netzwerkzugriff, Protokollierung und Verantwortlichkeit entscheidend.

Die Ausführungsschicht trägt das eigentliche Risiko

Der Executor ist kein dünner Wrapper um requests.post(). Er ist eine Sicherheits- und Zuverlässigkeitsgrenze.

Ein robuster Ablauf sieht so aus:

1. Originalantwort speichern: Bewahren Sie Anbieter, Modell, API-Einstieg, Anfrage-ID und vollständigen Tool-Block auf.
2. Argumente dekodieren: Prüfen Sie, ob die Argumente gültiges JSON bilden. Bei Streaming warten Sie auf das vollständige Ereignis.
3. Schema validieren: Lehnen Sie unbekannte Felder, fehlende Pflichtfelder und falsche Datentypen ab.
4. Fachlich prüfen: Kontrollieren Sie Wertebereiche, Mandantenzugehörigkeit, Eigentum und aktuelle Geschäftsregeln.
5. Risiko bewerten: Ordnen Sie das Tool als lesend, schreibend, destruktiv oder offen netzwerkfähig ein.
6. Freigabe einholen: Für kritische Aktionen verlangen Sie eine explizite Nutzer- oder Serviceteam-Freigabe.
7. Ausführen: Verwenden Sie kurzlebige Zugangsdaten, definierte Ziele, Timeouts und Idempotenz.
8. Ergebnis verpacken: Geben Sie nur die für die nächste Modellrunde nötigen Informationen zurück.
9. Nachbearbeiten: Prüfen Sie, ob das Modell danach eine endgültige, sachlich korrekte Antwort erzeugt.

Ein Fehler sollte nicht als ungefilterter Stacktrace zurück an das Modell gehen. Besser ist ein strukturiertes Ergebnis wie:

{
  "status": "error",
  "code": "RESOURCE_NOT_FOUND",
  "retryable": false,
  "message": "Die angeforderte Ressource wurde nicht gefunden."
}

Dieses Format hilft dem Modell, verständlich zu reagieren, ohne interne Pfade, Tokens, Zugangsdaten oder Infrastrukturdetails offenzulegen.

Prüfplan für ein gemeinsames Tool in drei Plattformen

Verwenden Sie für OpenAI, Google Gemini und Claude denselben fachlichen Anwendungsfall, zum Beispiel ein nur lesendes Wetter- oder Status-Tool. Ändern Sie nicht die Geschäftslogik, sondern dokumentieren Sie die jeweilige Anbieterintegration getrennt.

Prüfen Sie mindestens:

• [ ] Tool-Name und Beschreibung sind eindeutig.
• [ ] Pflichtfelder werden in allen drei Schemas gleich behandelt.
• [ ] Unbekannte Parameter werden abgewiesen.
• [ ] Fehlende Parameter erzeugen keinen direkten API-Aufruf.
• [ ] Falsche Datentypen werden vor der Ausführung erkannt.
• [ ] Parallele Aufrufe werden korrekt gesammelt.
• [ ] Mehrere Tool-Aufrufe behalten ihre jeweilige ID.
• [ ] Ein Timeout wird als kontrollierter Fehler zurückgegeben.
• [ ] Ein nicht wiederholbarer Fehler löst keinen gefährlichen Retry aus.
• [ ] Die Tool-Historie bleibt nach einem Neustart rekonstruierbar.
• [ ] Das Modell erhält nach dem Tool-Ergebnis keine geheimen Infrastrukturdetails.
• [ ] Die finale Antwort wird gegen das tatsächliche Tool-Ergebnis geprüft.

Für Streaming müssen Sie zusätzlich testen, ob Argumente in Fragmenten eintreffen. Bei OpenAI und Google Gemini ist dieser Fall in den jeweiligen API-Abläufen besonders relevant. Ein häufiger Fehler besteht darin, das erste Fragment wie vollständiges JSON zu behandeln.

Wenn Sie Schema-Kompatibilität und strukturierte Ausgaben weiter vertiefen möchten, können Sie den internen Leitfaden zu JSON Schema und strukturierten AI-Ausgaben als Ergänzung verwenden. Für die Berechtigungsschicht ist außerdem der Artikel zu Regeln und Skills in AI-Coding-Workflows relevant, weil dort die Trennung zwischen Anweisung und ausführbarer Aktion weitergedacht wird.

Häufige Fehlannahmen im Entwicklungsalltag

„Das Schema ist streng, also ist der Aufruf sicher“

Nein. Ein gültiger String kann ein unzulässiger Benutzername sein. Eine gültige Auftragsnummer kann zu einem anderen Mandanten gehören. Ein gültiger Betrag kann außerhalb der Freigabegrenze liegen. Schema-Prüfung ist Syntaxkontrolle, keine Autorisierung.

„Alle Anbieter akzeptieren dieselbe Tool-Nachricht“

Nein. Ein universelles internes Ereignis ist sinnvoll. Eine universelle Anbieteranfrage ist riskant. Übersetzen Sie den internen Vertrag je Plattform und behalten Sie das Originalobjekt für Diagnose und Wiederholung.

„Ein Modell kann die API direkt ansprechen“

Bei benutzerdefinierten Client-Tools nicht. Das Modell liefert die Absicht und die Argumente. Ihr Code besitzt Netzwerkzugriff, Geheimnisse und Ausführungsrechte. Nur ausdrücklich als Server-Tools bereitgestellte Funktionen werden durch den Anbieter selbst ausgeführt.

„Ein Fehler lässt sich einfach erneut an das Modell senden“

Nur bei kontrollierbaren Fehlern. Bei Berechtigungsfehlern, ungültigen Ressourcen oder destruktiven Aktionen kann ein automatischer Retry die Lage verschärfen. Der Fehlerstatus muss deshalb zwischen wiederholbar, nicht wiederholbar und freigabepflichtig unterscheiden.

Entscheidungshilfe für Ihre Architektur

Wählen Sie nach diesen Bedingungen:

• Wenn Ihr Projekt nur einen Anbieter nutzt und wenige Tools besitzt, dann starten Sie mit dem offiziellen SDK.
• Wenn Sie OpenAI, Google Gemini und Claude mit derselben Tool-Sammlung betreiben, dann bauen Sie früh eine Adapter-Schicht.
• Wenn Tool-Aufrufe nur lesend sind, dann können Sie die Automatisierung großzügiger testen.
• Wenn Tools Daten verändern, Zahlungen auslösen oder Ressourcen löschen, dann verlangen Sie eine separate Autorisierungs- und Freigabeschicht.
• Wenn Sie Streaming einsetzen, dann speichern und aggregieren Sie Argumentfragmente vor der Validierung.
• Wenn ein Tool externe Systeme mit langen Laufzeiten aufruft, dann brauchen Sie Job-ID, Timeout, Statusabfrage und idempotente Wiederholung.
• Wenn Ihr Agent macOS-Kommandos, Xcode, AppleScript oder andere Apple-Automatisierung ausführen muss, dann trennen Sie Modell- und Ausführungsebene und bewerten einen kontrollierten Remote-Mac-Knoten.
• Wenn Sie dauerhaft hohe, planbare Last mit eigenen physischen Schnittstellen benötigen, dann ist eine eigene Maschine oft passender als eine gemietete temporäre Umgebung.

Ein gewöhnlicher Linux- oder Windows-Server kann den Modell-Adapter und viele Web-APIs problemlos betreiben. Er wird jedoch unpraktisch, sobald Ihre Tools zwingend macOS, Xcode, Apple-Signierung oder Apple-Automatisierung benötigen. Lokale Hardware verursacht in diesem Fall zusätzliche Anschaffung, Wartung, Updates, Zugriffsschutz und Auslastungsrisiko.

Hashvps kann als temporärer Remote-Mac-Ausführungsknoten sinnvoller sein, wenn Sie eine Testumgebung, CI/CD-Läufe oder einen zeitlich begrenzten Agentenbetrieb benötigen, ohne dafür dauerhaft eigene Apple-Hardware zu reservieren. Für langfristige Dauerlast oder den Zugriff auf spezielle physische Geräte sollten Sie die Mietoption dagegen nüchtern gegen einen eigenen Rechner abwägen.

Function Calling wird zuverlässig, wenn Sie nicht versuchen, das Modell zum Ausführungsserver zu machen. Definieren Sie klare Schemas, übersetzen Sie Anbieterformate in interne Ereignisse, prüfen Sie jeden Aufruf unabhängig und behandeln Sie Berechtigungen als eigene Schicht. Dann können OpenAI, Google Gemini und Claude dieselben fachlichen Tools nutzen, ohne dass Ihre Sicherheits- und Betriebslogik an eine einzelne API-Antwort gekoppelt bleibt.