Function Calling ist der gängigste Mechanismus, mit dem große Sprachmodelle auf externe Fähigkeiten zugreifen: Entwickler beschreiben zunächst im JSON-Schema-Format, „welche Funktionen es gibt und wie ihre Parameter aussehen". Braucht das Modell mitten im Gespräch Daten oder eine Aktion, gibt es eine strukturierte Aufrufanfrage aus. Das eigene Programm führt die echte Funktion aus und speist das Ergebnis zurück, damit das Modell fortfahren kann. Der Kern in einem Satz: Das Modell entscheidet nur, „was aufgerufen wird und welche Parameter eingetragen werden" – der Code, der wirklich läuft, ist immer der eigene.
Welches Problem löst es eigentlich?
Ein Modell gibt nativ nur Text aus; „handfeste" Dinge wie Wetterabfrage, Datenbankzugriff oder Bestellungen kann es nicht. Function Calling schlägt dazwischen eine Brücke: Das Modell versteht die Anfrage in natürlicher Sprache, drückt „welche Funktion ich mit welchen Parametern aufrufen will" strukturiert aus und überlässt die Ausführung dem Programm. Genau das ist das Fundament, auf dem Tool Calling steht.
Wie ein vollständiger Funktionsaufruf aussieht
- Definieren: Die Anfrage enthält ein tools-Array, das Name, Beschreibung und Parameterstruktur (JSON Schema) jeder Funktion festhält.
- Entscheiden: Braucht das Modell eine externe Fähigkeit, antwortet es nicht direkt, sondern gibt tool_calls zurück: Funktionsname plus Parameter-JSON.
- Ausführen: Das eigene Programm parst die tool_calls und ruft die echte Funktion auf – API-Abfrage, Datenbankzugriff oder Skriptausführung.
- Zurückspeisen: Das Ergebnis fließt als tool-Nachricht zurück ins Gespräch, und das Modell formuliert daraus seine finale Antwort.
Die wichtigsten Bausteine
- tools-Definitionen: eine „Bedienungsanleitung" für das Modell. Je klarer die Beschreibung, desto treffsicherer die Parameter – description schreibt man für das Modell, nicht für Menschen.
- tool_choice: steuert, ob das Modell eine Funktion „aufrufen muss / darf / nicht darf"; üblich sind auto, none oder ein konkreter Funktionsname.
- Parallele Aufrufe: mehrere tool_calls auf einmal – praktisch, um in einer Runde mehrere unabhängige Dinge zu erledigen.
- Strukturelle Vorgaben: Parameter müssen valides JSON sein; ein Typfehler scheitert auf Programmseite, Schema-Vorgaben sind also strikt.
Die wirklichen Unterschiede zu Tool Calling, MCP und Plugin-Aufrufen
| Dimension | Function Calling | Tool Calling | MCP | Plugin-Aufrufe |
|---|---|---|---|---|
| Wesen | Ein Aufrufmechanismus | Oberbegriff | Ein Verbindungsprotokoll | Ein Vertriebsmodell für Fähigkeiten |
| Wer definiert Tools | Der Entwickler, in der Anfrage | Unterschiedlich | Wird vom MCP-Server bereitgestellt | Wird von der Plattform paketiert |
| Gelöstes Problem | Wie das Modell einen Aufruf startet | Wie das Modell externe Fähigkeiten nutzt | Wie Tools gefunden und einheitlich angebunden werden | Wie Fähigkeiten zu Nutzern gelangen |
Function Calling wurde 2023 von OpenAI popularisiert; die meisten gängigen Modelle bieten heute kompatible Umsetzungen. Tool Calling ist der größere Eimer, in dem Function Calling, Codeausführung und MCP-Tools gleichermaßen Platz finden. Merksatz: MCP kümmert sich ums „Wie verbinden", Plugins ums „Wie verteilen", Function Calling ums „Wie starten" – die drei sind Glieder einer Kette, kein Ersatz füreinander. Die Grenze zu Plugin-Aufrufen folgt derselben Logik.
Grenzen und Einschränkungen
- Parameter-Halluzinationen: Das Modell erfindet ggf. Parameternamen oder vertippt sich bei Typen; die Programmseite muss validieren.
- Tokens und Latenz: Jeder Aufruf kostet eine Gesprächsrunde, und tools-Definitionen belegen selbst Kontext – viele Tools bedeuten teuer und langsam.
- Rote Linien bei Sicherheit: Niemals das Modell direkt irreversible Aktionen auslösen lassen – Datenbank löschen, Geld überweisen, Massenmails; sensible Aktionen brauchen menschliche Bestätigung.
- Unterschiedliche Reife: Die Modelle unterscheiden sich darin, wie ausgereift ihr Function Calling ist; kleinere „reden oft nur, statt aufzurufen" oder verfehlen das Format.
Häufige Missverständnisse
- „Das Modell führt wirklich Code aus" – nein. Es gibt nur Aufrufanfragen aus; die Ausführung liegt in deinem Programm.
- „Function Calling ist MCP" – nein. MCP ist eine Protokollebene; Tools, die es bereitstellt, kann das Modell trotzdem über Mechanismen wie Function Calling nutzen.
- „Mit Function Calling braucht man keine Plugins" – Plugins verteilen Fähigkeiten an Nutzer, Function Calling dient Entwicklern; verschiedene Ebenen.
- „Definiert heißt immer aufgerufen" – Standard ist auto; sieht das Modell keinen Bedarf, ruft es nicht auf. Zum Erzwingen den Funktionsnamen explizit nennen.
FAQ
F: Ist Function Calling dasselbe wie die Tool-Parameter in den APIs der Anbieter?
A: Selbe Abstammung – „Modell gibt strukturierte Aufrufe aus, Programm führt aus" – mit Unterschieden bei Feldnamen und Verpackung; bei der Migration ändert man vor allem die Definitionen.
F: Ich nutze bereits MCP. Muss ich mich trotzdem um Function Calling kümmern?
A: Ja. MCP löst, wie Tools angebunden werden; Function Calling, wie das Modell Aufrufe startet. Vor- und nachgelagert, kein Entweder-oder.
F: Kann Function Calling lokale Skripte aufrufen?
A: Ja. Eine Funktion ist nur ein Einstiegspunkt im eigenen Programm; was dahintersteckt, ist dem Modell egal. Es sagt nur „welche, mit welchen Parametern".
