Lecteurs machines
Ce qu’obtient un modèle — llms.txt, le Markdown brut de n’importe quelle page et un vrai serveur MCP.
La documentation est lue autant par des modèles que par des personnes, et les quatre réponses ci-dessous sont générées à partir des mêmes collections que celles dont les pages sont issues — aucune ne peut donc diverger de ce qui est publié.
| Chemin | Ce que c’est |
|---|---|
/llms.txt | Un index : nom du site, résumé, puis chaque page comme entrée liée |
/llms-full.txt | Les mêmes pages, entières, concaténées en un seul fichier Markdown |
<page>.md | La source Markdown de n’importe quelle page |
/mcp | Un serveur MCP — list_pages, search_docs, read_page |
Du Markdown, pas du HTML
Tout ici transmet le Markdown tel qu’il a été écrit, et c’est pourquoi le schéma
de la collection demande à Content de stocker rawbody. Un modèle à qui l’on
donne du HTML rendu doit défaire une mise en page pour trouver un titre ; celui
à qui l’on donne la source lit ce que l’auteur a écrit, les blocs de code
toujours des blocs et un bloc MDC toujours un appel de composant.
<page>.md est servi par un middleware plutôt que par une route, car .md
est un suffixe du dernier segment du chemin et non un segment à part — il
n’existe pas de motif de route Nitro signifiant « tout chemin se terminant par
.md ».
Pourquoi les deux fichiers llms
La convention de llmstxt.org en nomme deux, et ils répondent à des questions différentes : un modèle qui a lu l’index doit encore récupérer soixante pages, tandis qu’un modèle à qui l’on remet le fichier complet les a déjà lues. Lequel revient le moins cher dépend de la question : le site publie donc les deux.
Pourquoi un vrai serveur MCP
/mcp parle le protocole via le SDK officiel plutôt que d’être un point de
terminaison JSON de la conception propre de duxt. Un client s’y connecte comme
il se connecte à n’importe quoi d’autre, au lieu que quelqu’un écrive un
adaptateur autour d’une forme que seul ce thème possède.
Sa recherche est un LIKE sur les titres et les descriptions, et non l’index
qu’utilise le navigateur : celui-ci est construit côté client à partir du
export de la collection, alors qu’un outil serveur dispose de la base de données
elle-même.