PullMD Teil 7: Der MCP-Server – Einfach erklärt
Am Abend des 2. März, im allerersten Konzept-Chat, steht ein Halbsatz: „MCP später.“ Danach kam sieben Wochen lang nichts. Im Kopf war die Sache trotzdem irgendwann abgehakt.
Was MCP eigentlich ist
MCP steht für Model Context Protocol. Das ist ein Protokoll, über das ein KI-Agent erfährt, welche Werkzeuge es gibt und wie man sie aufruft.
Ein Agent ist ein Programm, das eigenständig Aufgaben erledigt. Zum Beispiel Claude Code.
Der Agent fragt den MCP-Server nach seiner Werkzeugliste. Er bekommt für jedes Werkzeug eine Beschreibung samt Parametern und kann sie dann benutzen.
Ein bisschen wie eine Speisekarte: darin steht, was es gibt und wie man es bestellt.
Die Frage, die alles ins Rollen brachte
Am 25. April fragte ich Claude:
„Wie richte ich es in Claude Code oder sonstigen KI Agenten ein, ich glaube es ist ein MCP oder?“
Die Antwort: Nein, war es nicht. PullMD war eine HTTP-Schnittstelle mit einem Skill daneben.
HTTP ist das Protokoll, über das ein Browser mit einer Webseite spricht.
Ein Skill ist so etwas wie eine kurze Notiz auf dem Schreibtisch des Agenten. Darin steht, welches Werkzeug er wann nehmen soll. Mehr dazu in Teil 4.
Beides zusammen erledigte den Job ganz gut. Meine erste Reaktion: Dann reicht der Skill ja. Also eine Hilfeseite bauen, ein ZIP (ein gepacktes Dateipaket zum Herunterladen) anbieten, fertig. Das steht in Teil 6.
Warum ich eine halbe Stunde später doch anfing
Dann kam beim Schreiben der Anleitung das Argument, das die Sache drehte:
„Also ganz konkret: der MCP wäre gut, weil wir eh schon einen Server laufen haben und der Nutzer dann nicht mit Skills hantieren müsste, bei Änderungen am Server haben alle Clients automatisch den neuen Code… oder was spricht dafür/dagegen?“
Das ist der ganze Punkt. Der Server steht ohnehin. Wenn er die Werkzeuge selbst anbietet, muss niemand mehr ein ZIP herunterladen, entpacken und an die richtige Stelle legen. Und wenn ich etwas ändere, haben alle es sofort.
Lokal oder aus der Ferne
Es gibt zwei Wege, wie ein Agent einen MCP-Server erreichen kann.
Bei der lokalen Variante startet das Programm den Server auf dem eigenen Rechner. Jeder Nutzer installiert also erst mal etwas.
Bei der entfernten Variante spricht das Programm über das Internet mit einem Server, der irgendwo läuft. Man trägt eine Adresse ein, mehr nicht.
Nur der zweite Weg löst mein Problem. Bei der lokalen Variante wäre der Vorteil sofort wieder weg. Dann hantiert man eben statt mit einem Skill mit einer lokalen Installation.
Die drei Werkzeuge
Vorgeschlagen waren drei Werkzeuge:
read_url holt eine Webadresse als Markdown. Das ist die Hauptsache.
Markdown ist ein einfaches Textformat. Text mit Struktur, aber ohne Schnickschnack.
get_share liest den Live-Endpunkt aus Teil 6, den es seit zwei Stunden gab.
list_recent zeigt, was zuletzt durchgelaufen ist.
Was dazukam und was durchfiel
Ich habe gefragt, ob es noch weitere Kandidaten gäbe. Zurück kam die ganze Schnittstelle, sortiert nach Nutzen für einen Agenten.
Zwei weitere hätten sich gelohnt. Sie brauchten aber je einen Endpunkt, den es noch gar nicht gab. Die Suche über Titel und Adressen stand am Ende als vierter Vorschlag. Die Statistik nur als Möglichkeit für später.
Vier fielen in derselben Antwort gleich wieder durch. Eine Archiv-Abfrage, weil list_recent mit einer größeren Zahl dasselbe kann. Eine Speicher-Statistik, weil sie über den Inhalt nichts sagt. Und delete_entry und delete_all: eine Werkzeug-Beschreibung gibt dem Modell zu wenig Kontext, um sicher zu entscheiden, was weg darf.
Ich hatte einen einfacheren Grund: Ich brauchte die beiden schlicht nicht. Weg wäre ohnehin nur ein Eintrag im Zwischenspeicher, den der Dienst beim nächsten Aufruf einfach neu holt.
Ein Zwischenspeicher (Cache) ist eine Art Ablage für bereits abgerufene Seiten.
Meine Antwort war kurz: Die drei reichen völlig.
Der Skill bleibt trotzdem
Wenn es den MCP-Server gibt, kann der Skill dann weg?
Ein Stück weit schon. Der MCP-Server läuft auch ohne Skill. Zu jedem Werkzeug gehört eine Beschreibung, in der steht, wann man es nimmt.
Aber: Nicht jeder will oder kann einen MCP-Server einbinden. Wer bei der normalen Schnittstelle bleibt, bekommt das Verhalten nur über den Skill. Deshalb bleibt er.
Die Begründung, die wir uns damals sonst noch zurechtgelegt haben, trägt dagegen nicht. Wir hielten Regeln, die mehrere Werkzeuge betreffen, für etwas, das in eine Werkzeug-Beschreibung nicht hineinpasst.
Das stimmt so einfach nicht. Die Beschreibung von read_url fängt heute genau damit an: nimm den Dienst und nicht den eingebauten Abruf, und zwar nicht erst, wenn der scheitert.
Am 25. April war das vermutlich schon so. Nur ist es weder Claude noch mir aufgefallen.
Was dagegen sprach
Dass ein Programm einen MCP-Server einfach übers Internet anspricht, war damals noch ziemlich neu. Claude Code, Claude Desktop und Cursor konnten das schon. Andere Programme nicht unbedingt.
Wer eine ältere Version hatte, konnte den Server nur lokal starten. Und genau das wollte ich ja vermeiden.
Der Server bekommt außerdem eine zweite Aufgabe. Wenn der MCP-Teil klemmt, sehen Agenten einen Fehler. Die normale Schnittstelle läuft davon unabhängig weiter. Aber es ist eine Stelle mehr, die kaputtgehen kann.
Und alles, was kein MCP spricht, hat davon nichts. Für die bleibt der Kasten zum Kopieren auf der Hilfeseite.
Die Adresse wird zur Variablen
Zum Schluss eine Kleinigkeit, die erst beim Aufschreiben auffiel. Auf der Hilfeseite steht der Befehl zum Einrichten, und darin steht eine Adresse. Meine Adresse. Die für jeden anderen genau die falsche ist.
Also wurde die Basis-Adresse zu einer Umgebungsvariablen.
Eine Umgebungsvariable ist eine Einstellung, die man dem Programm beim Start mitgibt, ohne etwas im Code zu ändern.
Sie wird in die Hilfeseite eingesetzt und in das ZIP hineingeschrieben. Beides entsteht beim Start des Containers neu.
Ein Container ist eine Art versiegelte Box mit dem Programm und allem, was es zum Laufen braucht.
Warum das ausgerechnet an dem Tag wichtig wurde, steht in Teil 8.
Teil 7 von 15 der PullMD Serie.
← PullMD Teil 6: Setup für Agenten | PullMD Teil 8: Vom Tool für mich zum OSS-Projekt →