PullMD Teil 7: Der MCP-Server

Am Abend des 2. März, im allerersten Konzept-Chat, steht ein Halbsatz: „MCP später.“ Danach kam sieben Wochen lang nichts mehr dazu. Im Kopf war die Sache bei mir trotzdem irgendwann abgehakt.

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?“

War es eben nicht. Es war eine HTTP-Schnittstelle mit einem Skill daneben, und beides zusammen erledigte den Job auch ganz gut.

Meine erste Reaktion war entsprechend: dann reicht der Skill ja. Also Hilfeseite bauen, ZIP anbieten, fertig. Das steht in Teil 6.

Warum ich eine halbe Stunde später doch anfing

Dann kam mir beim Schreiben der Anleitung das Argument, das die Sache gedreht hat:

„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 ja 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, ohne dass irgendwer irgendetwas aktualisiert.

Die zwei Wege zu einem MCP-Server

Wichtig ist dabei, wie der Agent den Server erreicht. Es gibt zwei Wege.

Bei der lokalen Variante startet der Client den Server als Prozess auf dem eigenen Rechner. Das heißt: jeder Nutzer installiert erst mal etwas.
Bei der entfernten Variante spricht der Client über HTTP mit einem Server, der irgendwo steht. Der Nutzer trägt eine Adresse ein, mehr nicht.

Nur der zweite löst mein Problem. Bei der ersten wäre der Vorteil aus dem Argument oben sofort wieder weg gewesen, denn dann hantiert man eben statt mit einem Skill, mit einer lokalen Installation.

Der Skill bleibt trotzdem

Das war die Frage, die ich mir dabei selbst gestellt habe: Wenn es den MCP-Server gibt, kann der Skill dann weg?

Ein Stück weit schon. Ein MCP-Server läuft auch ohne Skill, und zu jedem Werkzeug gehört eine Beschreibung, in der eben auch steht, wann man es nimmt. Bei read_url stand von Anfang an sinngemäß drin: immer dann, wenn man sonst rohes HTML holen würde.

Nur passen Regeln, die mehrere Werkzeuge betreffen, schlecht in die Beschreibung eines einzelnen. Im Skill standen genau solche:

GitHub-Adressen nicht über den Dienst holen, dafür gibt es gh
Endpunkte, die JSON zurückgeben, auch nicht
und wenn der Dienst gerade nicht antwortet, zurück auf den eingebauten Abruf

Der Skill blieb, und ein Grund dafür gilt bis heute. Nicht jeder will oder kann einen MCP-Server einbinden, und wer bei der normalen Schnittstelle bleibt, bekommt das Verhalten nur über den Skill.

Die Begründung, die wir uns damals sonst noch zurechtgelegt haben, trägt dagegen nicht. Wir hielten diese Regeln für etwas, das in eine Werkzeug-Beschreibung nicht hineinpasst, und das stimmt so einfach nicht.

Die Beschreibung von read_url fängt heute genau damit an, dass man den Dienst dem eingebauten Abruf vorziehen soll, und zwar nicht erst, wenn der scheitert. Wer die Beschreibungen ordentlich schreibt, braucht den Skill dafür also gar nicht. Das war am 25. April vermutlich schon so, nur ist es weder Claude noch mir aufgefallen.

Die drei Werkzeuge

Vorgeschlagen waren zunächst drei:

read_url holt eine Adresse als Markdown, das ist die Hauptsache
get_share liest den Live-Endpunkt aus Teil 6, den es seit zwei Stunden gab
list_recent zeigt, was zuletzt durchgelaufen ist

Ich habe dann 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, brauchten aber je einen Endpunkt, den es noch gar nicht gab. Eine Suche über Titel und Adressen der gespeicherten Seiten, und eine Statistik über die Extraktionen. Die Suche stand am Ende als vierter Vorschlag drin, die Statistik nur als Möglichkeit für später.

Vier weitere fielen in derselben Antwort gleich wieder durch. Eine Archiv-Abfrage, weil list_recent mit einer größeren Zahl dasselbe kann. Eine Statistik über den belegten Speicher, weil sie über den Inhalt nichts sagt. Und delete_entry und delete_all, mit der Begründung, ein Werkzeug-Schema gebe dem Modell zu wenig Kontext, um sicher zu entscheiden, was weg darf.

Widersprochen habe ich dem nicht, hatte aber einen einfacheren Grund: Ich brauchte die beiden schlicht nicht. Weg wäre da ohnehin nur ein Eintrag im Zwischenspeicher, und den holt der Dienst beim nächsten Aufruf einfach neu.

Meine Antwort war dann kurz: die drei reichen völlig.

Was dagegen sprach

Der Vollständigkeit halber, denn es sprach durchaus etwas dagegen.

Dass ein Client einen MCP-Server einfach über HTTP anspricht, statt ihn selbst zu starten, 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 zwar unabhängig weiter, aber es ist eben 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 auf der Hilfeseite

Zum Schluss noch eine Kleinigkeit, die erst beim Aufschreiben auffiel. Auf der Hilfeseite steht der Befehl zum Einrichten, und darin steht eine Adresse.

Meine Adresse. Was für jeden, der den Dienst selbst betreibt, genau die falsche ist.

Also wurde die Basis-Adresse zu einer Umgebungsvariablen. Sie wird in die Hilfeseite eingesetzt und in das ZIP hineingeschrieben, und beides entsteht beim Start des Containers neu.

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 →