MCP-Server

Auf der Seite über Sidecars steht ein Satz, den die Seite dort schuldig bleibt. MCP ist die Steckdose, das Sidecar ist das Gerät. Hier wird er eingelöst. Ein Sidecar kann perfekt gebaut sein und für einen Agenten trotzdem unerreichbar bleiben, weil ihm niemand gesagt hat, dass es diesen Dienst gibt, wie er heißt, welche Felder er erwartet und was zurückkommt. Diese Lücke füllt das Protokoll.

Warum überhaupt ein Protokoll?

Ein Werkzeug in den Loop zu hängen ist Handarbeit, und wie sie geht, steht eine Station früher. Schema schreiben, mitschicken, Aufruf entgegennehmen, ausführen, Ergebnis zurückgeben. Für ein Werkzeug ist das eine überschaubare Stunde. Und für zehn Werkzeuge in drei Harnessen? Das Problem beginnt beim zweiten Harness.

Denn so eine Anbindung gilt nirgends allgemein. Sie hängt daran, wie ein Werkzeug beschrieben wird, wie der Aufruf zurückkommt und in welcher Sprache das alles geschrieben ist. Wer zehn Fähigkeiten hat und sie in drei Harnessen verfügbar machen will, muss dreißigmal dieselbe Anbindung schreiben, jedes Mal mit leicht anderen Ecken. Das ist keine theoretische Rechnung. So sah das Feld bis Ende 2024 aus: Jedes Werkzeug wurde jedem Harness einzeln beigebracht, und wer den Harness wechselte, durfte die Arbeit noch einmal machen.

Anthropic hat im November 2024 das Model Context Protocol veröffentlicht und offen gestellt. Der Gedanke dahinter ist unspektakulär und deshalb wirksam. Sprechen beide Seiten dieselbe Sprache, sinkt die Zahl der Anbindungen von Fähigkeiten mal Harnesse auf Fähigkeiten plus Harnesse. Einen Server, den du einmal baust, kann danach jeder Client benutzen, der das Protokoll spricht, und ein Harness, der es einmal gelernt hat, erreicht damit alles, was jemals als MCP-Server veröffentlicht wurde, ohne dass irgendjemand die beiden Seiten voneinander wissen ließ.

Wie weit trägt der Vergleich mit der Steckdose? Weiter, als er zunächst aussieht. Eine Steckdose weiß nichts über Föhne. Sie legt fest, wie breit die Löcher sind, welche Spannung anliegt und was passieren soll, wenn zu viel Strom fließt. Alles Weitere darf das Gerät entscheiden. Genauso wenig weiß MCP, was parse_pdf tut. Es legt fest, wie ein Werkzeug sich vorstellt, wie es aufgerufen wird und in welcher Form die Antwort zurückkommt, und alles, was danach im Sidecar passiert, bleibt dessen eigene Sache.

Client und Server: wer ruft wen an?

Zwei Rollen, und die Namen erklären sich für einmal selbst.

Der Server bietet Fähigkeiten an. Er ist das Stück Software, das vor deinem Sidecar, deiner Datenbank oder deiner API steht und sie beschreibt. Der Client sitzt im Harness und verbindet sich mit einem oder mehreren Servern. Ein Harness darf fünf Server gleichzeitig sprechen. Sie wissen nichts voneinander.

Der Ablauf hat drei Takte. Warum du sie kennen solltest? Weil im ersten die meisten Fehler stecken, und weil ein Client, der beim Handshake über eine Protokollversion stolpert, dir hinterher genau eine Zeile Fehlermeldung hinterlässt, in der von Werkzeugen keine Rede ist.

1. Verbinden und initialize. Client und Server sagen einander, welche Protokollversion sie sprechen und was sie können. Erst danach ist die Verbindung eine Sitzung.
2. tools/list. Der Client fragt, was es gibt. Zurück kommt eine Liste aus Namen, Beschreibungen und JSON-Schemata für die Argumente. Diese Liste wandert anschließend in den Kontext des Modells. Sie ist der Grund, warum das Modell überhaupt weiß, dass es parse_pdf aufrufen kann.
3. tools/call. Das Modell entscheidet sich für ein Werkzeug, der Harness schickt Namen und Argumente, der Server tut die Arbeit und antwortet.

Darunter liegt JSON-RPC 2.0, ein Format, das älter ist als jeder Agent und deshalb hier steht. Es ist langweilig, verbreitet und in jeder Sprache vorhanden.

Drei Dinge, die ein Server anbietet

Werkzeuge sind der bekannteste Teil. Der einzige sind sie nicht. Das Protokoll kennt drei Arten von Angeboten. Das ist keine Kosmetik, denn daran hängt, wer die Kontrolle hat.

Werkzeuge (tools) sind modellgesteuert. Das Modell entscheidet, wann es send_invoice aufrufen will, und der Harness führt es aus. Alles, was etwas verändert, gehört hierher.

Ressourcen (resources) sind anwendungsgesteuert. Ein Server bietet Daten unter einer URI an, eine Datei etwa, einen Datenbankauszug oder ein Log. Was davon in den Kontext wandert, darf der Harness entscheiden. Der Unterschied zum Werkzeug liegt in der Richtung. Eine Ressource wird gelesen und hat keine Wirkung. Wer beides vermischt und das Lesen als Werkzeug anbietet, lässt das Modell entscheiden, was es sich ansieht. Manchmal geht das gut. Meistens wird es teuer, weil ein Modell, dem man das Lesen als Werkzeug hinlegt, es aufruft, sobald ein Wort im Auftrag entfernt danach klingt, und die Antwort danach vollständig im Verlauf steht.

Prompts sind nutzergesteuert. Der Server liefert vorbereitete Textbausteine, die eine Oberfläche als Befehl anbieten kann. Der Nutzer wählt, das Modell bekommt den fertigen Text. In der Praxis ist das der seltenste der drei, und meistens zu Recht.

Dazu kommt eine Kleinigkeit mit Folgen. Ein Server darf melden, dass sich seine Werkzeugliste geändert hat, und ein Client, der auf diese Meldung hört, holt sie neu. Das klingt bequem. Wie weit traust du einem Werkzeug, dessen Beschreibung sich nach dem ersten erfolgreichen Aufruf ändern darf? Im Betrieb ist das eine Angriffsfläche, über die der Deep-Dive redet.

Zwei Transporte, und die Wahl fällt meistens leicht

Das Protokoll legt fest, was gesprochen wird. Worüber es gesprochen wird, ist eine zweite Entscheidung, und darauf gibt es genau zwei Antworten.

stdio heißt: Der Client startet den Server als eigenen Prozess und redet mit ihm über Standardein- und -ausgabe. Keine Ports. Kein Netzwerk. Keine Anmeldung. Berechtigt ist, wer den Prozess starten durfte. Diesen Transport nimmst du für alles, was auf demselben Rechner läuft wie der Agent. Zugriff aufs Dateisystem. Ein lokales Git. Ein Werkzeug, das die Zwischenablage liest.

Streamable HTTP heißt: Der Server ist ein Dienst mit einer Adresse, der Client schickt POST-Anfragen, und Antworten dürfen als Ereignisstrom zurücklaufen, wenn eine davon länger dauert. Diesen Transport nimmst du für alles, was nicht auf dem Rechner des Nutzers liegt: einen geteilten Dienst im Firmennetz, einen Server hinter einer Weboberfläche oder einen Endpunkt, an dem zehn Leute gleichzeitig hängen und von dem trotzdem keiner die Sitzung eines anderen sehen darf. Er hat den älteren Aufbau aus HTTP plus einem dauerhaft offenen Ereigniskanal abgelöst, der je Client eine stehende Verbindung brauchte und hinter Proxys entsprechend unbeliebt war.

Die Faustregel passt in eine Zeile. Läuft es beim Nutzer, nimm stdio. Läuft es für mehrere, nimm Streamable HTTP.

Eine Rechnung wird dabei immer wieder falsch aufgemacht. stdio ist nicht die einfachere Bauweise, es ist die einfachere Betriebsform. Der Code darunter bleibt derselbe. Was wegfällt, ist alles, was ein Dienst braucht, sobald er über das Netz erreichbar sein soll. Wer darf rein. Wer räumt alte Sitzungen weg. Was passiert bei Überlast. Und woran erkennt der Rest der Anlage, dass er noch lebt. Brauchst du davon eines, brauchst du erfahrungsgemäß alle, und dann ist der Transport nicht mehr die interessante Frage. Wie das aussieht, zeigt die Pro-Stufe am MCP-Server dieses Projekts.

Was MCP ausdrücklich nicht kann

Drei Verwechslungen kommen regelmäßig vor. Jede kostet Zeit.

MCP ersetzt kein Tool-Calling. Das Modell ruft Werkzeuge weiterhin so auf, wie es das immer getan hat, und die Schleife im Harness bleibt dieselbe. MCP steht neben dieser Schleife und liefert ihr die Werkzeugliste, statt sie im Code stehen zu haben.

MCP verbessert nichts, was dahinter steht. Ein Server, der ein schlechtes PDF-Werkzeug beschreibt, beschreibt weiterhin ein schlechtes PDF-Werkzeug. Was hinter dem Werkzeug tatsächlich passiert, steht nicht im Protokoll. Dort steht das Sidecar, und ob es taugt, entscheidet sich dort.

Ein MCP-Server ist kein Agent. Er entscheidet nichts, er ruft kein Modell, er hat keine Schleife. Er wartet auf Anfragen und beantwortet sie. Fängt dein Server an, selbst nachzudenken, hast du einen Agenten gebaut und ihn Server genannt.

MCP ist ein offenes Protokoll, über das ein Harness Fähigkeiten findet und aufruft, ohne sie einzeln beigebracht zu bekommen. Damit sinkt die Zahl der Anbindungen von Fähigkeiten mal Harnesse auf Fähigkeiten plus Harnesse.

Ein Server bietet Werkzeuge (modellgesteuert, mit Wirkung), Ressourcen (anwendungsgesteuert, nur lesend) und Prompts (nutzergesteuert) an. Der Client im Harness verbindet sich, holt die Liste und ruft auf.

Zwei Transporte. stdio für alles, was auf dem Rechner des Nutzers läuft, Streamable HTTP für alles, was mehrere gemeinsam benutzen. Der zweite ist nicht schwerer zu programmieren, aber schwerer zu betreiben.