Certains de vos lecteurs ne sont pas humains.
Un développeur qui travaille avec un assistant a besoin de la documentation dans une forme que l’assistant peut avaler. ApiGlow produit ces fichiers depuis le schéma chargé, côté client — il n’appelle aucun modèle et ne fait tourner aucun serveur.
La passation, dessinée — la page en prose, la même en Markdown, et les fichiers qu’un agent emporte.
Les deux fichiers qu’un assistant réclame.
llms-full.txt, c’est toute la documentation en un seul fichier Markdown : les informations de l’API, les serveurs, vos pages de prose, chaque opération et chaque webhook. C’est ce qu’on colle dans une fenêtre de contexte quand on veut que l’assistant connaisse simplement l’API.
llms.txt, c’est l’index du même contenu, suivant la convention llmstxt.org — un lien par opération et par webhook, pointant vers les routes de la page. C’est ce qu’un agent récupère quand il préfère naviguer qu’avaler.
Les deux sont produits depuis le schéma, dans le navigateur du lecteur. Aucun modèle n’est appelé, et rien n’est téléversé pour les fabriquer.
Un menu de transmission sur chaque page.
N’importe quelle page se copie en Markdown ou s’affiche en Markdown, pour qu’un agent reçoive la prose sans le décor. Le menu Copier pour l’IA de l’en-tête, identique sur chaque page, transmet l’API entière : les deux fichiers texte, une commande claude mcp add en une ligne, et des liens d’installation pour Cursor et VS Code. La page d’accueil porte le même enregistrement sous forme de bloc JSON.
La carte MCP branche l’un des deux ponts OpenAPI-vers-MCP disponibles sur étagère — au choix — et sort avec les identifiants sous forme d’emplacements vides, jamais de valeurs. Quand un schéma de sécurité n’est pas un en-tête, la carte le dit franchement au lieu de générer quelque chose qui ne marchera pas.
Et un agent qui corrige le schéma.
L’audit du schéma a une catégorie prêt pour les agents : ce qu’obtient un agent qui appelle votre API à travers un outil. Des entrées sans type, des unions qu’il ne sait pas départager, des valeurs d’enum que rien n’explique, des erreurs renvoyées en prose — chaque constat nomme ce qui casse concrètement dans un pont MCP ou une GPT Action.
Le paquet npm livre une skill d’agent pour l’autre sens. Elle lance apiglow audit, lit le rapport JSON — chaque constat placé en fichier:ligne:colonne, avec son correctif — corrige le schéma et audite à nouveau. Elle n’invente jamais ce que fait votre API pour remplir une description, et ne fait jamais passer le contrôle en éteignant une règle : ces décisions restent les vôtres.
Et les robots qui n’exécutent aucun JavaScript.
Les assistants qui récupèrent plutôt qu’ils ne naviguent ont le même problème que les moteurs de recherche : une application monopage, c’est une seule URL. Le miroir statique est la réponse —apiglow bake écrit une page HTML et Markdown par route, un sitemap et un llms.txt servi, depuis une commande lancée à côté de votre déploiement.Ce que ce n’est pas.
ApiGlow ne fait pas tourner d’assistant. Il n’y a pas de chat dans la documentation, pas de modèle derrière, pas de clé à fournir — il produit des fichiers, et c’est autre chose qui les lit.
La carte MCP configure un pont tiers. Ce que ce pont sait faire regarde le pont, et la carte est honnête sur les cas qu’elle ne peut pas couvrir.