llms.txt et une config MCP, générés depuis votre doc.
Certains lecteurs sont des agents — ou des développeurs qui travaillent avec. ApiGlow génère les fichiers à emporter qu’un assistant utilise vraiment, entièrement côté client : l’application n’appelle aucun modèle et ne fait tourner aucun serveur. Chacun se trouve là où on le veut — l’API entière sur l’accueil, l’endpoint dans son propre menu.
CAPTURE RÉELLE, AFFICHÉE À 1:1
Toute la doc en un seul Markdown.
llms-full.txt concatène la documentation en un seul fichier Markdown — l’info du schéma, les serveurs et les schemes de sécurité, les pages de prose, chaque opération et chaque webhook. C’est le format qu’un assistant ingère d’un bloc, et sa complétude est gardée par un test qui parcourt le modèle interne et échoue sur tout ce que l’export ignorerait en silence.
La carte à côté du territoire.
llms.txt est l’index du même contenu, selon la convention llmstxt.org : les pages de prose sous leurs groupes de navigation, un lien par opération groupée par tag, un par webhook, une section Workflows qui liste chaque scénario déclaré avec sa recette Arazzo, et pour finir où trouver le texte complet et le fichier OpenAPI — un lien énoncé honnêtement, qui nomme les overlays et les opérations masquées que le fichier publié ne reflète pas. Les liens sont des URL absolues vers les routes de la page hôte, si bien qu’un agent qui lit la carte peut citer le territoire. Les opérations masquées via le contrôle du schéma sont absentes ici aussi — un élagage, toutes les surfaces. Dans l’app, llms.txt ferme la zone documentation de la navigation, en bouton : l’agent du lecteur est à un clic de la carte.Une config MCP pour votre API — dans la forme que prend votre outil.
La page d’accueil génère le bloc JSON qu’un lecteur colle dans la config de son client d’agent — Claude Desktop, Claude Code, et consorts. Il branche un pont OpenAPI→MCP du commerce, qui tourne sur la machine du lecteur, sur l’URL du schéma de cette API ; le pont se choisit depuis une carte qui renvoie vers la documentation de chaque option.
Le même enregistrement sort aussi en ligne de commande claude mcp add pour un terminal, et en liens d’installation pour Cursor et VS Code. Les trois viennent d’une seule config : la commande qu’un lecteur colle installe exactement ce que dit le bloc sous ses yeux.
Les credentials sortent en placeholders clairement marqués, jamais avec les valeurs stockées dans les environnements du lecteur — un fichier destiné à un agent ne doit porter le jeton de personne. Un scheme inexprimable en en-tête est signalé plutôt qu’approximé, et un schéma fourni en ligne n’a pas de carte du tout : il n’y a rien qu’un pont puisse télécharger, et absent vaut mieux que faux.
Chaque endpoint, prêt à quitter la page.
Chaque opération porte un menu « Copier la page » qui répond à une seule question : donne-moi cette page ailleurs. Copiez l’endpoint en Markdown, ou lisez d’abord la source dans une vue brute qui sait l’enregistrer en fichier. Tendez-le à ChatGPT ou à Claude dans un nouvel onglet, la documentation déjà glissée dans le prompt. Ou emportez l’API entière : llms-full.txt et l’enregistrement MCP, qui reste à l’échelle de l’API même ici — ce dont un agent a besoin, c’est du document, pas d’un endpoint.
Un lecteur qui travaille avec un assistant n’a plus à lui décrire votre endpoint, ni à lui en coller une capture d’écran. Il lui tend le Markdown dont votre documentation est faite.
Des fichiers à héberger, pas des options à configurer.
La documentation est une page unique à routes # — aucun crawler ni LLM ne peut la parcourir par URL. Les deux fichiers sont donc faits pour être générés, puis déposés à côté de la page hôte et servis statiquement à la racine du site (https://docs.example.com/llms.txt). Régénérez-les quand le schéma change : ce sont des instantanés, pas des miroirs.
Ou évitez la copie à la main : apiglow bake écrit les deux en fichiers servis — avec des liens repointés vers le miroir Markdown baké de chaque page, ce qu’un agent peut réellement récupérer.
Voyez-le dans la démo.