Abstract illustration representing AI models interacting with external tools and systems, symbolizing the Model Context Protocol (MCP) standard.

Model Context Protocol im Vergleich: MCP vs. Function Calling, Plugins, APIs

Wie schneidet das Model Context Protocol (MCP) im Vergleich zu anderen Wegen ab, KI mit Tools zu verbinden? In diesem Artikel zeigen wir, wie sich MCP gegen Function Calling, Plugins, direkte APIs und Agenten-Frameworks schlägt. Außerdem sehen wir uns reale Anwendungsfälle für MCP an und überlegen, wohin uns dieser entstehende Standard führen könnte.

MCP und andere Ansätze für Function Calling

Um den Platz von MCP im KI-Ökosystem zu verstehen, hilft der Vergleich mit anderen Methoden, LLMs an externe Tools und Dienste anzubinden.

Function Calling von OpenAI

OpenAI führte Function Calling 2023 ein. Entwickler können damit Funktionen bei der API registrieren, und Modelle wie GPT-4 rufen sie auf. Das funktioniert so:

  1. Der Entwickler liefert für jede Funktion ein Schema (Name, Parameter, Beschreibung)
  2. Das Modell entscheidet anhand der Anfrage des Benutzers, ob es eine Funktion verwendet
  3. Verwendet es eine Funktion, gibt das Modell ein JSON-Objekt mit dem Funktionsnamen und den Argumenten zurück
  4. Der Code des Entwicklers führt die eigentliche Funktion aus und gibt das Ergebnis an das Modell zurück

Vom Konzept her ähnelt das dem Ablauf bei MCP, aber der Ansatz von OpenAI hat einige Einschränkungen:

  • Er ist fest an die Plattform und das API-Format von OpenAI gebunden
  • Funktionen müssen für jede Sitzung vorab definiert werden
  • Für dauerhafte Sitzungen mit Funktionsanbietern gibt es keine eingebaute Unterstützung
  • Jeder Funktionsaufruf steht im Grunde für sich und wird von zwischengeschaltetem Code verwaltet

MCP begegnet diesen Einschränkungen mit einem modellunabhängigen, dauerhaften Kanal. Jeder MCP-kompatible Client kann jedes Tool aufrufen und einen laufenden Austausch mit zustandsbehaftetem Kontext aufrechterhalten.

Interessanterweise lassen sich die beiden Ansätze kombinieren. Ein Entwickler könnte zum Beispiel eine generische call_mcp_tool-Funktion im Function-Calling-Framework von OpenAI implementieren. Das Modell gibt dann aus, welches MCP-Tool aufgerufen werden soll, und die Funktion leitet das über das MCP-Protokoll weiter.

ChatGPT-Plugins

ChatGPT-Plugins waren ein weiterer Ansatz, um die Fähigkeiten von LLMs zu erweitern. Jedes Plugin definierte seine eigene API (meist über eine OpenAPI-Spezifikation), die ChatGPT aufrufen konnte. Das war innovativ, hatte aber einige Einschränkungen:

  • Jedes Plugin war eine Einzelanfertigung mit eigenem API-Schema und eigener Authentifizierung
  • Plugins waren im Grunde einmalige Verbindungen ohne dauerhafte Sitzungen
  • Nur ChatGPT (oder ähnlich privilegierte Systeme) konnte diese Plugins nutzen
  • Die Authentifizierung lief von Fall zu Fall anders, ohne standardisierten Ablauf

MCP verbessert dieses Modell, weil es ein offener Standard ist, den jede KI-Plattform übernehmen kann. Es unterstützt dauerhafte Verbindungen und standardisierte Authentifizierung (OAuth 2.0) und ist nicht auf das Ökosystem eines einzelnen Anbieters beschränkt.

Eine Analyse bringt es so auf den Punkt: ChatGPT-Plugins sind wie Spezialwerkzeuge in einem geschlossenen Werkzeugkasten, MCP dagegen ist ein Werkzeugset nach offenem Standard, das jedem Entwickler zur Verfügung steht.

Agenten-Frameworks (LangChain usw.)

Bevor es High-Level-Protokolle gab, verbanden viele Entwickler LLMs über Agenten-Frameworks wie LangChain mit externen Tools. Diese Frameworks boten Abstraktionen, bei denen das Modell Befehle wie „Action: search Google“ ausgeben konnte, die das Framework dann ausführte.

Auch diese Ansätze hatten Einschränkungen:

  • Sie waren im Grunde Hacks auf der Textschnittstelle des Modells
  • Verschiedene Tools verwendeten oft uneinheitliche Formate oder Befehlsstrukturen
  • Die Integration war meist auf bestimmte Modelle zugeschnitten
  • Für Tool-Definitionen und Interaktionen gab es keinen einheitlichen Standard

MCP löst das mit einer einzigen Standardschnittstelle. Tools präsentieren sich einheitlich, und jeder konforme Client kann die Interaktion des Modells mit ihnen vermitteln. So liegt die Tool-Logik zentral im Protokoll, statt über den Code verstreut zu sein.

Direkte API-Integration

Der einfachste Ansatz: Man prüft Benutzeranfragen oder Modellantworten von Hand, ermittelt, welche API aufzurufen ist, führt den Aufruf aus und fügt die Ergebnisse wieder in den Kontext des Modells ein.

Das funktioniert, skaliert aber schlecht:

  • Jede neue API braucht eigenen Code
  • Jede Integration ist fragil und modellspezifisch
  • Mehrere APIs zu integrieren wird exponentiell komplex
  • Für Fehlerbehandlung und Authentifizierung gibt es kein Standardverfahren

MCP löst diese Probleme durch Standardisierung. Sobald ein Dienst einen MCP-Server hat, kann ihn jeder kompatible KI-Client ohne zusätzlichen Integrationsaufwand nutzen.

Reale Anwendungen von MCP

Was MCP wirklich kann, zeigt sich erst an realen Anwendungen. Hier sind ein paar Szenarien, in denen die besonderen Eigenschaften von MCP anspruchsvolle KI-Assistenten möglich machen.

Integrierte Entwicklungsumgebungen (IDEs)

Nehmen wir einen KI-Coding-Assistenten in einer IDE wie VS Code oder JetBrains. Mit MCP könnte dieser Assistent:

  1. Über einen Dateisystem-MCP-Server auf Projektdateien zugreifen
  2. Über einen MCP-Server für Codeausführung Code ausführen
  3. Über einen Dokumentations-MCP-Server die Dokumentation abfragen
  4. Über einen Projektmanagement-MCP-Server Tickets in Issue-Trackern anlegen
  5. Über einen Test-MCP-Server Unit-Tests erzeugen

Alle diese Interaktionen folgen demselben Protokollmuster, deshalb lassen sich die Fähigkeiten des Assistenten leicht erweitern. Neue Tools lassen sich hinzufügen, ohne dass man die zentrale KI-Integration ändern muss.

Wenn der Benutzer sagt: „Finde die Performance-Engpässe in diesem Code und lege für jeden ein Ticket an“, kann der Assistent einen komplexen Workflow über mehrere Tools hinweg steuern: den Code profilieren, die Ergebnisse analysieren, Tickets anlegen, und das alles über eine einheitliche Schnittstelle.

Wissensarbeiter in Unternehmen

Für Wissensarbeiter in einem Unternehmen könnte ein MCP-fähiger Assistent:

  1. Über einen Wissensdatenbank-MCP-Server interne Dokumente durchsuchen
  2. Über einen MCP-Server für die Personaldatenbank auf Mitarbeiterdaten zugreifen
  3. Über einen Kalender-MCP-Server Besprechungen planen
  4. Über einen Datenanalyse-MCP-Server Berichte erstellen
  5. Über MCP-Server für Kommunikationsplattformen Inhalte teilen

Das ergibt ein starkes Produktivitätswerkzeug, das sich nahtlos in bestehende Unternehmenssysteme einfügt. Neue Tools müssen nur die MCP-Schnittstelle implementieren, damit der Assistent sie nutzen kann.

Lautet die Anfrage etwa: „Bereite einen Quartalsbericht zum Vertrieb für mein Team vor und plane eine Besprechung dazu“, kann der Assistent Daten aus mehreren Quellen sammeln, Visualisierungen erzeugen, ein Dokument erstellen und die Besprechung ansetzen, alles über einheitliche MCP-Interaktionen.

Smart Home und IoT-Steuerung

Auch abseits des Berufs könnte MCP verändern, wie wir mit Smart-Home-Geräten umgehen. Ein MCP-fähiger Assistent könnte:

  1. Über einen Smart-Home-MCP-Server das Licht steuern
  2. Über einen HVAC-MCP-Server Thermostate einstellen
  3. Über einen Sicherheits-MCP-Server Sicherheitssysteme überwachen
  4. Über MCP-Server für Unterhaltungssysteme Medien abspielen

So entsteht eine einheitliche Schnittstelle für komplexe Szenarien der Hausautomation. „Ich gehe schlafen“ könnte zum Beispiel eine Abfolge von Aktionen über mehrere Systeme auslösen: Licht aus, Temperatur anpassen, Alarmanlage scharf schalten, alles koordiniert über MCP.

Die Stärke der Komponierbarkeit

Besonders stark werden diese Szenarien durch die Komponierbarkeit von MCP. Ein MCP-fähiger Assistent ist nicht auf vordefinierte Workflows angewiesen, sondern kann Tools je nach Anfrage dynamisch kombinieren.

Lautet der Auftrag zum Beispiel: „Recherchiere aktuelle Arbeiten zum Klimawandel, fasse die wichtigsten Ergebnisse zusammen und erstelle eine Präsentation für die Besprechung nächste Woche“, könnte der Assistent:

  1. Mit einem Websuche-MCP-Server aktuelle Arbeiten finden
  2. Mit einem MCP-Server für die PDF-Verarbeitung den Inhalt extrahieren
  3. Mit einem Zusammenfassungs-MCP-Server die wichtigsten Ergebnisse herausarbeiten
  4. Mit einem Präsentations-MCP-Server Folien erstellen
  5. Mit einem Kalender-MCP-Server die Präsentation terminieren

Aus dieser dynamischen Komposition entstehen emergente Fähigkeiten: Der Assistent kann Probleme lösen, für die er nie explizit programmiert wurde, indem er verfügbare Tools auf neue Weise kombiniert.

Die Zukunft von MCP

MCP entwickelt sich weiter, und einige Entwicklungen erscheinen wahrscheinlich:

Ein wachsendes Ökosystem

Weil MCP offen ist, dürfte rund um das Protokoll ein wachsendes Ökosystem kompatibler Server und Clients entstehen. Zu erwarten sind:

  • MCP-Server für beliebte Webdienste und APIs
  • Sprachspezifische MCP-Client-Bibliotheken
  • MCP-Gateway-Dienste, die mehrere Tools bündeln
  • Branchenspezifische Sammlungen von MCP-Servern

Dieses Wachstum macht MCP durch Netzwerkeffekte immer wertvoller, denn jedes neue kompatible Tool und jeder neue Client erhöht den Wert des gesamten Ökosystems.

Mehr Sicherheit und Governance

Mit der wachsenden Verbreitung von MCP, gerade in Unternehmen, werden wahrscheinlich bessere Funktionen für Sicherheit und Governance kommen:

  • Feingranulare Berechtigungsmodelle
  • Audit-Logging und Compliance-Funktionen
  • Integration in die Authentifizierung von Unternehmen
  • Kontrollen für Datenresidenz und Datenschutz

Damit eignet sich MCP auch für sensible Umgebungen, in denen der Zugriff auf Tools sorgfältig kontrolliert werden muss.

Erweiterung auf multimodale Modelle

Aktuelle MCP-Implementierungen konzentrieren sich auf textbasierte LLMs, aber das Protokoll ließe sich auf multimodale Modelle erweitern, die Bilder, Audio und Video verarbeiten. Dazu könnten gehören:

  • Tools für die Analyse und Erzeugung von Bildern
  • Tools für die Audioverarbeitung und Transkription
  • Tools für die Analyse und den Schnitt von Videos

Solche Erweiterungen brächten die Vorteile von MCP in ein breiteres Spektrum von KI-Anwendungen.

Standardisierung und Verbreitung in der Branche

Wenn MCP seinen Wert beweist, könnten formale Standardisierungsbemühungen und eine breitere Verbreitung in der Branche folgen:

  • Branchenkonsortien, die MCP-Erweiterungen definieren
  • Cloud-Anbieter mit MCP-kompatiblen Diensten
  • Hersteller von Unternehmenssoftware, die MCP-Schnittstellen implementieren
  • Betriebssysteme, die MCP als Standardfunktion integrieren

Das würde MCP als universelle Schnittstelle für die Interaktion zwischen KI und Tools festigen.

Herausforderungen und Überlegungen

So vielversprechend MCP ist, es steht vor einigen Herausforderungen:

Konkurrierende Standards

MCP ist nicht der einzige Versuch, die Interaktion zwischen KI und Tools zu standardisieren. Andere Frameworks und Protokolle entstehen gerade, und die Konsolidierung wird dauern. Das Risiko einer Fragmentierung durch mehrere inkompatible Standards bleibt real.

Performance-Overhead

Die zusätzliche Abstraktionsschicht von MCP kostet etwas Performance. Bei latenzkritischen Anwendungen kann das ein Problem sein. Künftige Optimierungen dürften das angehen.

Sicherheitsrisiken

Wie jedes Protokoll, das Automatisierung ermöglicht, wirft MCP Sicherheitsfragen auf. Bösartige MCP-Server könnten versuchen, Schwachstellen in Clients auszunutzen, und kompromittierte Clients könnten legitime Server missbrauchen. Solide Sicherheitspraktiken werden unverzichtbar sein.

Hürden bei der Einführung

Trotz seiner Vorteile stößt MCP bei der Einführung auf Hürden:

  • Altsysteme lassen sich womöglich nur schwer anpassen
  • Organisationen wehren sich womöglich gegen Standardisierung
  • Entwickler bevorzugen womöglich vertraute, wenn auch weniger effiziente Ansätze

Diese Hürden zu überwinden, wird überzeugende Nachweise für den Wert von MCP erfordern.

Fazit

Das Model Context Protocol ist ein deutlicher Fortschritt in der Art, wie KI-Systeme mit externen Tools und Diensten interagieren. Mit einer standardisierten, komponierbaren Schnittstelle für Function Calling begegnet MCP vielen Einschränkungen früherer Ansätze.

Wie wir in dieser Serie gesehen haben, schaffen die Client-Server-Architektur von MCP, das Lifecycle-Management, die dynamische Erkennung und die Interoperabilität die Grundlage für fähigere KI-Assistenten. Diese Assistenten können mehrere Tools kombinieren, um komplexe Probleme zu lösen, den Kontext über Interaktionen hinweg halten und sich an die Bedürfnisse der Benutzer anpassen.

Das wachsende Ökosystem rund um MCP deutet auf eine Zukunft hin, in der sich KI-Assistenten nahtlos in eine Vielzahl digitaler Systeme einfügen, von Webdiensten über Unternehmensanwendungen bis zu Smart-Home-Geräten. Diese Integration wird neue Fähigkeiten und Anwendungsfälle erschließen und KI in unserem Alltag praktischer und wertvoller machen.

Es bleiben Herausforderungen, aber die Richtung ist klar: Wir bewegen uns auf eine Welt zu, in der KI-Systeme externe Tools und Daten über standardisierte Protokolle wie MCP wirksam nutzen können, und das erweitert dramatisch, was mit KI-Assistenten möglich ist.

Als Entwickler, Organisationen und Benutzer tun wir gut daran, die Entwicklung von MCP genau zu verfolgen. Es könnte durchaus zur universellen Sprache werden, über die KI-Systeme mit der digitalen Welt interagieren, eine Entwicklung mit weitreichenden Folgen für die Zukunft der Zusammenarbeit von Mensch und KI.

Aus dem Englischen übersetzt: zum Originalbeitrag

Gestalten Sie die Zukunft Ihres Unternehmens mit KI

Tauchen Sie ein in unsere spannenden Workshops und rüsten Sie Ihr Team mit den Werkzeugen und dem Wissen aus, um im Zeitalter der KI führend zu sein.

Kontaktieren Sie uns
Scroll to top