MCP vs Function Calling: Welche Unterschiede gibt es beim Tool-Aufruf von AI Agenten? JSON Schema, API und Tool Calling im vollständigen Vergleich

Der Agent erzeugt zwar korrekte Tool-Aufrufe, doch jedes neue Modell, jeder weitere Client und jeder Remote-Server bringt eine eigene Integrationskante mit.

Die schnellste Lösung lautet: Function Calling für die Modellentscheidung, MCP für standardisierte Tool-Verbindungen. Bei einer einzelnen Anwendung mit wenigen Tools genügt meist der direkte Weg; erst bei mehreren Clients, gemeinsam genutzten Tools oder zentraler Governance lohnt sich eine MCP-Schicht.

Diese Einordnung ist für folgende Teams relevant:

Einzelanwendungs-Entwickler, die eine unnötig komplexe Plattformarchitektur vermeiden möchten.
Multi-Modell-Teams, die ein gemeinsames internes Aufrufformat und wiederverwendbare Schemas benötigen.
MCP-Verantwortliche, die eine belastbare Migrationsgrenze zwischen direkter API-Integration und MCP festlegen müssen.

Die zwei Ebenen des Tool-Aufrufs

Die zentrale Verwechslung entsteht, weil beide Begriffe im Alltag als Synonyme für „ein Modell benutzt ein Tool“ verwendet werden. Architektonisch liegen sie jedoch nicht auf derselben Ebene.

Function Calling beschreibt den Dialog zwischen Modell und Anwendung:

Die Anwendung übermittelt dem Modell eine Tool-Definition.
Das Modell entscheidet, ob ein Tool benötigt wird.
Es erzeugt den Tool-Namen und strukturierte Argumente.
Die Anwendung validiert diese Argumente und führt den Code oder die API aus.
Das Ergebnis wird an das Modell zurückgegeben, damit es die Antwort fortsetzt.

Das Modell führt die Funktion dabei nicht selbst aus. Die Anwendung bleibt für Extraktion, Validierung, Ausführung und Rückgabe des Ergebnisses verantwortlich. Die offizielle Dokumentation des Gemini API beschreibt genau diese Trennung zwischen Funktionsdeklaration, Modellentscheidung, Anwendungsausführung und anschließender Antwortgenerierung. (ai.google.dev)

MCP, das Model Context Protocol, standardisiert dagegen die Verbindung zwischen einer Host-Anwendung, einem MCP-Client und einem MCP-Server. Ein Server kann Tools, Ressourcen und Prompts anbieten; Tools sind dabei ausführbare Funktionen, während Ressourcen Kontextdaten und Prompts wiederverwendbare Vorlagen darstellen. Die Kommunikation basiert auf JSON-RPC 2.0, ergänzt um Lebenszyklus, Capability-Aushandlung und je nach Transport zusätzliche Autorisierungsmechanismen. (modelcontextprotocol.io)

Daraus folgt eine belastbare Schichtenregel:

Modellseite: Welches Tool passt zur Anfrage?
Schemaebene: Welche Parameter und Rückgabewerte sind zulässig?
Verbindungsebene: Wo ist das Tool erreichbar und wie wird es entdeckt?
Ausführungsebene: Welcher Code oder welche API wird tatsächlich aufgerufen?
Berechtigungsebene: Darf dieser Nutzer diese Aktion in diesem Mandanten ausführen?

MCP beantwortet vor allem die dritte Frage. Function Calling beantwortet vor allem die erste und teilweise die zweite. Keine der beiden Technologien ersetzt die Ausführungsebene oder die fachliche Autorisierung.

JSON Schema als gemeinsamer Vertrag

JSON Schema ist in beiden Architekturpfaden wichtig, aber seine Rolle sollte nicht überschätzt werden. Es definiert die Form von Eingaben und gegebenenfalls Ausgaben. Es beweist nicht, dass eine Aktion fachlich erlaubt, sicher oder idempotent ist.

Bei direktem Function Calling wird das Schema meist als Teil der modellabhängigen Tool-Definition übertragen. Die Implementierung kann beispielsweise festlegen, dass ein Tool customer_id als Zeichenkette und amount als Zahl erwartet. Anbieter unterscheiden sich jedoch bei Feldnamen, Nachrichtenformaten, Tool-Auswahl und strikter Schema-Unterstützung. In der OpenAI API werden Funktionsparameter als JSON-Schema-Objekt beschrieben; ein strikter Modus kann die Einhaltung des Schemas erzwingen, unterstützt aber nur einen Teil des vollständigen JSON-Schema-Umfangs. (platform.openai.com)

MCP definiert für Tools ein inputSchema und optional ein outputSchema. Die offizielle Tools-Spezifikation verlangt für inputSchema ein gültiges JSON-Schema-Objekt und sieht außerdem strukturierte Tool-Ergebnisse vor, die einem definierten Ausgabeschema entsprechen können. (modelcontextprotocol.io)

Für die Architektur bedeutet das:

Ein Schemafehler muss vor der Ausführung abgefangen werden.
Ein fachlich ungültiger Wert kann trotz gültigem Schema vorliegen.
Eine gültige, aber gefährliche Anweisung darf nicht automatisch ausgeführt werden.
Schemaänderungen brauchen Versionierung, Kompatibilitätsregeln und Tests.
Das interne Ereignismodell sollte nicht direkt an das Format eines einzelnen Modellanbieters gebunden sein.

Ein robustes internes Ereignis könnte beispielsweise logisch aus tool_name, arguments, request_id, tenant_id, actor, approval_state und schema_version bestehen. Das ist kein vorgeschriebenes MCP-Format, sondern eine sinnvolle Entkopplung: Das Modellformat darf sich ändern, ohne dass Audit, Berechtigungen und Geschäftslogik neu gebaut werden müssen.

Architektur nach Einsatzszenario

Einzelanwendung mit wenigen Tools

Wenn ein Agent in einer einzigen Backend-Anwendung auf wenige, stabile Tools zugreift, ist direkter Function Calling meist der vernünftigste Startpunkt. Die Anwendung kennt ihre Tool-Liste bereits, kontrolliert den Ausführungscode und muss keinen separaten Discovery-Mechanismus betreiben.

Der zusätzliche MCP-Layer würde in diesem Fall neue Betriebsaufgaben erzeugen:

Server-Prozess oder Transport muss überwacht werden.
Tool-Discovery muss getestet und gecacht werden.
Authentifizierung und Verbindungsfehler kommen zur Anwendung hinzu.
Ein weiteres Versions- und Berechtigungsmodell muss gepflegt werden.
Fehlermeldungen müssen zwischen Modell, MCP-Client und API abgebildet werden.

Das ist kein Argument gegen MCP, sondern gegen eine Einführung ohne konkreten Wiederverwendungsbedarf. Entscheidend ist, dass die direkte Implementierung nicht als unstrukturierter Sonderweg entsteht. Die Tools sollten intern bereits über stabile Schnittstellen, versionierte JSON Schema und klar definierte Fehlerklassen verfügen. Dann bleibt eine spätere MCP-Anbindung eine Adapteraufgabe statt einer vollständigen Neuentwicklung.

Mehrere Modelle und Anbieter

Sobald ein Team Modelle austauschen oder parallel betreiben möchte, entsteht eine andere Belastung. Function Calling ist konzeptionell ähnlich, aber die konkreten API-Formate sind nicht automatisch identisch. Unterschiede können bei Tool-Definitionen, Tool-Choice, Parallelaufrufen, Nachrichtenrollen, Rückgabeformaten, Fehlersignalen und strikter Schema-Prüfung auftreten.

Eine interne Adapter-Schicht ist deshalb oft wichtiger als die sofortige Einführung von MCP. Sie sollte mindestens drei Dinge übernehmen:

Normalisierung: Anbieterformate werden in ein internes Tool-Call-Ereignis umgewandelt.
Validierung: Argumente werden gegen die eigene Schema-Version geprüft.
Ausführung: Die Geschäftslogik erhält ein einheitliches Kommando und liefert ein einheitliches Ergebnis.

MCP kann später die Tool-Verbindung standardisieren, beseitigt aber nicht alle Unterschiede auf der Modellseite. Auch wenn ein MCP-Client eine einheitliche Tool-Liste erhält, muss die Anwendung diese Werkzeuge weiterhin in das jeweilige Modellformat übertragen oder eine Plattform verwenden, die diese Abbildung übernimmt. Dass moderne API-Schnittstellen sowohl eigene Funktionen als auch MCP-Tools als unterschiedliche Tool-Typen behandeln können, zeigt diese Trennung deutlich. (platform.openai.com)

Mehrere Agents und Clients

Der stärkste praktische Grund für MCP liegt nicht in der Anzahl der Funktionen, sondern in der Anzahl der Verbraucher. Wenn dieselben Tools von einem Chat-Agent, einer Entwicklungsumgebung, einem Desktop-Client und einem automatisierten Workflow genutzt werden sollen, wird direkte Function-Calling-Integration schnell redundant.

Ein MCP-Server kann die Tool-Liste über tools/list bereitstellen. Clients können dadurch Fähigkeiten entdecken, statt jede Integration separat fest zu verdrahten. Die Spezifikation sieht außerdem Capability-Ankündigungen und bei Bedarf Änderungen der Tool-Liste vor. (modelcontextprotocol.io)

Der Gewinn besteht vor allem in:

weniger wiederholtem Verbindungs- und Discovery-Code,
einer gemeinsam dokumentierten Tool-Oberfläche,
zentraleren Audit- und Freigabepunkten,
besserer Wiederverwendung über unterschiedliche Hosts hinweg,
klareren Grenzen zwischen Client und Tool-Anbieter.

Dafür muss das Team den Server wie ein produktives Integrationssystem betreiben. Dazu gehören Versionskompatibilität, Authentifizierung, Scope-Begrenzung, Protokollierung, Ausfallverhalten und eine Regel für inkompatible Tool-Änderungen. Ein MCP-Server mit unklarer Besitzverantwortung verlagert die Komplexität nur an eine andere Stelle.

Remote-Tools und macOS-Abhängigkeiten

Bei Remote-MCP verändert sich die Risikoklasse. Ein lokaler Prozess kann auf Dateien, Schlüsselbund, Entwicklerwerkzeuge oder angeschlossene Geräte zugreifen. Ein entfernter Server benötigt dagegen einen belastbaren Transport, Identitätsprüfung, Netzwerkregeln, Überwachung und ein definiertes Verhalten bei Verbindungsabbruch.

Besonders kritisch sind Tools, die macOS-Ressourcen benötigen, etwa Xcode-Builds, signierte Artefakte, Simulatoren, bestimmte Entwicklerwerkzeuge oder lokale Projektdateien. MCP verlangt nicht, dass diese Tools auf macOS betrieben werden. Das Betriebssystem ist eine Deployment-Entscheidung, keine Protokolleigenschaft. Wenn ein Tool jedoch tatsächlich macOS benötigt, kann ein kontrolliert betriebenes Remote-Mac-System die Ausführung kapseln.

Für solche Szenarien sollten Teams mindestens prüfen:

Welche Daten verlassen das lokale Netzwerk?
Welche Identität wird an den MCP-Server weitergegeben?
Welche Tools sind pro Nutzer, Projekt und Mandant sichtbar?
Wie wird ein abgebrochener oder wiederholter Aufruf behandelt?
Wo landen Logs, Eingaben, Ergebnisse und Genehmigungsnachweise?
Wie wird der Zugriff beendet, wenn ein Projekt oder Token widerrufen wird?

Bei personenbezogenen Daten muss die technische Architektur außerdem zur eigenen DSGVO-Bewertung passen. Eine Datenschutz- und Sicherheitsprüfung für Mac-Umgebungen sollte nicht erst nach der Einführung des Remote-Servers beginnen.

Erfahrung aus der Umsetzung: Ein „read-only“-Label reicht nicht als Sicherheitsmodell. Auch ein Lese-Tool kann vertrauliche Daten an einen Agent-Kontext übergeben, in dem sie anschließend in Logs, Prompts oder Folgetools sichtbar werden.

Hochriskante Schreibaktionen

Bei einer Rechnungserstellung, einer Datenlöschung, einem Produktions-Deployment oder einer Änderung von Zugriffsrechten darf weder Function Calling noch MCP als alleinige Sicherheitskontrolle gelten.

Eine tragfähige Schutzarchitektur arbeitet mit mehreren Ebenen:

Modellsteuerung: Das Modell darf nur aus einer begrenzten Tool-Liste auswählen.
MCP- oder Gateway-Ebene: Der Server prüft Identität, Scope, Zielsystem und erlaubte Operation.
Geschäfts-API: Die fachliche Autorisierung wird unabhängig vom Agent erneut geprüft.
Bestätigungsebene: Der Nutzer bestätigt riskante oder irreversible Aktionen.
Audit-Ebene: Anfrage, Tool-Version, Schema-Version, Ergebnis und Freigabe werden nachvollziehbar protokolliert.

Die MCP-Spezifikation betont ausdrücklich Nutzerzustimmung, Datenkontrolle und Vorsicht bei Tool-Aufrufen. Sie weist zugleich darauf hin, dass das Protokoll diese Sicherheitsprinzipien nicht vollständig auf Protokollebene erzwingen kann. (modelcontextprotocol.io)

Ein gültiges JSON Schema sagt nur: „Die Daten haben die erwartete Struktur.“ Es sagt nicht: „Dieser Nutzer darf diesen Datensatz ändern“ oder „Diese Aktion wurde vom Nutzer verstanden und bestätigt“. Für Schreibaktionen muss deshalb ein approval_state oder ein vergleichbarer Freigabestatus Teil des internen Ausführungsmodells sein.

Umsetzungsplan für die Migration

Eine schrittweise Prüfung verhindert, dass ein Team MCP aus strategischen Gründen einführt, ohne die tatsächliche Betriebsgrenze zu kennen.

1. Tool-Inventar erstellen

Für jedes Tool werden Zweck, Eingaben, Rückgaben, Datenklassifizierung, Seiteneffekte, benötigte Betriebssystemressourcen und Ziel-API dokumentiert. Dabei sollte zwischen lesenden, berechnenden und schreibenden Funktionen unterschieden werden.

2. Internes Aufrufformat definieren

Die Geschäftslogik sollte nicht direkt mit einem anbieterspezifischen Nachrichtenobjekt arbeiten. Ein internes Ereignis mit Tool-Name, Argumenten, Korrelations-ID, Nutzerkontext, Schema-Version und Freigabestatus bildet die stabile Grenze.

3. JSON Schema versionieren

Für jede Eingabe und Ausgabe werden Pflichtfelder, erlaubte Werte, zusätzliche Eigenschaften und Abwärtskompatibilität festgelegt. Schema-Tests sollten sowohl gültige als auch absichtlich fehlerhafte Aufrufe enthalten.

4. Direkten Function-Calling-Pfad testen

Das Team implementiert ein minimales Beispiel, bei dem das Modell ein Tool anfordert, die Anwendung die Argumente prüft, die API ausführt und das Ergebnis zurückgibt. Dabei werden Timeout, ungültiges JSON, unbekannter Tool-Name, doppelte Anfrage und API-Fehler separat behandelt.

5. Dasselbe Tool über MCP exponieren

Anschließend wird genau dieses Tool über einen MCP-Server angeboten. Verglichen werden nicht nur die erfolgreichen Aufrufe, sondern auch Discovery, Authentifizierung, Berechtigungsfehler, Server-Ausfall, Schema-Ablehnung und Nutzerbestätigung.

6. Client- und Modellmatrix prüfen

Für jeden vorgesehenen Client wird dokumentiert, wie Tool-Definitionen, Tool-Auswahl, Streaming, parallele Aufrufe, Fehler und strukturierte Ergebnisse behandelt werden. Ein Protokollstandard macht eine Client- oder Modellprüfung nicht überflüssig.

7. Rollback und Governance festlegen

Vor dem Produktivbetrieb muss klar sein, wie ein MCP-Server deaktiviert, auf eine frühere Tool-Version zurückgesetzt oder auf direkte Ausführung umgeschaltet wird. Für Remote-Mac-Tools gehören zusätzlich Session-Begrenzung, Zugriffsentzug und die sichere Löschung temporärer Arbeitsdaten in den Ablauf. Für die technische Umgebung kann eine verwaltete Mac-Remote-Umgebung sinnvoll sein, wenn reproduzierbare Builds oder kontrollierte macOS-Ressourcen benötigt werden.

FAQ zur Architekturentscheidung

Wird MCP Function Calling ersetzen?

Nein. Function Calling beschreibt, wie das Modell einen Tool-Aufruf auswählt und Argumente erzeugt. MCP standardisiert dagegen die Verbindung zu Tools, Ressourcen und Prompts. Ein einzelner Agent kann direkt mit Function Calling arbeiten, während mehrere Clients von MCP profitieren. In einer kombinierten Architektur bleibt Function Calling die Modellseite und MCP die Integrationsseite.

Auf welcher Ebene liegen MCP und Tool Calling?

Tool Calling liegt zwischen Modell und Anwendung. Das Modell erhält eine Beschreibung, wählt ein Tool und produziert strukturierte Parameter. MCP liegt zwischen Host-Anwendung und externem Server. Der MCP-Client entdeckt dort verfügbare Fähigkeiten und leitet Aufrufe weiter. Die Geschäfts-API und ihre Berechtigungen liegen nochmals darunter und dürfen nicht durch das Protokoll ersetzt werden.

Braucht ein einzelner Agent überhaupt MCP?

Nicht zwingend. Bei einer einzigen Anwendung und wenigen stabilen Funktionen ist direkter Function Calling meist einfacher zu testen und zu betreiben. MCP wird sinnvoll, wenn mehrere Agents oder Clients dieselben Tools verwenden, wenn Tools unabhängig deployt werden sollen oder wenn zentrale Governance benötigt wird. Die interne Schnittstelle sollte auch ohne MCP sauber versioniert sein.

Kann MCP eine Geschäfts-API direkt ausführen?

Ein MCP-Server kann hinter einem Tool eine Geschäfts-API aufrufen. Der Server ist jedoch nur die Integrationshülle. Authentifizierung, fachliche Autorisierung, Mandantentrennung, Idempotenz, Rate Limits und Validierung müssen weiterhin in der Ausführungsschicht und der API liegen. Bei Schreibaktionen kommt eine explizite Bestätigung hinzu, sofern die Operation nicht vollständig reversibel ist.

Wie lassen sich MCP und Function Calling kombinieren?

Die Anwendung liest die MCP-Tool-Liste ein, überführt Tool-Namen und JSON Schema in das Format des jeweiligen Modells und empfängt anschließend den erzeugten Function-Call. Danach wird dieser Aufruf über den MCP-Client an den Server weitergeleitet. Das interne Ereignismodell verbindet beide Seiten und verhindert, dass Anbieterformate die Geschäftslogik bestimmen.

Entscheidungstabelle für drei Architekturpfade

Die folgende Tabelle ist eine redaktionelle Entscheidungsbewertung, kein Leistungsbenchmark. Die Punktzahl bewertet die Eignung des jeweiligen Pfads für den beschriebenen Einsatzbereich auf einer Skala von 1 bis 5.

Architekturpfad	Geeignet für	Tool- und Client-Situation	Governance und Betrieb	Redaktionelle Bewertung
Nur Function Calling	Einzelne Anwendung mit wenigen stabilen Tools	Direkte Tool-Definition im Backend, ein Modell oder überschaubare Modellauswahl	Geringster Betriebsaufwand, Berechtigungen bleiben in der Anwendung und API	5/5 bei kleinem Umfang
Function Calling plus interne Adapter-Schicht	Multi-Modell-Plattformen und schrittweise Migration	Mehrere Modellformate, gemeinsames internes Ereignismodell, Tools zunächst direkt ausgeführt	Gute Entkopplung ohne sofortigen Serverbetrieb; Adapter müssen gepflegt werden	5/5 bei Modellvielfalt
Function Calling plus MCP	Mehrere Agents, IDEs, Desktop-Clients oder gemeinsam genutzte Remote-Tools	Tool-Discovery über MCP, Modellanbindung über Function Calling oder Plattformadapter	Höherer Betriebsaufwand, dafür zentrale Wiederverwendung, Authentifizierung und Auditierbarkeit	5/5 bei Client- und Governance-Bedarf

Die Auswahl sollte nicht nach der bloßen Anzahl von Funktionen erfolgen. Ein Agent mit vielen internen Hilfsfunktionen kann weiterhin mit direktem Function Calling gut beherrschbar sein, während wenige, aber von vielen Clients gemeinsam verwendete Tools früh von MCP profitieren.

Bewertungslogik für die Entscheidung

Für die konkrete Architekturentscheidung gelten vier Rückfragen:

Wie viele unabhängige Clients sollen dasselbe Tool verwenden? Bei nur einem Client spricht die Einfachheit für direkten Function Calling. Bei mehreren Clients steigt der Nutzen standardisierter Discovery.
Wie häufig wechseln Modelle oder Anbieter? Bei häufigem Wechsel ist eine interne Adapter-Schicht der erste Pflichtbaustein. MCP allein löst die Modellformat-Differenzen nicht.
Muss der Tool-Server unabhängig deployt und überwacht werden? Wenn ein eigenes Team, ein eigener Lebenszyklus und Remote-Betrieb erforderlich sind, ist MCP organisatorisch plausibler.
Wie kritisch sind die Aktionen? Je höher das Risiko, desto wichtiger sind getrennte Freigabe-, Autorisierungs- und Audit-Schichten, unabhängig vom gewählten Protokoll.

Teams sollten deshalb nicht mit der Frage „MCP oder Function Calling?“ beginnen, sondern mit der Frage „Welche Grenze soll standardisiert werden?“. Bei einem einzelnen Backend ist die Modell-zu-Anwendung-Grenze meist ausreichend. Bei gemeinsam genutzten Tools muss zusätzlich die Anwendung-zu-Tool-Grenze standardisiert werden.

Für lokale Entwicklungs- und Build-Tools kommen weitere Anforderungen hinzu: Dateisystemrechte, Schlüsselverwaltung, Signierung, Simulatorzugriff und reproduzierbare Umgebungen. Eine Mac-Support- und Betriebsplanung kann dabei helfen, Protokollfragen von macOS-spezifischen Ausführungsrisiken zu trennen.

Direkte Ausführung oder Remote-Mac-Umgebung

Für ein kleines internes Toolset ist eine lokale oder bereits vorhandene Backend-Ausführung häufig die bessere Wahl. Eine Remote-Mac-Umgebung bringt nur dann einen konkreten Vorteil, wenn macOS-Ressourcen benötigt werden, mehrere Clients dieselbe Umgebung nutzen sollen oder isolierte, zeitlich begrenzte Ausführungsumgebungen Teil des Betriebsmodells sind.

Die direkte Variante hat jedoch reale Grenzen: lokale Rechner sind nicht immer verfügbar, Zustände können zwischen Entwicklern abweichen, Zugriffsrechte werden oft manuell gepflegt und ein dauerhaft erreichbarer MCP-Server ist schwerer zentral zu überwachen. Bei einem gemeinsam betriebenen Remote-System kommen zwar Netzwerk- und Identitätsfragen hinzu, dafür lassen sich Zugriff, Lebenszyklus und Rücknahme der Umgebung klarer organisieren.

Daher lautet die praktische Empfehlung: Nicht für MCP allein eine Mac-Umgebung mieten. Wenn die Entscheidungstabelle jedoch auf gemeinsam genutzte macOS-Tools oder einen dauerhaft erreichbaren Remote-MCP-Server zeigt, ist eine isolierbare und zurücknehmbare Mac-Umgebung von Zilmac eine realistische Option. Für langfristig gleichbleibende Hochlast, spezielle physische Anschlüsse oder vollständig lokale Datenverarbeitung kann ein eigener Mac weiterhin passender sein.