MCP Grundlagen: Hosts, Clients, Server und das JSON-RPC-Protokollformat

Sprachmodelle wurden für Unternehmen erst dann wirklich nützlich, als sie in der Lage waren, Aktionen auszuführen – nicht nur Antworten zu geben. Die schwierige Aufgabe lag nie im Modell selbst, sondern darin, es mit den Datenbanken, APIs und internen Tools zu verbinden, in denen die eigentliche Arbeit stattfindet – und das einmal durchzuführen, anstatt es für jede Anwendung sowie jeden Modellanbieter erneut zu tun. Das Model Context Protocol (MCP) ist ein Versuch, diese Verbindungen zu standardisieren. Dieser Artikel erläutert das Problem, das MCP löst, die Rollen seiner Komponenten, was über die Verbindungen übertragen wird, sowie die Unterschiede zwischen den beiden Standardtransportprotokollen, damit Sie einschätzen können, wo ein MCP-Server in Ihrer eigenen Architektur Platz findet.

Wo LLMs Wert schaffen: durch Handlungen

Einst war ein großer Teil der Automatisierung unerreichbar, einfach weil Software keine locker strukturierten Anfragen interpretieren konnte. Sprachmodelle beseitigen diese Hürde, und sobald sie mit Tools verbunden sind, können sie mehrstufige Workflows steuern, die zuvor eine menschliche Intervention zwischen verschiedenen Systemen erforderten.

Betrachten wir einen Assistenten, der dazu aufgefordert wird, einen Zug von Casablanca nach Rabat zu finden und zu buchen. Die Verständnis der Anfrage ist nur der erste Schritt. Der Assistent muss in einem Fahrplan-Service suchen, einen Abfahrtszeitpunkt auswählen, eine Buchungs-API aufrufen und das Ergebnis bestätigen. Jeder dieser Schritte stellt einen Aufruf eines Tools dar. Wenn die Tools über einen MCP-Server bereitgestellt werden, kann jeder kompatible Agent den gesamten Ablauf ausführen.

Daraus folgt direkt der wirtschaftliche Nutzen: Weniger manuelle Schritte pro Aufgabe bedeuten geringere Betriebskosten und schnellere Abwicklung. Es gibt auch einen Aspekt bezüglich der Benutzererfahrung. Mitarbeiter müssen regelmäßig mit vielen Dashboards und Interfaces umgehen, von denen jedes seine eigene Logik hat. Ein konversationaler Frontend, der mit diesen Backends verbunden ist, kann einen Großteil dieser Komplexität hinter einer einzigen Schnittstelle verbergen.

Das Integrationssproblem, das MCP löst

Der Einsatz von Tools ist nichts Neues. Jedes große LLM SDK unterstützt ihn, doch jedes verwendet dabei eigene Konventionen zur Deklaration von Tools, Beschreibung der Parameter sowie Zurückgabe von Ergebnissen. In der Praxis bedeutet das, dass derselbe Tool mehrfach implementiert wird – einmal pro Modellanbieter. Das Wechseln der Modelle oder die gleichzeitige Unterstützung mehrerer Modelle erfordert das Portieren dieses Integrationscodes, was die Teams verlangsamt und es erschwert, Produkte zu skalieren.

Das Überspringen der SDKs löst das Problem nicht vollständig. Man kann eine eigene Integrationsschicht entwickeln, die Intentionen in Aktionen umwandelt, Endpunkte aufruft, Parameter sammelt, Fehler behandelt und Analysen erfasst. Das bedeutet zusätzliche Komplexität, ist aber handhabbar. Das tiefere Problem besteht darin, dass eine solche Schicht in der Regel innerhalb einer einzigen Anwendung vorhanden ist. Wenn eine zweite Anwendung dieselben Tools benötigt, muss das Team die gleiche Schicht erneut erstellen. Die Integrationlogik ist somit an den Verbraucher gebunden und nicht an das System, das die jeweilige Funktionalität bereitstellt.

Was MCP ist

MCP ist ein offener Standard, der KI-Anwendungen eine gemeinsame Methode bietet, um mit Datenquellen und Tools zu verbinden. Er ermöglicht nichts, was vorher strikt unmöglich war; vielmehr macht er diese Verbindungen einfacher und konsistenter. Die Dokumentation des Protokolls unter modelcontextprotocol.io dient als autoritatives Referenzmaterial.

Der entscheidende Wandel liegt darin, wo die Logik der Tools untergebracht ist. Mit MCP veröffentlicht ein Backend-Dienst wie eine Datenbank, eine API oder ein internes Tool seine Funktionalitäten über einen MCP-Server. Die gängige Analogie ist ein USB-C-Anschluss: Der Dienst stellt einen Standardanschluss bereit, in den jede kompatible Anwendung eingesteckt werden kann. Die KI-Anwendung enthält nicht mehr das Wissen darüber, wie jedes Tool verwendet wird; sie muss lediglich das Protokoll verstehen.

Die Architektur: Hosts, Clients und Server

MCP nutzt eine Client-Server-Architektur mit drei Rollen, die leicht verwechselt werden können:

• Host: Die KI-Anwendung selbst, beispielsweise ein Chat-Assistent, eine IDE mit einem Agenten oder Ihr eigener Agentendienst. Damit interagiert der Benutzer, und es verbindet sich über einen oder mehrere MCP-Server mit der Außenwelt.

Klient: Ein Komponente innerhalb des Hosts, die eine Verbindung zu einem einzelnen MCP-Server herstellt und aufrechterhält. Dies ist der „Stecker“ in der USB-C-Analogie.

Server: Ein Programm, das den Clients auf standardisierte Weise Funktionen anbietet.

Der Host kommuniziert niemals direkt mit einem Server. Er erstellt einen Klienten pro Server und delegiert die gesamte Kommunikation an diesen; jeder Klient unterhält dabei eine eigene, ein-zu-eins-Verbindung. Diese Trennung ist in der Praxis nützlich: Ein Host, der mit einem Dateisystemserver, einem Ticketing-Server und einem CRM-Server verbunden ist, führt drei unabhängige Klienten, sodass ein Ausfall oder eine Berechtigungsproblematik in einer Verbindung nicht auf die anderen übergeht.

Die drei Server-Primitiven

Primitiven definieren, was jede Seite anbieten kann. Ein Server stellt drei Haupttypen zur Verfügung:

• Tools: Operationen, die das Modell ausführen kann, wie zum Beispiel den Aufruf einer API oder das Schreiben eines Datensatzes.
• Resources: Daten, die das Modell lesen und als Kontext verwenden kann, wie beispielsweise Datensatzzeilen oder Dokumente.
• Prompts: Voreingestellte Anweisungsvorlagen, die das Modell leiten, ähnlich wie wiederverwendbare System-Prompts.

Der Unterschied zwischen Tools und Resources ist für Sicherheit und Design von Bedeutung. Das Lesen eines Resources sollte ohne Nebeneffekte ablaufen, während der Aufruf eines Tools die Umgebung verändern kann; daher wenden Hosts oft unterschiedliche Genehmigungsregeln auf jeweils eines an.

JSON und JSON-RPC: das Nachrichtenformat

JSON (JavaScript Object Notation) stellt strukturierte Daten als aus Schlüssel-Wert-Paaren, Arrays und verschachtelten Objekten bestehenden Text dar. Da das Format einfach ist und universell unterstützt wird, können ein Sender und ein Empfänger, die in unterschiedlichen Sprachen programmiert sind, sich darauf einigen, was eine Nachricht bedeutet.

JSON-RPC baut darauf auf, indem es eine feste Nachrichtenstruktur für Fernprozeduraufrufe definiert. Eine Anfrage nennt eine Methode, enthält Parameter und ein Identifikator; wenn beide Seiten die Struktur befolgen, kann der Client den Server bitten, eine Methode auszuführen, und erhält das Ergebnis oder einen Fehler in einer ebenso vorhersehbaren Struktur. Das untenstehende Beispiel ist eine JSON-RPC 2.0-Anfrage, mit der ein Server um die Abfrage des Wetterzustands für Casablanca gebeten wird. Beachten Sie die vier Felder: die Protokollversion, eine Anfrage-id, die zur Zuordnung zur Antwort verwendet wird, der method-Name sowie das params-Objekt.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "get_weather",
  "params": {
     "city": "Casablanca"
   }
}

Dieses Beispiel veranschaulicht reines JSON-RPC. In MCP selbst werden Tools nicht als oberste Methoden mit dem Namen des Tools aufgerufen. Stattdessen sendet der Client eine Anfrage mit der Methode tools/call und platziert den Namen des Tools sowie seine Argumente innerhalb von params. Genau diese Indirektheit ermöglicht es MCP, ein festes Vokabular an Protokollmethoden zu definieren, während die Server frei sind, alle Tools bereitzustellen, die sie möchten.

Entdeckung ist das fehlende Element

JSON-RPC weist allein schon ein Problem auf: Ein Client muss bereits wissen, welche Methoden der Server anbietet. MCP schließt diese Lücke, indem es standardisiert, wie Clients Fähigkeiten entdecken können. Ein Client kann den Server bitten, seine Tools, Ressourcen und Anfragen aufzulisten, wodurch er Namen, Beschreibungen sowie Eingabeschemata erhält, die anschließend an das Modell weitergegeben werden. MCP legt außerdem fest, wie die Verbindung initialisiert wird und welche Übertragungsmechanismen die Nachrichten übertragen.

Übertragungsmechanismen: Wie Nachrichten übertragen werden

JSON-RPC definiert das Vokabular; der Übertragungsmechanismus bestimmt, wie Bytes zwischen Client und Server übertragen werden. Zum Zeitpunkt der Erstellung legt MCP zwei Standard-Übertragungsmechanismen fest. Prüfen Sie die aktuelle Spezifikation, bevor Sie sich auf Details verlassen, da das Protokoll weiterentwickelt wird.

stdio für lokale Tools

Mit dem stdio-Transport startet der Client den MCP-Server als Kindprozess. Der Server liest eingehende Nachrichten von seiner Standardeingabe und schreibt Antworten an seine Standardausgabe. Jeder Prozess erhält diese Pipes automatisch vom Betriebssystem, sodass weder Netzwerk-Sockets noch Ports erforderlich sind.

Deshalb eignet sich stdio hervorragend für Tools, die auf derselben Maschine wie der Host laufen, beispielsweise einen Server, der Ordner im lokalen Dateisystem erstellt. Ein weiterer Vorteil ist die Isolation: Der Server existiert nur solange, wie der Host ihn weiterläuft, und ist nicht über das Netzwerk erreichbar.

Streamable HTTP für gemeinsam genutzte, entfernte Server

Mit Streamable HTTP ist der Server ein unabhängiger Prozess, der als HTTP-Dienst läuft, und kann gleichzeitig viele Clients bedienen. Nachrichten werden über gewöhnliche HTTP-Anfragen ausgetauscht.

Diese Übertragung kann gestreamt werden. Anstatt auf eine vollständige Antwort zu warten, kann der Server die Daten schrittweise senden, was für lang andauernde Tool-Aufrufe vorteilhaft ist. Das Streamen wird mithilfe von Server-Sent Events (SSE) erreicht – einem einrichtungsorientierten Kanal, in dem eine lang andauernde HTTP-Antwort eine Abfolge von vom Server gesendeten Ereignissen enthält. Der Verkehr in die andere Richtung erfolgt weiterhin als gewöhnliche HTTP-Anfragen vom Client aus. Das genaue Verhalten hängt von der Implementierung sowie von der verwendeten HTTP-Version ab.

Eine praktische Faustregel: Wählen Sie stdio, wenn das Tool auf dem Rechner eines einzelnen Benutzers liegt, und wählen Sie Streamable HTTP, wenn eine Funktion zwischen Benutzern oder Teams geteilt werden soll, unter Berücksichtigung der Authentifizierungs- und Netzwerkkontrollen, die gemeinsam genutzte Dienste benötigen.

Warum ein Protokoll wichtiger ist als ein anderes SDK

Protokolle existieren dafür, dass Systeme, die von verschiedenen Teams in unterschiedlichen Sprachen und nach verschiedenen Veröffentlichungsskalen entwickelt werden, dennoch vorhersehbar miteinander zusammenarbeiten können. Ein Protokoll ist eine vereinbarte Reihe von Regeln dafür, wie unabhängige Komponenten miteinander kommunizieren, die Nachrichten des anderen interpretieren und Vertrauen aufbauen.

Der Wert der Standardisierung des Tool-Zugriffs liegt hauptsächlich im wirtschaftlichen Aspekt. Wenn die Integrationskosten für ein neues Modell oder eine neue Anwendung gegen Null gehen, werden Experimente günstig, und günstige Experimente führen zu schnelleren Iterationen. Das Team, das ein System betreut, kann einen MCP-Server veröffentlichen, und jede aktuelle sowie zukünftige KI-Anwendung in der Organisation kann diesen ohne speziell angefertigten Verbindungscode nutzen. Um zu sehen, wie dies innerhalb eines Agentenframeworks funktioniert, lesen Sie unseren Artikel über die Standardisierung der Tool-Integration in LangGraph mit MCP.

Kernpunkte

• LLMs liefern den größten Wert, wenn sie auf echten Systemen agieren können, wobei das Engpassproblem in der Integration und nicht in der Intelligenz liegt.
• Fehlt ein Standard, wird derselbe Tool für jedes Model-SDK und jede Anwendung neu implementiert; MCP verlagert diese Logik auf einen Server, der dem System gehört, das die Funktion bereitstellt.
• Ein Host führt pro Server einen Client aus, und jeder Client behält eine eigene Verbindung bei; die Server bieten Tools, Ressourcen und Anfragen bereit.
• JSON-RPC legt die Struktur der Nachrichten fest, während MCP ein fester Methodensatz wie tools/call sowie die Entdeckung von Funktionen hinzufügt.
• Verwenden Sie stdio für lokale, einbenutzerige Tools und Streamable HTTP für gemeinsam genutzte Remote-Dienste, und überprüfen Sie die Transporteinstellungen gegenüber der aktuellen Spezifikation.