In Diskussionen über AI-Agent-Integrationen tauchen drei Begriffe auf, die oftmals synonym verwendet werden. Function Calling, Tool Use und Model Context Protocol klingen so ähnlich, dass sie in vielen Artikeln und Slack-Channels miteinander verwechselt werden. Sie beschreiben aber drei unterschiedliche Konzepte auf drei verschiedenen Ebenen.
Wer eine AI-Integration plant, kommt an dieser Begriffsklärung nicht vorbei. Die Wahl zwischen Function Calling, Tool Use und MCP ist nicht beliebig, weil sie jeweils unterschiedliche Verträge mit unterschiedlichen Anbietern und unterschiedliche Portabilitäts-Eigenschaften nach sich zieht.
Function Calling ist OpenAIs API-Mechanismus, mit dem ein Modell strukturierte Funktions-Aufrufe in der Konversation einbringt. Tool Use ist Anthropics Begriff für dasselbe Grundkonzept im Claude-Modell. MCP (Model Context Protocol) liegt eine Ebene tiefer, ist ein offener Standard, mit dem Tools von externen Servern bereitgestellt werden, unabhängig vom konkreten Agent-Anbieter. Function Calling und Tool Use sind anbieter-spezifische APIs, MCP ist ein anbieter-neutrales Protokoll.
Drei Begriffe, drei Ebenen
Die drei Begriffe sitzen nicht auf derselben Abstraktions-Ebene. Wer sie als gleichwertige Alternativen behandelt, übersieht den Unterschied zwischen Anbieter-API und offenem Protokoll.
Function Calling und Tool Use sind beide Modell-API-Features. Sie beschreiben, wie ein konkretes Sprachmodell innerhalb einer Konversation strukturierte Aufrufe formuliert. Function Calling kommt von OpenAI und wurde im Sommer 2023 eingeführt. Tool Use ist Anthropics äquivalente Funktion in Claude, die kurz danach folgte. Beide sind technisch sehr ähnlich, syntaktisch aber unterschiedlich, weil jeder Anbieter sein eigenes JSON-Schema definiert.
MCP ist ein Protokoll-Layer darüber. Es definiert nicht, wie ein Modell Tool-Aufrufe formuliert (das tut weiterhin der Anbieter), sondern wie Tools von externen Servern bereitgestellt und konsumiert werden. Ein MCP-Server ist anbieter-neutral. Er funktioniert mit Claude, mit ChatGPT, mit Cursor und mit jedem anderen Agenten, der das Protokoll unterstützt.
Wer die drei Begriffe dauerhaft sortieren will, kann sich an einer einfachen Frage orientieren. Function Calling beantwortet die Frage „Wie macht OpenAI das?", Tool Use beantwortet „Wie macht Anthropic das?", und MCP beantwortet „Wie macht man es anbieter-neutral?". Die ersten beiden sind Hersteller-Antworten auf dasselbe Grundproblem, der dritte ist die offene Spec, gegen die alle Hersteller implementieren können.
Function Calling als OpenAI-Pattern
Function Calling wurde von OpenAI im Juni 2023 als API-Feature eingeführt. Die Grundidee ist, dass ein Sprachmodell statt einer freien Antwort ein strukturiertes JSON-Objekt zurückgibt, das einen Funktions-Aufruf darstellt. Die Anwendung führt diesen Aufruf aus, gibt das Ergebnis zurück, und das Modell setzt die Konversation fort.
Technisch sieht das so aus. Der Entwickler übergibt der OpenAI-API eine Liste von Funktions-Definitionen mit Name, Beschreibung und Parameter-Schema. Das Modell entscheidet anhand der Konversation, ob es eine der Funktionen aufrufen will, und liefert ein Aufruf-Objekt zurück.
{
"function_call": {
"name": "getCustomerOrders",
"arguments": "{\"customerId\": \"abc-123\", \"limit\": 10}"
}
}Der Vorteil ist Pragmatik. Function Calling lässt sich mit ein paar Zeilen Code in eine bestehende Anwendung integrieren, ohne separate Server oder Protokoll-Implementierungen.
Der Nachteil ist Lock-in. Eine Function-Calling-Integration ist an OpenAI gebunden. Wer das Modell wechselt, schreibt die Tool-Schicht neu. Wer mehrere Modelle parallel betreibt, pflegt mehrere Integrations-Pfade. Das war 2023 noch akzeptabel, weil OpenAI praktisch der einzige Anbieter war. 2026 wirkt es zunehmend wie ein Bremsklotz.
In der Praxis hat OpenAI die Function-Calling-API mehrfach erweitert, ohne sie grundlegend zu ändern. parallel_tool_calls für mehrere gleichzeitige Funktions-Aufrufe wurde 2024 eingeführt, strict_mode für strenge Schema-Validierung folgte kurz danach. Diese Erweiterungen sind nützlich, machen aber den Lock-in tiefer, weil sie nicht direkt auf andere Anbieter übertragbar sind.
Tool Use als Anthropic-Pattern
Tool Use ist Anthropics Begriff für dieselbe Grundidee in Claude. Die Mechanik ist ähnlich, die Konzepte unterscheiden sich aber in Details, die in der Praxis Reibung erzeugen.
Anthropic hat Tool Use im Frühjahr 2024 als API-Feature eingeführt. Das Modell entscheidet auf Basis der Konversation, ob es ein Tool aufruft, und liefert ein strukturiertes Tool-Use-Objekt zurück. Die Anwendung führt das Tool aus und gibt das Ergebnis zurück, woraufhin Claude die Konversation fortsetzt.
Die syntaktischen Unterschiede zu OpenAIs Function Calling sind klein, aber existent. Anthropic verwendet tool_use-Objekte mit name, input und id, während OpenAI auf function_call mit name und arguments setzt. Wer eine Tool-Schicht für beide Anbieter bauen will, pflegt zwei parallele Repräsentationen.
Konzeptuell teilen Function Calling und Tool Use mehr, als sie trennt. Beide sind anbieter-spezifische APIs für dasselbe Grundkonzept (strukturierte Funktions-Aufrufe innerhalb einer Konversation). Beide leiden am selben Lock-in-Problem. Beide sind ohne MCP nicht portabel zwischen Modellen.
Anthropic hat darüber hinaus einige eigene Erweiterungen, die in OpenAIs Function Calling nicht direkt ein Pendant haben. tool_choice mit Optionen wie any und auto steuert, ob Claude überhaupt ein Tool aufrufen soll oder zwingend eines aus einer bestimmten Liste. Diese Detailarbeit erinnert daran, dass selbst zwischen den beiden Marktführern subtile Unterschiede in der Tool-Logik bestehen, die in einer geteilten Codebasis abgefangen werden müssen.
Wir haben in einem Pilot-Projekt eine bestehende Function-Calling-Integration parallel auf Claudes Tool Use portiert, um die Modell-Auswahl offen zu halten. Der mechanische Aufwand pro Tool lag bei einer Stunde. Was deutlich länger dauerte, war die Anpassung der Prompt-Strukturen, weil die beiden Modelle auf Tool-Beschreibungen unterschiedlich reagieren. Nach drei Wochen Parallelbetrieb haben wir auf MCP migriert, was beide Modell-Pfade in einer einheitlichen Tool-Definition zusammenfasst.
MCP als anbieter-neutraler Protokoll-Layer
MCP setzt eine Ebene tiefer an. Statt einer modell-spezifischen API definiert es ein Protokoll, das zwischen Agenten und Tool-Servern läuft. Ein MCP-Server stellt Tools bereit, ein MCP-Client (typischerweise ein Agent) konsumiert sie. Welches Sprachmodell im Hintergrund läuft, ist für die Tool-Definition irrelevant.
Die Trennung zwischen Tool-Bereitstellung und Modell-Aufruf hat einen weiteren Effekt, der oftmals erst in der zweiten Iteration auffällt. Tools werden zu eigenständigen Artefakten mit eigenem Lebenszyklus. Sie haben eigene Versionen, eigene Audit-Logs, eigene Berechtigungen und eigene Pflege-Verantwortlichkeit. Was vorher in der Anwendungs-Codebasis verwoben war, wird nun zu einer dedizierten Schicht, die unabhängig vom konsumierenden Agenten und unabhängig vom darunter liegenden Modell betrieben werden kann.
Die Protokoll-Schicht löst zwei Probleme, die Function Calling und Tool Use offen lassen.
Portabilität. Ein MCP-Tool funktioniert mit Claude, ChatGPT, Cursor und jedem anderen Agenten, der das Protokoll unterstützt. Wer das Modell wechselt, lässt die Tool-Schicht unverändert.
Externalisierung. Tools laufen in einem eigenständigen Server-Prozess, nicht eingebettet in die Anwendung, die den Agenten nutzt. Das macht Tools wiederverwendbar zwischen Anwendungen und ermöglicht zentrale Pflege.
Was MCP nicht tut, ist die Ebene innerhalb der Konversation zu ändern. Wenn der Agent ein Tool aufruft, läuft die Aufruf-Mechanik weiterhin über Function Calling oder Tool Use, je nach Modell. MCP übernimmt nur die Verbindung zum externen Tool-Server und das Protokoll-Handling. Die Modell-API darunter bleibt anbieter-spezifisch.
Damit klärt sich auch eine Frage, die in vielen Diskussionen falsch gestellt wird. Es geht nicht darum, ob ein Team Function Calling oder MCP nutzen sollte. Beide werden in der Realität verwendet. Function Calling oder Tool Use sind die Aufruf-Mechanik des Modells, MCP ist der Vermittlungs-Layer zum Tool-Server. Wer eine moderne Agent-Architektur baut, hat in den meisten Fällen beides im Stack, eines pro Schicht.
Wann sich welcher Ansatz lohnt
Die Wahl zwischen den drei Ansätzen folgt einer einfachen Logik, die sich in der Praxis bewährt hat.
| Situation | Empfehlung | Begründung |
|---|---|---|
| Schnell-Prototyp mit einem Modell | Function Calling oder Tool Use direkt | Geringer Aufwand, keine Protokoll-Investition nötig |
| Mehrere Modelle parallel | MCP als Protokoll-Layer | Eine Tool-Schicht statt N anbieter-spezifischer Pfade |
| Modell-Wechsel-Option offen halten | MCP von Anfang an | Vermeidet späteren Migration-Aufwand |
| Tools werden in mehreren Anwendungen genutzt | MCP als Server-Architektur | Zentrale Pflege, keine Duplikation |
Für Enterprise-Setups ist die Antwort meistens MCP. Der Anfangs-Aufwand ist höher als bei direkter Function-Calling-Integration, der Lock-in-Schutz und die Wiederverwendbarkeit zahlen sich aber innerhalb weniger Monate aus.
Für Prototypen und kleine Integrationen ist Function Calling oder Tool Use weiterhin die pragmatischere Wahl. Wer ein Tool für eine einzelne Anwendung mit einem festen Modell baut, braucht den Protokoll-Layer nicht.
In der Praxis sehen wir drei typische Reifegrade. Die erste Stufe ist eine Prototyp-Integration, in der Function Calling direkt aus der Anwendung gegen ein einzelnes Modell läuft. Die zweite Stufe entsteht, wenn das Team feststellt, dass dieselben Tools in mehreren Anwendungen gebraucht werden, woraufhin der Tool-Code in einen eigenen Service ausgelagert wird, oftmals noch mit Function-Calling-API. Die dritte Stufe ist der Wechsel auf MCP als Protokoll-Layer, weil entweder ein Modell-Wechsel ansteht oder die Anzahl der Tool-Konsumenten gewachsen ist und Wiederverwendung wichtiger wird als initiale Geschwindigkeit.
Die Faustregel aus der Praxis lautet so. Sobald mehr als ein Modell oder mehr als eine Anwendung im Spiel ist, lohnt sich MCP. Bei einer einzelnen Anwendung mit einem festen Modell darf Function Calling weiterhin die direktere Wahl sein.
Migrations-Pfade zwischen den Ansätzen
Wer auf Function Calling oder Tool Use gestartet ist und auf MCP migrieren will, hat einen klaren Pfad.
Bestehende Funktions-Definitionen werden zu MCP-Tools übersetzt. Das ist mechanisch trivial, weil Tool-Schemas in beiden Welten als JSON Schema vorliegen. Die Hauptarbeit liegt in der Server-Architektur, nicht in der Tool-Mechanik.
Bestehende Anwendungen werden auf einen MCP-Client umgestellt. Statt direkt Function-Calling-Definitionen an die Modell-API zu übergeben, fragt die Anwendung den MCP-Server nach verfügbaren Tools und übergibt deren Definitionen weiter. Die Modell-API darunter bleibt unverändert.
Eine Migration von Function Calling oder Tool Use zu MCP, die ohne Schema-Review läuft, übernimmt typische Schwächen direkt. Tool-Beschreibungen, die für ein konkretes Modell optimiert wurden, sind in MCP nicht automatisch agent-neutral. Die Migration ist die Gelegenheit, Beschreibungen aus Agent-Sicht statt aus Modell-Sicht zu schreiben.
In den meisten Fällen läuft die Migration in zwei Wochen pro Tool-Familie ab. Was länger dauert, ist die organisatorische Klärung, wer die Tool-Schicht in Zukunft pflegt, weil sie sich vom Anwendungs-Code löst und einen eigenen Lebenszyklus bekommt.
Eine zweite Migrations-Variante lohnt sich für Teams, die noch nicht produktiv mit Function Calling oder Tool Use arbeiten. Sie überspringen die anbieter-spezifische Stufe und starten direkt mit MCP. Der Aufwand am Anfang ist höher, aber sie sparen die spätere Migration komplett. Diese Variante eignet sich besonders für Greenfield-Projekte oder für Teams, die ohnehin eine API-Plattform aufbauen, in der MCP ein integraler Bestandteil ist.
Im Versions-Kontext sei daran erinnert, dass MCP selbst weiterentwickelt wird. Die Auth-Profile, Resource-Definitionen und Streaming-Aspekte haben sich seit November 2024 mehrfach erweitert. Wer eine Migration plant, prüft zuerst, welche MCP-Version der Ziel-Server unterstützen soll, und richtet sich nach den aktuellen Spec-Versionen, um nicht auf einer überholten Variante aufzusetzen.
Wie api-portal.io die drei Ansätze unterstützt
In api-portal.io werden Tools primär über MCP bereitgestellt, mit automatischer Generierung aus OpenAPI-Specs. Bestehende Function-Calling- oder Tool-Use-Integrationen lassen sich über Adapter-Schichten weiternutzen, während die zugrunde liegende Tool-Definition bereits MCP-konform ist. So bleiben Modell-Wechsel und Mehrfach-Verwendung möglich, ohne dass Tool-Schemas neu geschrieben werden müssen.
Der MCP Server übernimmt die Anbindung von APIs an MCP-fähige Clients.