Produktinhalte für KI-Agenten aufbereiten: llms.txt, MCP und strukturierte Doku

Ein wachsender Teil der Leser deiner Dokumentation sind keine Menschen. Coding-Assistenten holen sich Doku, um „Wie binde ich X ein?“ zu beantworten; Support-Agenten lesen Hilfeartikel, um Fragen von Nutzern zu klären; Recherche-Agenten fassen Changelogs zusammen, um Anbieter zu bewerten. Anbieter von Doku-Hosting berichten inzwischen, dass ein großer Teil des Traffics auf Dokumentation von KI-Agenten kommt und nicht aus Browsern. Wenn deine Inhalte nur für Menschen lesbar sind, die durch eine gerenderte Seite scrollen, bist du für einen Kanal unsichtbar, der immer öfter entscheidet, ob dein Produkt empfohlen, eingebunden oder aussortiert wird.

Damit Agenten mit deinen Inhalten etwas anfangen können, braucht es drei Ebenen: einen auffindbaren Index, ein Protokoll, das Maschinen nutzen können, und Inhalte, die so gut strukturiert sind, dass sich das Lesen lohnt.

Ebene 1: llms.txt – der Index, nach dem Agenten suchen

llms.txt ist eine Konvention nach dem Vorbild von robots.txt: eine Markdown-Datei im Stammverzeichnis deiner Website (yourapp.com/llms.txt), die Agenten auf Basis von Sprachmodellen sagt, was deine Website ist und wo ihre wichtigen Inhalte liegen. robots.txt sagt, was Crawler nicht dürfen; llms.txt sagt, was sich zu lesen lohnt: eine kurze Beschreibung des Produkts, dann eine kuratierte Liste mit Links auf die wichtigsten Seiten – Doku-Abschnitte, API-Referenz, Changelog, Preise.

Eine gute llms.txt hat zwei Eigenschaften:

• Kuratiert, nicht zusammenkopiert. Die Datei ist eine Karte, kein Abladeplatz. Verweise auf deine kanonischen Doku-Seiten; Agenten folgen den Links und lesen die Seiten selbst. (Die verwandte Konvention llms-full.txt ist die Variante mit dem vollständigen Inhalt, für Agenten, die alles mit einem Abruf haben wollen. Nützlich, aber zuerst muss der Index stimmen.)

• Generiert, nicht von Hand gepflegt. Wie eine Sitemap veraltet eine von Hand bearbeitete llms.txt. Erzeuge sie aus derselben Content-API, die auch deine Seiten speist, dann landet ein veröffentlichter Artikel automatisch im Index. Liegen deine Inhalte in einem Content-Backend, ist das eine kleine Server-Route: Listen abrufen, Markdown-Links ausgeben.

Aufwand: ein Nachmittag. Ertrag: IDE-Assistenten und Recherche-Agenten, die /llms.txt abrufen (und das tun sie schon heute), bekommen deine Darstellung deines Produkts statt einer Vermutung.

Ebene 2: MCP – von lesbar zu bedienbar

Das Model Context Protocol (MCP) setzt sich als Standard durch, um externe Systeme als Tools an KI-Agenten anzubinden. llms.txt macht deine Inhalte auffindbar, ein MCP-Server macht sie bedienbar: Ein Agent ruft search_entries mit der Frage eines Nutzers auf, holt mit get_entry einen vollständigen Artikel oder listet deinen Changelog auf – als strukturierte Operationen, die strukturierte Daten zurückgeben, statt HTML auszulesen.

Konkret ändert das, wer mit deinen Inhalten arbeiten kann:

• Der Coding-Agent eines Entwicklers fragt dein Hilfecenter und deinen Changelog direkt aus dem Editor ab, während der Entwickler deine API einbindet.

• Der Schreib-Agent eines Teams entwirft einen Changelog-Eintrag, legt ihn als Entwurf ab und überlässt das Veröffentlichen einem Menschen. Bietet der Server Tools zum Schreiben an, kannst du Arbeit an Inhalten delegieren.

• Deine eigenen internen Agenten sortieren Feedback-Beiträge vor oder beantworten Support-Fragen auf Grundlage derselben Inhalte, ohne eigens gebaute Integration.

CMS-Anbieter sind hier schnell nachgezogen: Mehrere große Content-Plattformen haben im letzten Jahr MCP-Server veröffentlicht, und bei der Auswahl einer Plattform wird MCP zum Punkt auf der Checkliste. Kookee hat einen: einen MCP-Server über den Inhalten eines Projekts, den jedes Teammitglied mit einem persönlichen Token verbindet, standardmäßig nur mit Lesezugriff. Er hat Tools zum Lesen (auflisten, suchen, abrufen) und zum Schreiben (anlegen, ändern, veröffentlichen, kategorisieren, Feedback vorsortieren). So funktionieren beide Hälften des Kreislaufs ohne Zusatzarbeit: Agenten, die deine Inhalte lesen, und Agenten, die beim Schreiben helfen. Egal, welche Plattform du nutzt, die Frage bei der Auswahl bleibt dieselbe: Erreicht ein Agent meine Inhalte als Tools, mit einer Authentifizierung, die auf die Person beschränkt ist, für die er handelt?

Ebene 3: Inhalte, die die Tokens wert sind

Indizes und Protokolle bringen deine Inhalte zu den Agenten; die Struktur entscheidet, was sie damit anfangen können. Praktischerweise helfen den Agenten dieselben Gewohnheiten, die schon Menschen und Suchmaschinen geholfen haben:

• Eine Frage pro Artikel, die Antwort zuerst. Agenten holen sich Textabschnitte, sogenannte Chunks. Ein Artikel, der mit der Antwort beginnt, liefert einen brauchbaren Chunk; einer, der sie unter einer Einleitung vergräbt, liefert Rauschen.

• Echte Überschriften und stabile URLs. Abruf und Zitieren hängen beide an adressierbaren Abschnitten. Wenn ein Agent yourapp.com/help/billing/refunds#timeline zitieren kann, kann ein Nutzer seine Antwort prüfen.

• Strukturierte Felder statt Konventionen im Fließtext. Einen Changelog-Eintrag mit festem Typ („Fix“) und einem Versionsfeld kann man filtern; dieselbe Information in einem Absatz muss erst jemand parsen.

• Text, keine Screenshots von Text. Die meisten Retrieval-Pipelines können Bilder nicht auslesen. Ein Screenshot illustriert, aber kein Schritt darf nur im Screenshot stehen.

• Ehrliche Aktualität. Veraltete Doku führt Agenten (und ihre Nutzer) genauso in die Irre wie Menschen, nur in großem Maßstab. Zeitstempel an Einträgen und ein gepflegter Changelog geben Agenten das Signal, aktuelle Inhalte vorzuziehen.

Ein Muster gibt es erst, seit Agenten mitlesen: Artikel nur als Kontext für die KI. Manches Wissen – bekannte Einschränkungen, Details zu Workarounds, Feinheiten einer Migration – soll dein KI-Support nutzen, ohne dass es im Hilfecenter für Interessenten steht. Unterstützt dein Content-Backend für Artikel eine Sichtbarkeit nur für die KI, beantwortet der Assistent mehr, als deine öffentliche Doku zeigt, ohne dass diese Artikel im öffentlichen Hilfecenter auftauchen. Privat sind sie damit nicht: Der Assistent zitiert sie jedem, der fragt.

Was dir das konkret bringt

„Bereit für Agenten“ klingt abstrakt, bis du einen Weg nachverfolgst. Ein Entwickler fragt seinen Coding-Assistenten: „Wie paginiere ich Ergebnisse in {dein Produkt}?“ Der Assistent ruft /llms.txt ab, folgt dem Link zur API-Doku, liest den Abschnitt zur Paginierung und schreibt funktionierenden Code mit Quellenangabe. Diese Antwort stützt sich entweder auf deine Inhalte oder auf eine zwei Jahre alte Antwort auf Stack Overflow. Rechne das hoch auf jede Integrationsentscheidung, jeden Anbietervergleich und jede Support-Frage, die heute über einen Agenten läuft, dann ist klar, worum es geht.

Eine pragmatische Reihenfolge

1. Bring zuerst die Struktur in Ordnung: Artikel mit der Antwort am Anfang, Überschriften, typisierte Felder. Das verbessert die Doku für Menschen schon heute, und alles Weitere baut darauf auf.

2. Stell /llms.txt online, generiert aus deiner Content-API.

3. Bau einen MCP-Server oder übernimm einen, über deine Content-Plattform, falls sie einen anbietet.

4. Achte in deinen Logs auf User-Agents von KI-Agenten und Abrufe von llms.txt; echter Traffic zeigt dir, wo du nachlegen solltest.

Keiner dieser Schritte ist groß, und ihre Wirkung summiert sich: Dieselben strukturierten Inhalte aus der API, die deine Seiten rendern und deine Suche speisen, machen dich auch für das am schnellsten wachsende Publikum deiner Doku lesbar.