Maschinelle Leser
Was ein Modell bekommt — llms.txt, das rohe Markdown jeder Seite und ein echter MCP-Server.
Dokumentation wird von Modellen ebenso gelesen wie von Menschen, und alle vier Antworten unten werden aus denselben Collections erzeugt, aus denen die Seiten rendern — keine von ihnen kann also von dem abweichen, was veröffentlicht ist.
| Pfad | Was es ist |
|---|---|
/llms.txt | Ein Index: Seitenname, Zusammenfassung, dann jede .md-Seite als Link |
/llms-full.txt | Eine duxt-Erweiterung: dieselben Seiten in einer Markdown-Datei |
<seite>.md | Der Markdown-Quelltext jeder Seite |
/mcp | Ein MCP-Server — vier Werkzeuge, von list_versions bis read_page |
Markdown, nicht HTML
Alles hier übergibt das Markdown so, wie es geschrieben wurde — deshalb bittet
das Collection-Schema Content darum, rawbody zu speichern. Ein Modell, dem man
gerendertes HTML gibt, muss ein Layout rückgängig machen, um eine Überschrift zu
finden; eines, dem man die Quelle gibt, liest, was der Autor geschrieben hat,
mit Code-Fences, die noch Fences sind, und einem MDC-Block, der noch ein
Komponentenaufruf ist.
<seite>.md wird von einer Middleware ausgeliefert statt von einer Route,
denn .md ist ein Suffix am letzten Pfadsegment und kein eigenes Segment — es
gibt kein Nitro-Routenmuster, das „jeder Pfad, der auf .md endet“ bedeutet.
Wie eine Seite sich selbst ankündigt
Nichts davon muss erraten werden. Jede Dokumentationsseite trägt zwei Link-Relationen im Head — die erste benennt ihr eigenes Markdown, die zweite den Index, der sie abdeckt:
<link rel="alternate" type="text/markdown" href="/duxt/getting-started.md" />
<link rel="describedby" href="/llms.txt" />
Die Alternate zeigt auf die gerade gerenderte Seite und nicht auf ihr
canonical, sodass eine alte Version ihren eigenen Quelltext übergibt statt den
der aktuellen. Beide sind absichtlich <link>-Elemente und keine
HTTP-Link-Header: Eine vorgerenderte Seite behält sie, wenn ein Edge sie als
statische Datei ausliefert — ohne Header-Konfiguration irgendwo im Deployment.
Warum beide llms-Dateien
Die Konvention von llmstxt.org definiert den Index. duxt
ergänzt /llms-full.txt für ein Modell, das die .md-Links nicht Seite für
Seite abrufen kann und dieselbe Dokumentation der Standardversion auf einmal
braucht.
Warum ein echter MCP-Server
/mcp spricht das Protokoll über das offizielle SDK, statt ein JSON-Endpunkt
nach duxts eigenem Entwurf zu sein. Ein Client verbindet sich damit so wie mit
allem anderen, statt dass jemand einen Adapter um eine Form herum schreibt, die
nur dieses Theme hat.
Der Server bietet vier begrenzte Werkzeuge: list_versions, list_pages,
search_docs und read_page. Die Suche umfasst Titel, Beschreibungen und den
geschriebenen Markdown-Text; Quelle, Version und Pfadpräfix können sie
eingrenzen. Sie verwendet bewusst nicht den clientseitigen Browserindex: Das
Werkzeug besitzt die bereitgestellte Content-Datenbank und liefert Ergebnisse
seitenweise in protokollgerechter Größe. Argumente und Ergebnisformen stehen
unter MCP-Endpunkt.