MCP vs Function Calling vs Plugins: Der Unterschied

Du hörst ständig „MCP”, „Function Calling” und „Plugins” – oft im selben Satz, oft so, als wären sie dasselbe. Sind sie aber nicht. Sie lösen verwandte Probleme (eine KI mit der echten Welt verbinden), arbeiten aber auf unterschiedlichen Ebenen. Wer das einmal sauber sortiert hat, versteht plötzlich, warum alle gerade über MCP reden.

Dieser Artikel gehört zu unserem Hub Was ist ein MCP-Server? Model Context Protocol einfach erklärt. Wenn dir der Begriff MCP noch gar nichts sagt, fang am besten dort an.

Die kurze Antwort

Function Calling ist die Fähigkeit eines Modells, ein Tool aufzurufen; MCP ist ein offener Standard, wie diese Tools angebunden werden; Plugins waren der frühere, plattform-spezifische Versuch desselben.

Anders gesagt: Diese drei Begriffe liegen nicht nebeneinander, sondern teilweise übereinander.

Function Calling ist die Basis-Mechanik. Das KI-Modell sagt „ich möchte jetzt die Funktion wetter(stadt) mit stadt=Berlin aufrufen”.
MCP (Model Context Protocol) ist ein offener Standard, der definiert, wie Tools, Daten und Prompts an eine KI angedockt werden – einmal gebaut, überall nutzbar.
Plugins waren der ältere, herstellergebundene Ansatz (z. B. ChatGPT-Plugins), bei dem jede Plattform ihr eigenes Süppchen kochte.

Wenn du nur eine Sache mitnimmst: Function Calling ist das Was, MCP ist das standardisierte Wie, und Plugins waren das alte, fragmentierte Wie.

Begriff	Ebene	Standardisiert?	Heute relevant?
Function Calling	Modell-Fähigkeit	herstellerspezifisch	Ja, Grundbaustein
MCP	Verbindungs-Protokoll	offener Standard	Ja, im Aufwind
Plugins	Plattform-Integration	proprietär	kaum noch

Function Calling erklärt

Function Calling bedeutet, dass ein KI-Modell strukturiert sagen kann, welches Tool es mit welchen Werten aufrufen will – ausführen muss das Tool aber dein Code.

Ein Sprachmodell kann von sich aus keine E-Mail verschicken, keine Datenbank abfragen und das aktuelle Wetter nicht kennen. Es kann nur Text erzeugen. Function Calling ist der Trick, der das umgeht: Du beschreibst dem Modell vorab eine Liste von Funktionen („Tools”) – Name, Zweck, erwartete Parameter. Das Modell entscheidet dann selbst, wann eine davon nützlich ist, und gibt strukturiert (meist als JSON) zurück, was es aufrufen will.

Der Ablauf in vier Schritten:

Du gibst dem Modell eine Tool-Beschreibung mit (z. B. „wetter(stadt) – liefert das aktuelle Wetter”).
Der Nutzer fragt: „Wie ist das Wetter in Berlin?”
Das Modell antwortet nicht mit Text, sondern mit einem Aufruf-Wunsch: wetter(stadt="Berlin").
Dein Programm führt die Funktion aus, holt das Ergebnis und gibt es zurück ans Modell, das daraus eine schöne Antwort formuliert.

Wichtig: Das Modell ruft nichts selbst auf. Es schlägt nur vor. Die Ausführung – und damit die Kontrolle – liegt bei deinem Code.

Das Problem dabei: Jeder Anbieter macht das etwas anders. Wie genau du Tools definierst, sieht bei verschiedenen KI-Anbietern unterschiedlich aus, und jede neue Integration musst du pro Modell und pro Tool von Hand verdrahten. Bei einem Tool ist das egal. Bei fünfzig wird es zur Fleißarbeit. (Zur Prüfung: Die exakten Feld-Namen der jeweiligen APIs ändern sich – schau für Code immer in die aktuelle Doku des Anbieters.)

Was MCP anders macht

MCP standardisiert die Verbindung zwischen KI und Tools, sodass du eine Integration einmal baust und sie mit jeder MCP-fähigen App funktioniert.

Das Model Context Protocol ist ein offener Standard, den Anthropic am 25. November 2024 vorgestellt hat. Die Idee dahinter wird oft als „USB-C für KI-Anwendungen” beschrieben: ein einheitlicher Stecker, statt für jedes Gerät ein eigenes Kabel.

Der Unterschied zu reinem Function Calling liegt im Wo und Wie oft:

Bei klassischem Function Calling lebt jede Tool-Definition in deiner App und ist an einen Anbieter gekoppelt. Wechselst du das Modell oder baust eine zweite App, fängst du im Zweifel neu an.
Bei MCP liegt die Funktionalität in einem eigenständigen MCP-Server. Jede MCP-fähige App (der „Host”) kann sich über einen standardisierten Client mit diesem Server verbinden. Einmal gebaut – von vielen genutzt.

MCP definiert dabei drei Dinge, die ein Server anbieten kann: Tools (Aktionen, die die KI ausführen darf – das ist die Brücke zum Function Calling), Resources (Daten, die die KI lesen kann) und Prompts (vorgefertigte Vorlagen). Die Architektur folgt dem Host-Client-Server-Muster – wer ist wer, erklären wir ausführlich im Hub Was ist ein MCP-Server?.

Der Clou: MCP ersetzt Function Calling nicht – es baut darauf auf. Wenn ein MCP-Server ein Tool bereitstellt, nutzt das Modell im Hintergrund weiterhin seinen Function-Calling-Mechanismus, um es aufzurufen. MCP kümmert sich um die Standardisierung der Verkabelung drumherum, damit nicht jeder alles neu erfindet.

Wenn du das praktisch ausprobieren willst, zeigt dir MCP-Server mit Claude (Code) verbinden, wie das konkret aussieht.

Und was waren Plugins?

Plugins waren der frühere, plattformgebundene Ansatz, einer KI externe Funktionen beizubringen – bekannt vor allem durch ChatGPT-Plugins, heute weitgehend abgelöst.

Bevor MCP da war, gab es schon das Bedürfnis, KI-Chatbots mit externen Diensten zu verbinden – Flüge suchen, Restaurants buchen, Tabellen abfragen. Die Antwort darauf hieß damals „Plugins”. Das Konzept: Ein Anbieter (etwa ein Reiseportal) schreibt eine Integration nach den Vorgaben einer bestimmten Plattform, und Nutzer dieser Plattform können sie aktivieren.

Das Problem war genau diese Plattform-Bindung. Ein Plugin für Plattform A funktionierte nicht auf Plattform B. Jeder Anbieter musste seine Integration mehrfach pflegen – ein Fall von „M Tools × N Plattformen = zu viel Arbeit”. Genau diese Fragmentierung will MCP auflösen: ein Standard statt vieler proprietärer Insellösungen.

Der Begriff „Plugin” lebt heute noch weiter – etwa als Verpackung, mit der Tools (inklusive MCP-Server, Skills und Befehle) gebündelt und installiert werden. Aber als eigene Methode, eine KI mit der Außenwelt zu verbinden, sind die klassischen Chatbot-Plugins der Vergangenheit weitgehend von Function Calling und MCP überholt worden.

Wann nimmst du was?

Für einen einzelnen, app-internen Tool-Aufruf reicht Function Calling; sobald du Integrationen wiederverwenden oder teilen willst, lohnt sich MCP; reine Plugins baust du heute kaum noch neu.

Eine Faustregel:

Du baust eine einzige App mit ein, zwei Tools? Direktes Function Calling ist schnell und völlig ausreichend. Kein Grund, ein Protokoll daraufzusetzen.
Du willst dieselbe Integration in mehreren Apps nutzen, im Team teilen oder fertige Integrationen anderer einbinden? Dann ist MCP der richtige Weg. Du baust (oder installierst) einen MCP-Server einmal und verbindest ihn mit allem, was MCP spricht.
Du nutzt eine fertige KI-App (z. B. Claude Desktop oder Claude Code) und willst sie erweitern? Such nach einem passenden MCP-Server, statt selbst Function-Calling-Code zu schreiben.
Plugins? Als Endnutzer triffst du sie noch als Verpackungsformat. Als Entwickler ist „neues Chatbot-Plugin nach altem Muster bauen” selten noch die richtige Wahl.

Kurz: Je mehr Wiederverwendung und je mehr Apps im Spiel sind, desto stärker spricht alles für MCP. Für den schnellen Einzelfall bleibt Function Calling unschlagbar simpel.

Wie es weitergeht

Die volle Abgrenzung: Skills vs MCP vs Subagents
Wozu das Ganze: was ein KI-Agent ist
Selbst bauen: einen eigenen MCP-Server erstellen

FAQ: Häufige Fragen zu MCP, Function Calling & Plugins

Ist MCP dasselbe wie Function Calling?

Nein. Function Calling ist die Fähigkeit eines Modells, strukturiert einen Tool-Aufruf vorzuschlagen. MCP ist ein offener Standard, der regelt, wie solche Tools (und Daten und Prompts) an eine KI angebunden werden. MCP nutzt Function Calling im Hintergrund – es ersetzt es nicht, sondern standardisiert die Verkabelung drumherum.

Ersetzt MCP Function Calling?

Nein, MCP baut darauf auf. Wenn ein MCP-Server ein Tool anbietet, ruft das Modell es weiterhin über seinen normalen Function-Calling-Mechanismus auf. MCP sorgt nur dafür, dass die Anbindung standardisiert und wiederverwendbar ist, statt für jede App und jeden Anbieter neu gebaut zu werden.

Was ist der Unterschied zwischen MCP und Plugins?

Plugins waren plattformspezifisch: Eine Integration funktionierte nur auf der Plattform, für die sie gebaut wurde. MCP ist ein offener, herstellerübergreifender Standard – ein MCP-Server funktioniert mit jeder MCP-fähigen App. MCP löst damit genau die Fragmentierung, an der der alte Plugin-Ansatz krankte.

Wann sollte ich Function Calling statt MCP verwenden?

Wenn du eine einzelne App mit wenigen Tools baust, ist direktes Function Calling schneller und einfacher. MCP lohnt sich, sobald du Integrationen über mehrere Apps hinweg wiederverwenden, im Team teilen oder fertige Server anderer einbinden willst.

Wer hat MCP erfunden?

MCP wurde von Anthropic entwickelt und am 25. November 2024 als offener Standard veröffentlicht. Es ist nicht an Claude gebunden – jede App und jedes Modell kann MCP unterstützen.

Fazit

MCP, Function Calling und Plugins sind keine Konkurrenten auf derselben Ebene. Function Calling ist die Mechanik, mit der ein Modell Tools anstößt. Plugins waren der erste, plattformgebundene Versuch, das nutzbar zu machen – heute weitgehend Geschichte. Und MCP ist der offene Standard, der das Anbinden von Tools vereinheitlicht, damit du Integrationen einmal baust und überall nutzt.

Der nächste Schritt: Verstehe die Architektur dahinter im Hub Was ist ein MCP-Server? – oder probier es direkt aus mit MCP-Server mit Claude (Code) verbinden.