MCP-Server vs Function Calling: Wähle Deine Waffe

Es ist verlockend. Wirklich.

Jeder LLM-Anbieter hat jetzt Function Calling. OpenAI hat es. Anthropic hat es. Google hat es. Du wählst deinen Favoriten, liest zwanzig Minuten die Doku, definierst deine Funktionen als JSON-Schemas und lieferst aus. Es funktioniert. Deine Demo sieht toll aus. Deine Investoren sind beeindruckt.

Das Problem ist, dass „es funktioniert" und „es funktioniert im großen Maßstab über mehrere Anbieter" zwei völlig verschiedene Aussagen sind. Die erste ist ein Dienstagnachmittag. Die zweite ist ein Vollzeitjob.

Wenn du Function Calling fest an einen einzigen Anbieter verdrahtest, wählst du nicht nur einen Vendor. Du wählst sein Schema-Format, seine Parameter-Konventionen, seine Fehlerbehandlungs-Semantik und seinen Release-Kalender. Du schreibst Glue-Code, der per Definition nicht portabel ist. Und du tust es an der Schicht, wo Portabilität am meisten zählt — der Grenze zwischen deiner Anwendung und der Intelligenz, von der sie abhängt.

Die meisten merken das erst, wenn sie einen zweiten LLM unterstützen müssen. Dann hat der Glue-Code bereits Metastasen gebildet.

Hier eine Übung. Geh in deine Codebase und zähl die Zeilen, die nur dazu da sind, zwischen deinen internen Tool-Definitionen und dem Function-Calling-Format eines bestimmten LLM-Anbieters zu übersetzen.

Eine Integration? Vielleicht hundert Zeilen. Machbar. Zwei Integrationen? Du merkst, dass OpenAI und Anthropic subtil unterschiedliche Meinungen darüber haben, wie man optionale Parameter ausdrückt. Drei? Du pflegst eine Kompatibilitätsmatrix. Fünf? Du hast versehentlich ein Framework gebaut.

Und die Frameworks hören nie auf zu wachsen. Jeder Anbieter ändert seine API jedes Quartal. Manchmal fügen sie Features hinzu. Manchmal deprecaten sie Dinge. Manchmal „verbessern" sie das Schema-Format auf Arten, die deine bestehenden Definitionen am Samstag um 2 Uhr morgens in Produktion brechen.

Die Wartungssteuer bei Multi-Vendor Function Calling ist nicht linear. Sie ist kombinatorisch. Jeder neue Anbieter multipliziert die Angriffsfläche. Jede API-Änderung kaskadiert durch jede Integration. Deine „einfache" Function-Calling-Schicht wird zum fragilsten Teil deines Stacks — die eine Datei, die jeder fürchtet anzufassen.

Niemand setzt diese Kosten ins Architekturdokument. Niemand schätzt sie in der Sprint-Planung. Sie akkumulieren einfach leise, bis du eines Tages merkst, dass die Hälfte deiner Engineering-Zeit dafür draufgeht, Integrationen am Leben zu halten, statt Features zu bauen.

MCP ist kein Produkt. Es ist nicht die API eines Startups. Es ist ein Protokoll. Diese Unterscheidung zählt mehr, als die Leute denken.

Wenn du einen MCP-Server schreibst, beschreibst du deine Tools einmal. Ein Schema. Ein Satz Beschreibungen. Ein Fehlerformat. Das war's. Jeder LLM, der MCP spricht, kann deine Tools entdecken und nutzen, ohne dass du eine einzige Zeile anbieterspezifischen Code schreibst.

Keine Adapter. Keine Versionsmatrizen. Kein „if openai then Format A, elif anthropic then Format B". Das Protokoll ist der Vertrag, und jeder Client, der das Protokoll implementiert, bekommt deine Tools umsonst.

Das ist dasselbe Muster, das HTTP erfolgreich gemacht hat. Niemand schreibt eine andere API für Chrome, Firefox und Safari. Du implementierst das Protokoll und jeder konforme Client funktioniert. MCP macht für KI-Tool-Integration, was HTTP für die Auslieferung von Webinhalten getan hat — es macht die Transportschicht langweilig, damit du dich auf die Anwendungsschicht konzentrieren kannst.

Das praktische Ergebnis: Deine Tool-Definitionen werden zu Assets statt zu Verbindlichkeiten. Du schreibst sie einmal, testest sie einmal, dokumentierst sie einmal. Wenn ein neuer LLM-Anbieter auftaucht, schreibst du nichts um. Du zeigst auf deinen MCP-Server und es funktioniert.

Ich wäre unehrlich, wenn ich das nicht anerkennen würde: Manchmal ist Function Calling die richtige Wahl.

Wenn du eine Anwendung baust, die immer nur einen LLM nutzen wird, und du weißt welchen, und du machst dir da nichts vor — dann ist direktes Function Calling einfacher. Weniger Abstraktion. Weniger bewegliche Teile. Du tauschst Portabilität gegen Direktheit, und manchmal lohnt sich dieser Tausch.

Wenn du anbieterspezifische Features brauchst, die noch kein MCP-Äquivalent haben — Structured-Output-Modi, Computer-Use-APIs oder anbieterspezifisches Streaming — dann macht direkte Integration Sinn. Man kann nicht auf etwas zugreifen, was das Protokoll nicht exponiert.

Und wenn du prototypst, wenn du in der Phase „mach dass es läuft" bist, bringt dich Function Calling schneller ans Ziel. MCP hat Setup-Overhead. Für einen Wochenend-Hackathon ist dieser Overhead real.

Aber hier ist die Frage, die du ehrlich beantworten musst: Beschreibt „ein Anbieter für immer" tatsächlich deine Zukunft? Denn meiner Erfahrung nach sind die Unternehmen, die sagen „wir werden nur OpenAI nutzen", dieselben, die sechs Monate später hektisch Claude-Support einbauen, wenn ihre Nutzer danach fragen. Die, die sagen „wir prototypen nur", sind dieselben, die diesen Prototyp zwei Jahre später immer noch in Produktion laufen haben.

Die Kosten des Umstiegs von Function Calling auf MCP steigen jeden Tag, den du wartest. Die Kosten, mit MCP zu starten, bleiben ungefähr gleich.

Was die meisten übersehen: MCP und Function Calling sind keine Feinde. Sie sind Schichten im selben Stack.

MCP-Tools können als Funktionen an jeden LLM exponiert werden, der Function Calling unterstützt. Das Protokoll ist die Single Source of Truth — die kanonische Beschreibung dessen, was deine Tools tun, was sie akzeptieren und was sie zurückgeben. Die Function-Calling-Adapter werden generiert, nicht von Hand geschrieben. Dein MCP-Server ist die einzige Quelle; die anbieterspezifischen Formate sind Projektionen.

Das heißt, du musst dich nicht entscheiden. Du kannst MCP als Tool-Definitionsschicht haben und trotzdem Function Calling als Auslieferungsmechanismus an jeden LLM nutzen. Der Unterschied ist, dass bei MCP diese Funktionsdefinitionen aus einer einzigen Quelle abgeleitet werden, statt unabhängig pro Anbieter gepflegt zu werden.

Das ist die Richtung, in die die Branche geht, ob sie es weiß oder nicht. Das Muster „eine kanonische Beschreibung, viele abgeleitete Formate" hat in jedem anderen Bereich gewonnen — Datenbankschemas, API-Spezifikationen, Typsysteme. KI-Tool-Integration wird auf dasselbe Muster konvergieren, weil die Alternative eine Wartungslast ist, die schneller wächst als jedes Engineering-Team.

Die Unternehmen, die das jetzt verstehen, werden ihre Zeit damit verbringen, bessere Tools zu bauen. Die, die es später verstehen, werden ihre Zeit damit verbringen, Glue-Code umzuschreiben. Beide Gruppen landen am selben Ort. Die einzige Frage ist, wie viel Zeit sie auf dem Weg dorthin verschwenden.