PullMD Teil 6: Setup für Agenten
Ich habe an einem Nachmittag eigentlich nur die Oberfläche aufgeräumt. Was dabei herauskam, war eine Hilfeseite und ein ziemlich blöder Denkfehler in meinem eigenen Dienst.
Der Gedanke, der alles losgetreten hat
Wir redeten über Share-Links und darüber, wie lange die eigentlich leben. Und dann fiel mir etwas auf:
„ah sehr interessant, also könnte ein KI agent ein subreddit link immer wieder mal abrufen und hätte so ständig die neuesten beiträge oder die halt auf der seite stehen… cool. wir sollten solche informationen auf eine eingebaute hilfeseite schreiben, weil man sowas auch vergisst und nach ein paar wochen oder monaten nicht mehr weiss. viele projekte haben sowas nicht“
Der zweite Teil ist mir im Rückblick der wichtigere. Ich vergesse die Eigenheiten meiner eigenen Werkzeuge ja tatsächlich. Nach drei Monaten weiß ich nicht mehr, ob der Cache eine Stunde hält oder einen Tag, und dann probiere ich es eben aus, statt nachzulesen. Dabei wäre es natürlich gut, so etwas direkt im Dienst nachlesen zu können.
Die Hilfeseite
Also /help, zweisprachig, im selben Design wie der Rest.
Drin steht das, was man vergisst:
- Wie lange ein Ergebnis frisch bleibt und wann neu geholt wird
- Wie lange ein Share-Link lebt
- Dass ein Agent einen Subreddit-Link immer wieder abrufen kann und so an die neuesten Beiträge kommt
- Welche Parameter der Endpunkt kennt
- Was im Kopf des Markdowns steht
- Wie der Dienst erkennt, ob gerade ein Browser, die App oder ein Agent anfragt
Dazu ein Abschnitt, den ich vorher so nirgends hatte: Setup für KI-Agenten. Zwei Kästen zum Kopieren, einer davon ein fertiger Text, den man einem beliebigen Chatbot vorsetzen kann, und der Skill aus Teil 4 als ZIP zum Herunterladen.
Das ZIP entsteht beim Bauen des Containers automatisch aus dem Skill-Verzeichnis. Neun Dateien, neun Kilobyte. Wer es auspackt, hat das Setup schon drin und muss nichts zusammensuchen.
Für MCP stand an der Stelle erst mal „kommt noch“. Dazu kommen wir in Teil 7.
Eine Behauptung stimmte nicht
Beim Aufschreiben des Subreddit-Tipps habe ich die Idee noch einmal durchgedacht: dass ein Agent denselben Link immer wieder abruft und jedes Mal den aktuellen Stand bekommt. Und gemerkt, dass sie so gar nicht funktioniert:
„der share link macht ja eigentlich nur sinn, wenn ich den inhalt darüber immer wieder frisch holen kann. ansonsten brauch ich den share link nicht, den alten text hab ich ja bereits.“
Der Share-Link war bis dahin ein Schnappschuss. Man ruft ihn auf und bekommt genau das, was beim ersten Abruf da war. Für „schick mal jemandem einen Artikel“ ist das richtig. Für einen Agenten, der wissen will, was gerade in einem Subreddit los ist, ist es nutzlos.
Der Denkfehler war also nicht im Code, sondern in dem, was ich eine halbe Stunde vorher selbst behauptet hatte.
Aus dem Schnappschuss wird ein Endpunkt
Der Umbau war klein. Beim Aufruf eines Share-Links schaut der Dienst jetzt aufs Alter. Ist der Stand älter als eine Stunde, holt er die Quelle neu und schreibt sie zurück. Die Kennung bleibt dabei dieselbe.
Zwei Details, die dabei wichtig waren:
-
Er muss aus dem alten Markdown ableiten, ob damals Kommentare dabei waren und in welcher Sprache geantwortet wurde. Sonst kommt beim Auffrischen etwas anderes zurück als beim ersten Mal.
-
Und wenn das Neuholen scheitert, weil die Quelle weg ist oder das Netz klemmt, liefert er weiter den alten Stand aus. Ein Share-Link, der plötzlich 404 sagt, wäre schlechter als einer, der etwas Altes zeigt.
Damit muss ein Agent nur noch eine kurze Kennung kennen. Keine URL verwalten, keine Parameter merken. Einmal abrufen, und was zurückkommt, ist aktuell.
Dass genau dieser Endpunkt zwei Stunden später eines von drei Werkzeugen für Claude wird, war zu dem Zeitpunkt noch nicht geplant.
Teil 6 von 15 der PullMD Serie.
← PullMD Teil 5: Die falsche Engine gemessen | PullMD Teil 7: Der MCP-Server →