MCP und Function Calling sind keine konkurrierenden Standards. Wer in Reddit-Threads die beiden als Entweder-oder-Frage behandelt, hat den Kern nicht verstanden. Function Calling ist Phase 1: Das LLM analysiert eine Anfrage und gibt strukturiertes JSON aus, das beschreibt, welches Tool mit welchen Argumenten aufgerufen werden soll. MCP ist Phase 2: die Infrastrukturschicht, die diese Tool-Aufrufe portabel, auffindbar und über jedes Modell und jede Anwendung hinweg ausführbar macht. Das eine ist das Gehirn, das entscheidet. Das andere sind die Hände, die handeln.
Die Verwechslung ist nachvollziehbar. Beide drehen sich um “Tools aufrufen”. Beide produzieren JSON. Beide verbinden LLMs mit externen Systemen. Aber sie arbeiten auf verschiedenen Schichten des Stacks. Und diesen Unterschied zu verstehen, entscheidet darüber, ob Ihr Agent nur mit einem Modell funktioniert oder mit jedem.
Function Calling: Wie LLMs ihre Absicht ausdrücken
Function Calling (auch “Tool Use” genannt) ist der Mechanismus, über den ein LLM strukturierte Daten statt Freitext ausgibt, wenn es eine externe Aktion für nötig hält. Sie definieren Tools als JSON-Schemas, senden diese zusammen mit dem Prompt des Nutzers, und das Modell gibt einen strukturierten Aufruf mit Funktionsname und Argumenten zurück. Ihr Anwendungscode führt dann die eigentliche Funktion aus und schickt das Ergebnis an das Modell zurück.
tools = [{
"type": "function",
"function": {
"name": "wetter_abrufen",
"description": "Aktuelles Wetter für eine Stadt abrufen",
"parameters": {
"type": "object",
"properties": {
"stadt": {"type": "string"}
},
"required": ["stadt"]
}
}
}]
response = client.chat.completions.create(
model="gpt-4o",
messages=[{"role": "user", "content": "Wie ist das Wetter in München?"}],
tools=tools
)
# Modell gibt zurück: {"name": "wetter_abrufen", "arguments": {"stadt": "München"}}
# Ihr Code führt den eigentlichen API-Aufruf aus
Entscheidend: Das Modell führt nie etwas aus. Es erzeugt eine strukturierte Anfrage. Ihre Anwendung parst das JSON, ruft die echte Wetter-API auf und füttert das Ergebnis zurück. Das LLM ist ein Router, kein Executor.
Das Vendor-Lock-in-Problem
Jeder Anbieter implementiert Function Calling anders. OpenAI nutzt einen parameters-Key und gibt tool_calls mit serialisierten JSON-Strings zurück. Anthropic nutzt input_schema und liefert tool_use-Contentblöcke mit inline Objekten. Google Gemini hat eine flache Struktur mit eigenen Key-Namen. Ein Anbieterwechsel bedeutet: Tool-Definitionen umschreiben, Response-Parsing anpassen, Fehlerbehandlung ändern, Dispatch-Logik neu bauen.
Für ein Projekt mit einem einzigen Anbieter ist das egal. Für Teams, die verschiedene Modelle für verschiedene Aufgaben einsetzen, z.B. Claude für Reasoning und GPT-4o für Code-Generierung, wird es schnell teuer.
MCP: Die Ausführungs-Infrastrukturschicht
Das Model Context Protocol löst ein anderes Problem. Von Anthropic im November 2024 entwickelt und inzwischen von der Agentic AI Foundation unter der Linux Foundation verwaltet, standardisiert MCP, wie KI-Anwendungen externe Tools und Datenquellen entdecken, sich mit ihnen verbinden und sie aufrufen.
MCP nutzt eine Client-Server-Architektur mit drei Komponenten:
MCP Host: Ihre KI-Anwendung (Claude Desktop, Cursor, ein eigener Chatbot). Das, womit der Nutzer interagiert.
MCP Client: Middleware innerhalb des Hosts, die Verbindungen zu MCP-Servern verwaltet. Jeder Client hält eine 1:1-Verbindung zu einem bestimmten Server und übernimmt die Protokollverhandlung.
MCP Server: Ein separater Prozess, der ein externes System (GitHub, Postgres, Slack, ein Dateisystem) kapselt und über eine standardisierte Schnittstelle per JSON-RPC 2.0 bereitstellt.
Anders als Function Calling bieten MCP-Server vier Fähigkeitstypen, nicht nur Tools:
- Tools: Aufrufbare Aktionen mit Seiteneffekten (Ticket erstellen, Nachricht senden)
- Resources: Strukturierter Lesezugriff auf Daten (Dateien abrufen, Datenbankeinträge lesen)
- Prompts: Wiederverwendbare Prompt-Templates für häufige Interaktionen
- Sampling: Erlaubt Servern, LLM-Completions über den Client anzufordern, was rekursive agentische Muster ermöglicht
Das Ökosystem ist auf 97 Millionen monatliche SDK-Downloads gewachsen (Python und TypeScript zusammen), mit über 10.000 aktiven öffentlichen Servern. OpenAI, Google, Microsoft und AWS unterstützen MCP nativ in ihren Plattformen.
Sieben Unterschiede, die wirklich zählen
Entwickler auf Reddit fragen ständig: “Soll ich MCP oder Function Calling verwenden?” Die Frage selbst zeigt das Missverständnis. Hier sind die tatsächlichen Unterschiede:
1. Position in der Pipeline. Function Calling arbeitet am Frontend und wandelt natürliche Sprache in strukturierte Tool-Absichten um. MCP sitzt am Backend und liefert die Infrastruktur, um diese Absichten systemübergreifend auszuführen. Es sind aufeinanderfolgende Phasen, keine Alternativen.
2. Standardisierung. Function-Calling-Schemas sind anbieterspezifisch. Jeder Provider hat sein eigenes Format. MCP erzwingt ein einziges, herstellerneutrales Protokoll. Ein Tool einmal auf einem MCP-Server definiert, funktioniert mit Claude, GPT-4o, Gemini und jedem zukünftigen Modell, das MCP spricht.
3. Kopplung. Function Calling bettet Tool-Definitionen direkt in Ihren Anwendungscode ein und bindet sie eng an einen einzelnen Agenten. MCP entkoppelt Tools in separate Serverprozesse und macht sie über Agenten, Teams und Anwendungen hinweg wiederverwendbar, ohne Code zu duplizieren.
4. Discovery. Function-Calling-Tools werden statisch in jeder API-Anfrage definiert. MCP unterstützt dynamische Entdeckung über tools/list und automatische Benachrichtigungen bei Änderungen über tools/list_changed. Ein Agent, der sich mit einem MCP-Server verbindet, muss nicht vorab wissen, welche Tools existieren.
5. Sicherheitsisolation. Bei Function Calling liegen alle API-Credentials in Ihrem Hauptanwendungsprozess. MCP isoliert Credentials pro Server. Ihr Slack-MCP-Server hält nur Slack-Tokens. Ihr Datenbank-Server nur Datenbank-Credentials. Ein Breach bei einem kompromittiert nicht die anderen.
6. Skalierbarkeit. Ein neues Tool via Function Calling hinzufügen heißt: die einbettende Anwendung ändern. Einen neuen MCP-Server hinzufügen heißt: einen unabhängigen Prozess deployen, mit dem sich jeder MCP-Client verbinden kann. Der Unterschied zwischen O(N*M) und O(N+M) bei N Modellen und M Tools.
7. Kontextkosten. Function Calling sendet Tool-Schemas pro Request, aber Sie kontrollieren genau, welche Tools enthalten sind. MCP-Server können Dutzende Tools exponieren, und jeder verbundene Server fügt sein volles Schema zum Kontextfenster hinzu. Fünf MCP-Server mit je 10 Tools können 30% Ihres Kontexts verbrauchen, bevor der Agent überhaupt über die Anfrage nachdenkt. Das ist MCPs meistkritisierter Trade-off.
Der Entscheidungsrahmen: Ein konkretes Flussdiagramm
Hören Sie auf zu fragen “MCP oder Function Calling?” Fragen Sie stattdessen: “Was baue ich?”
Function Calling nutzen, wenn:
- Sie 2-5 Tools haben, die spezifisch für Ihre Anwendungslogik sind (Routing, Validierung, Klassifikation)
- Sie prototypen und in 20 Zeilen Python etwas zum Laufen bringen wollen
- Latenz wichtiger ist als Portabilität (In-Process-Ausführung, kein Netzwerk-Hop)
- Ein einzelner Anbieter ohne Pläne zum Modellwechsel
- Einfache Aufgaben: strukturierte Daten aus Text extrahieren, Support-Tickets kategorisieren, Formulare verarbeiten
Ein Support-Ticket-Klassifikator, der Kundenname, Issue-Typ und Dringlichkeit aus Freitext extrahiert? Function Calling. Die Tool-Definition ist 15 Zeilen, die Ausführung ist In-Process, und es muss mit keinem anderen Modell funktionieren.
MCP nutzen, wenn:
- 10+ Tools über mehrere externe Systeme
- Mehrere Agenten oder Anwendungen dieselben Integrationen brauchen (CRM, Ticketing, Datenbanken)
- Cross-Modell-Kompatibilität wichtig ist (Sie nutzen Claude fürs Reasoning und GPT-4o für Code-Generierung)
- Credential-Isolation eine Sicherheitsanforderung ist, z.B. nach DSGVO-Grundsätzen der Datenminimierung
- Mehrere Teams dieselben Tool-Integrationen konsumieren
- Enterprise Governance: Sie brauchen Audit-Trails, Zugriffskontrolle und zentrales Tool-Management, wie es der EU AI Act für Hochrisiko-KI-Systeme fordert
Eine Vertriebs-KI, die Salesforce-Daten braucht, E-Mails über SendGrid versendet, Aktivitäten in HubSpot loggt und eine interne Analysedatenbank abfragt? MCP. Sie schreiben jede Integration einmal als MCP-Server. Jeder Agent, unabhängig vom Modell, verbindet sich über dasselbe Protokoll.
Das Hybrid-Muster: Wie Produktionssysteme wirklich funktionieren
Die meisten produktiven Agent-Systeme nutzen beide, und die Aufteilung folgt einer klaren architektonischen Linie.
Function Calling übernimmt agentenspezifische Logik innerhalb der Konversationsschleife: Routing-Entscheidungen, Validierungs-Gates, Geschäftsregeln, Formatkonvertierung. Das sind schnelle In-Process-Operationen, die zum Agenten gehören, nicht zur Infrastruktur.
MCP übernimmt geteilte Integrationen auf der Infrastrukturebene: Datenbankzugriff, Drittanbieter-APIs, Dateioperationen, alles, was mehrere Agenten oder Anwendungen brauchen. Diese laufen als separate Prozesse mit eigenen Credentials und eigenem Lebenszyklus.
Nutzeranfrage
→ LLM (Function Calling erzeugt strukturierten Tool-Intent)
→ Anwendung prüft: lokales Tool oder MCP-Tool?
→ Lokal: In-Process ausführen (schnell, kein Netzwerk-Hop)
→ MCP: an MCP-Client weiterleiten → MCP-Server → externer Dienst
→ Ergebnis wird an LLM zur Antwortgenerierung zurückgegeben
Ein konkretes Beispiel aus der DACH-Praxis: Ein Kundenservice-Agent eines deutschen Versicherers nutzt Function Calling für Intent-Klassifikation (Schadensmeldung, Vertragsanfrage oder Beschwerde?) und Routing-Logik (Beschwerden an einen Menschen eskalieren). Für die eigentliche Arbeit nutzt er MCP: Kundendatenbank abfragen, Support-Tickets in Jira erstellen, Follow-up-E-Mails versenden. Die Klassifikation ist agentenspezifisch. Die Integrationen werden von jedem Agenten in der Organisation geteilt.
Auf das Token-Budget achten
Ein Produktionsaspekt, der zu wenig Beachtung findet: MCPs Kontextkosten. Jeder verbundene MCP-Server sendet sein vollständiges Tool-Schema an das LLM. Ein Jira-MCP-Server mit 15 Tool-Definitionen kann 2.000-3.000 Tokens verbrauchen, bevor der Agent eine einzige Nutzernachricht verarbeitet. Fünf Server angebunden, und Sie haben 30% eines 128K-Kontextfensters nur für Tool-Beschreibungen verloren.
Die Lösung: selektive Verbindungen. Verbinden Sie nicht jeden MCP-Server mit jedem Agenten. Nur die Server, die dieser Agent tatsächlich braucht. Manche Teams setzen eine leichtgewichtige Routing-Schicht ein, die MCP-Server dynamisch basierend auf der Nutzeranfrage verbindet, statt alles vorab zu laden.
Sicherheit: Der Teil, den niemand zuerst bespricht
MCPs Credential-Isolation ist ein echter architektonischer Vorteil gegenüber Function Calling. Aber das Protokoll hat seine eigene Angriffsfläche. In den ersten 60 Tagen von 2026 wurden über 30 CVEs im MCP-Ökosystem offengelegt. CVE-2025-6514 im mcp-remote-Paket betraf über 437.000 Umgebungen mit einem CVSS-Score von 9,6. Eine Studie fand, dass 43% der untersuchten MCP-Server Command-Injection-Schwachstellen enthielten.
Das Sicherheitsmodell von Function Calling ist einfacher: Ihre Anwendung hält alle Credentials und führt alle Tools aus. Die Angriffsfläche ist Ihre Anwendung. Mit MCP erweitert sich die Angriffsfläche auf jeden verbundenen Server, die Transportschicht dazwischen und die Tool-Beschreibungen selbst (die manipuliert werden können, um das LLM-Verhalten zu beeinflussen).
Keiner der Ansätze ist grundsätzlich sicherer. Function Calling konzentriert das Risiko. MCP verteilt es. Die richtige Wahl hängt davon ab, ob Sie eine einzelne befestigte Perimeter bevorzugen oder Defense in Depth mit mehr Toren zum Auditieren. Für Unternehmen, die unter der DSGVO operieren, kann MCPs Credential-Isolation ein Argument für das Prinzip der Datenminimierung sein: Jeder Serverprozess hat nur Zugriff auf die Daten, die er braucht.
Häufig gestellte Fragen
Ersetzt MCP das Function Calling?
Nein. MCP und Function Calling arbeiten auf verschiedenen Schichten. Function Calling ist die Art, wie ein LLM strukturierte Tool-Absichten erzeugt (Phase 1). MCP ist die Infrastruktur, die diese Absichten portabel über Modelle und Anwendungen hinweg ausführt (Phase 2). Die meisten Produktionssysteme nutzen beide zusammen.
Wann sollte ich Function Calling statt MCP nutzen?
Nutzen Sie Function Calling für 2-5 agentenspezifische Tools, schnelles Prototyping, latenzkritische Operationen, Deployments mit einem einzigen Anbieter und einfache Aufgaben wie Datenextraktion oder Klassifikation. Function Calling ist schneller (In-Process, kein Netzwerk-Hop) und einfacher zu implementieren für kleine Anwendungsfälle.
Wann sollte ich MCP statt Function Calling nutzen?
Nutzen Sie MCP, wenn Sie 10+ Tools über externe Systeme haben, Cross-Modell-Kompatibilität brauchen, Credential-Isolation für die Sicherheit benötigen, mehrere Agenten dieselben Integrationen teilen, oder Enterprise-Governance-Features wie Audit-Trails und Zugriffskontrolle erforderlich sind.
Welche KI-Anbieter unterstützen MCP in 2026?
Stand März 2026 wird MCP von Anthropic (Ersteller), OpenAI (seit März 2025), Google DeepMind (seit April 2025), Microsoft, AWS, Cloudflare und Bloomberg unterstützt. Das Protokoll wird von der Agentic AI Foundation unter der Linux Foundation verwaltet und hat über 97 Millionen monatliche SDK-Downloads.
Kann ich MCP und Function Calling zusammen nutzen?
Ja, und die meisten Produktionssysteme tun das. Das typische Muster nutzt Function Calling für agentenspezifische Logik (Routing, Validierung, Klassifikation), die In-Process ausgeführt wird, und MCP für geteilte Infrastruktur-Integrationen (Datenbanken, APIs, Dateisysteme), die als separate Serverprozesse laufen.