Transcription
Damit große Sprachmodelle wirklich nützlich sind, müssen sie oft mit externen Datenquellen, Diensten und Werkzeugen interagieren. Und bis vor kurzem geschah dies typischerweise über Application Programming Interfaces oder APIs. Nun, Ende 2024, hat Anthropic ein neues offenes Standardprotokoll eingeführt, das Model Context Protocol oder MCP. Und es hat bereits für viel Aufsehen gesorgt und standardisiert, wie Anwendungen LLMs Kontext bereitstellen. Lassen Sie uns also diese beiden Begriffe MCP und API definieren und ihre Gemeinsamkeiten und Unterschiede betrachten.
Eine gute Metapher für MCP ist, dass es so etwas wie ein USB-C-Anschluss für Ihre KI-Anwendungen ist, und das liegt daran, dass es Verbindungen zwischen KI-Anwendungen, LLMs und externen Datenquellen standardisiert. Wenn Sie also an Ihren normalen Laptop denken, den Sie vielleicht benutzen. Nun, der hat wahrscheinlich eine Reihe von USB-C-Anschlüssen. Das ist ein sehr alter. Und in diese Anschlüsse können Sie alle möglichen Kabel stecken, und sie werden den USB-C-Standard verwenden, um mit allen Arten von Peripheriegeräten zu interagieren. Vielleicht haben Sie eines dieser Dinge an einen Monitor angeschlossen. Ein anderes ist mit einer externen Festplatte verbunden, und vielleicht haben Sie auch ein Netzteil für das dritte hinzugefügt. Es spielt wirklich keine Rolle, wer die Peripheriegeräte herstellt, sie funktionieren alle zusammen nach diesem gemeinsamen Standard. Nun, MCP ist so etwas.
Wenn wir uns ansehen, was wirklich darin enthalten ist, gibt es einen MCP-Host, und dieser führt auch eine Reihe von MCP-Clients aus. Nun öffnet jeder Client eine JSON RPC 2.0-Sitzung über das Protokoll, das mit MCP geliefert wird, also das MCP-Protokoll, und das verbindet sich mit externen MCP-Servern. Wir haben hier also eine Client-Server-Beziehung. Nun, Server, die bieten Fähigkeiten an. Vielleicht haben wir einen Server für den Zugriff auf eine Datenbank, vielleicht haben wir einen anderen, der uns Zugriff auf ein Code-Repository gibt. Und dann haben wir vielleicht einen weiteren Server, der uns zu einem E-Mail-Server bringt. Wenn wir also zur USB-C-Analogie zurückkehren, können wir den Laptop als eine Art MCP-Host betrachten. Das MCB-Protokoll, das ist wirklich das, was durch die USB-C-Verbindung signalisiert wird. Und dann die Festplatte, der Monitor und das Netzteil. Wir können diese wirklich als MCP-Server betrachten.
Okay, das ist die Architektur, aber was sind die Fähigkeiten von MCP? Nun, es adressiert zwei Hauptbedürfnisse von LLM-Anwendungen. Und wenn ich von LLM-Anwendungen spreche, meine ich insbesondere KI-Agenten. Und diese beiden Bedürfnisse sind zum einen die Bereitstellung von Kontext in Form von kontextuellen Daten und zum anderen die Ermöglichung von Werkzeugen und der Nutzung von Werkzeugen durch diese KI-Agenten. Es bietet also eine standardisierte Möglichkeit für einen KI-Agenten, externen Kontext abzurufen, was Dinge wie Dokumente, Wissensbasis-Einträge und Datenbankdatensätze und dergleichen bedeutet, und es kann auch Aktionen oder Werkzeuge ausführen, wie vielleicht eine Websuche durchführen, einen externen Dienst aufrufen oder einige Berechnungen durchführen.
Das alles geschieht über diesen MPC-Server, den ich erwähnt habe, und der eine Reihe von Primitiven bewirbt. Lassen Sie uns drei davon betrachten. Eines der Primitiven heißt Werkzeuge, und Werkzeuge sind diskrete Aktionen oder Funktionen, die die KI aufrufen kann. Ein Wetterdienst könnte also ein "get weather"-Werkzeug anbieten, oder ein Kalenderdienst könnte ein "create event"-Werkzeug anbieten. Der Servername bewirbt den Namen jedes Werkzeugs, seine Beschreibung, das Eingabe- und Ausgabeschema in seiner Fähigkeitsliste. Wenn ein LLM einen MCP-Client verwendet, um ein Werkzeug aufzurufen, führt der MCP-Server die zugrunde liegende Funktion aus. Das sind also Werkzeuge.
Ein weiteres Primitiv sind Ressourcen. Und Ressourcen sind schreibgeschützte Datenelemente oder Dokumente, die der Server bereitstellen kann. Die der Client dann bei Bedarf abrufen kann, also Textdateien, Datenbank-Schemas, Dateiinhalte und dergleichen. Und dann haben wir als zusätzliches Primitiv auch Prompt-Vorlagen, und das sind vordefinierte Vorlagen, die vorgeschlagene Prompts liefern. Nicht jeder MCP-Server wird alle drei Primitiven verwenden. Tatsächlich konzentrieren sich viele derzeit nur auf Werkzeuge, aber das Wichtige hierbei ist, dass ein KI-Agent einen MCP-Server zur Laufzeit abfragen kann, um zu entdecken, welche Primitiven verfügbar sind, und dann diese Fähigkeiten auf einheitliche Weise aufrufen kann. Da jeder MCP-Server einen maschinenlesbaren Katalog veröffentlicht, also tools/list und resources/list und prompts/list, können Agenten neue Funktionalitäten entdecken und nutzen, ohne Code neu zu deployen.
Okay, das ist MCP. Was ist mit APIs? Nun, APIs sind eine weitere Möglichkeit, einem System den Zugriff auf die Funktionalität oder Daten eines anderen Systems zu ermöglichen. Eine Application Programming Interface ist eine Reihe von Regeln oder Protokollen, die beschreiben, wie Informationen oder Dienste angefordert werden. Und durch die Verwendung von APIs können Entwickler Fähigkeiten aus externen Systemen integrieren, anstatt alles von Grund auf neu zu erstellen. Eine E-Commerce-Website kann beispielsweise eine Zahlungs-API verwenden, um Kreditkartenzahlungen abzuwickeln.
Die API fungiert als Abstraktionsschicht. Wir haben also die anfragende Anwendung, den Client, nun, diese muss nicht die internen Details des Dienstes kennen, den sie aufrufen möchte, den Server. Es ist alles irgendwie von ihr abstrahiert, weil der Server die Anfrage verarbeitet und das Einzige, was wir wissen müssen, ist, wie wir die Anfragen formatieren und die Antworten verstehen, indem wir die API verwenden. Das ist wirklich alles, was dazu gehört.
Es gibt viele verschiedene API-Stile, aber einer der allgegenwärtigsten ist der RESTful API-Stil. Sie können sich das als die, im Wesentlichen, die Standard-API des Webs vorstellen. Und eine RESTful API kommuniziert über HTTP. Dieser Aufruf hier ist also ein HTTP-Aufruf mit einer RESTful API, bei der Clients Standard-HTTP-Methoden verwenden. Sie könnten zum Beispiel GET verwenden, um Daten abzurufen. Sie könnten POST verwenden, um Daten zu erstellen, PUT, um Daten zu aktualisieren, und DELETE, um Daten zu löschen.
Zum Beispiel könnte eine REST-API für ein Bibliothekssystem einen Endpunkt haben, der etwa so aussieht: GET, und dann sagen wir /books, /123, wenn wir die Details von Buch Nummer eins, zwei, drei abrufen möchten. Oder wir könnten POST verwenden und sagen POST /loans, wenn wir ein Buch ausleihen möchten. Jeder solche Endpunkt gibt Daten zurück, oft im JSON-Format, die das Ergebnis darstellen. Und tatsächlich werden viele kommerzielle große Sprachmodelle über REST angeboten. Senden Sie einen JSON-Prompt, erhalten Sie eine JSON-Vervollständigung zurück. KI-Agenten können auch REST-APIs verwenden, um eine Websuche durchzuführen oder mit den internen REST-Diensten eines Unternehmens zu interagieren.
MCP und APIs, sie teilen sich... Viele Gemeinsamkeiten, nicht zuletzt, dass sie beide als Client-Server-Modellarchitekturen gelten. Bei einer REST-API sendet ein Client eine HTTP-Anfrage wie die von mir erwähnten GETs oder POSTs an einen Server, und der Server gibt dann eine Antwort zurück. Bei MCP sendet der MCP-Client eine Anfrage wie tools/call an einen MCP-Server und erhält eine Antwort. Sie bieten also wirklich beide eine Abstraktionsschicht, so dass ein System nicht die Low-Level-Details der Interna eines anderen kennen muss. Die Implementierungsdetails dort, sie sind verborgen. Der Client folgt einfach der Schnittstelle.
Sowohl MCP als auch APIs helfen also wirklich, Dinge zu vereinfachen, insbesondere die Integration zu vereinfachen und Entwicklern zu ermöglichen, Systeme miteinander zu verdrahten, anstatt das Rad neu zu erfinden. Aber MCP und APIs haben auch einige grundlegende Unterschiede. Und lassen Sie uns mit dem Zweck beginnen, den wir wirklich als MCPs Bereich betrachten können, im Gegensatz zum Allzweckzweck, den wir wirklich als Domäne von APIs betrachten könnten.
Das Model Context Protocol wurde explizit entwickelt, um LLM-Anwendungen mit externen Daten und Werkzeugen zu integrieren. Es standardisiert Muster wie die Bereitstellung von Kontextdaten und den Aufruf von Werkzeugen auf eine Weise, die mit der Funktionsweise von KI-Agenten übereinstimmt. APIs hingegen wurden nicht speziell mit Blick auf KI oder LLMs entwickelt, und das bedeutet, dass MCP bestimmte Annahmen mitbringt, die für KI nützlich sind.
Das ist einer der stärksten Vorteile von MCP, und das ist die Tatsache, dass es dynamische Erkennung unterstützt. Was meine ich damit? Nun, ein MCP-Client kann einen MCP-Server einfach fragen: "Hey, was kannst du tun?" Und er erhält eine Beschreibung aller verfügbaren Funktionen und Daten, die dieser Server anbietet. Der Client oder die LLM-Anwendung, die ihn verwendet, kann sich dann an das anpassen, was gerade verfügbar ist. Traditionelle REST-APIs bieten normalerweise keinen gleichwertigen Laufzeit-Erkennungsmechanismus, und wenn sich die API ändert, neue Endpunkte hinzugefügt werden, muss der Client von einem Entwickler aktualisiert werden.
MCP dreht dieses Modell um, denn KI-Agenten können jedes Mal, wenn sie sich verbinden, die aktuellste Liste der Fähigkeiten von einem Server abrufen und dann neue Funktionen automatisch übernehmen. Ein weiterer großer Unterschied betrifft auch die Standardisierung, insbesondere die Standardisierung der Schnittstelle, und der Unterschied hier ist, dass jeder MCP-Server, unabhängig davon, mit welchem Dienst oder welchen Daten er verbunden ist, dasselbe Protokoll spricht und dieselben Muster befolgt, während jede API einzigartig ist. Die spezifischen Endpunkte und die Parameterformate und die Authentifizierungsschemata variieren zwischen den Diensten. Wenn ein KI-Agent also fünf verschiedene REST-APIs verwenden möchte, benötigt er möglicherweise fünf verschiedene Adapter, während fünf MCP-Server auf exakt dieselben Aufrufe reagieren. Einmal bauen, viele integrieren.
Okay, also ähnlich, aber unterschiedlich, aber hier ist der Knackpunkt. Wenn es um MCP geht, verwenden viele MCP-Server, wenn wir uns ihre Implementierung ansehen, tatsächlich traditionelle APIs, um ihre Arbeit zu erledigen. In vielen Fällen ist ein MCP-Server im Wesentlichen ein Wrapper um eine bestehende API, der zwischen dem MCP-Format und der nativen Schnittstelle der zugrunde liegenden Dienste übersetzt, indem er diese API verwendet, wie der MCP GitHub-Server, der High-Level-Werkzeuge wie repository/list als MCP-Primitive exponiert, aber dann intern jeden Werkzeugaufruf in die entsprechende REST-API-Anfrage von GitHub übersetzt.
MCP und APIs sind also keine Gegner, sie sind Schichten, sie sind Schichten in einem KI-Stack. MCP kann APIs im Hintergrund verwenden und gleichzeitig eine KI-freundlichere Schnittstelle darüber bieten. Und heute finden Sie MCP-Dienste für Dateisysteme, Google Maps, Docker, Spotify und eine wachsende Liste von Unternehmensdatenquellen. Und dank MCP können diese Dienste nun besser und standardisierter in KI-Agenten integriert werden.