Documentation an agent can read.

ApiGlow’s reader might be a person — or an agent, or a person pairing with one. The app produces every take-away that reader needs in the browser: this documentation runs no server, so there is nowhere else to produce them, and no model is ever called. They are reachable from wherever each is wanted — the whole-API files from the home page and the navigation, the per-endpoint ones from each operation’s “Copy page” menu. The short version lives on the AI surface feature page; this guide is the how-to.

Generate the two text files

llms-full.txt is the whole documentation as one Markdown document — schema info, prose docs pages, every operation — the format assistants ingest in one piece. Generate it from the home page, or from the “Copy page” menu of any operation.

llms.txt is the index of the same content, per the llmstxt.org convention: the docs pages under their nav group’s title (top-zone pages as ## Guides, bottom-zone ones as ## Resources), a ## Workflows section listing each config-declared scenario with its step and input counts — and its Arazzo recipe when one is published — one link per operation grouped by tag, one per webhook, plus pointers to the full text and the OpenAPI file. The header states the base URL and an orientation line on the auth schemes, and the Reference link is qualified honestly: when the documentation renders the schema through overlays, or hides operations the published file still declares, the link says so — an agent reading the raw file deserves to know it differs from what the humans see. llms.txt also closes the navigation’s documentation section — as a button, not a link: the file is generated on the spot, so there is no page to navigate to.

Host them next to the page

The docs are a hash-routed application: a crawler or an LLM cannot browse #/op/… URLs. That is exactly what the two files fix — but only if they are reachable. Drop both next to the host page and serve them statically at the site root:

docs.example.com/
├── index.html      ← the page with the ApiGlow script tag
├── llms.txt
└── llms-full.txt

Or let the bake serve them

Downloading and copying by hand works; apiglow bake automates it. The CLI writes llms.txt and llms-full.txt as served files in the same run that writes the HTML and Markdown mirrors — and the served versions are better than the downloads: llms.txt links the served .md mirror of every page instead of hash routes an agent cannot fetch, and each llms-full.txt section carries a Source: line pointing at its page. In-browser generation keeps hash links, since without a bake there is nothing else to point at.

Both files are snapshots of the loaded document — the app cannot reach over and update files on your server. When the schema changes, re-run the bake (or regenerate by hand) and redeploy alongside the page. If the docs deploy is scripted, this is one more step in the job, not a new pipeline.

The MCP config card

For agents that speak MCP, the home page also generates a ready-to-paste server config: it wires an off-the-shelf OpenAPI→MCP bridge — running on the reader’s machine, picked from the card — to this API’s OpenAPI URL. Credentials appear as clearly marked placeholders, never as values from anyone’s stored environments. Read the block, paste it into the agent’s client config (Claude Desktop, Claude Code, …), or download it as mcp.json.

The same registration also comes out in the two other shapes a reader’s tooling takes it in: a claude mcp add … one-liner to copy into a terminal, and install links for Cursor and VS Code that hand the whole thing to the editor. All three are built from one config, so the command installs exactly what the block in front of you says — there is no second source to drift from the first.

Three behaviors worth knowing: the card offers two bridges, which differ on Overlay support — picking the one that cannot apply your overlays is flagged, never silent; a security scheme with no header form (an apiKey in a query or a cookie, mutualTLS) is reported as such rather than approximated; and with an inline schema (openapi.spec) there is no card at all — a bridge needs a URL to fetch, and the page cannot hand it one. That last rule governs the command and the install links too: no URL, no registration in any shape.

The hand-off menu, on every endpoint

The take-away files are not only on the home page. Every operation’s “Copy page” menu answers one question — give me this page somewhere else — in three registers, from the narrowest to the widest.

This endpoint, as Markdown. Copy it to the clipboard, or open “View as Markdown” to read the source first: a dialog over the documentation showing the exact string the copy produces, verbatim in a <pre>, with a button to save it as {operationId}.md. It is a view rather than a URL on purpose — the docs are hash-routed, so there is no ?format=md address to hand anyone.

This endpoint, handed to an assistant. Two items open ChatGPT or Claude in a new tab with the endpoint’s Markdown already embedded in the prompt, under a line asking the assistant to read it and help use the endpoint. The Markdown is truncated past ~6 000 characters — browsers cap URL length, and a silently mangled prompt would be worse than a visibly shortened one.

The whole API, wired to an agent. llms-full.txt, plus the MCP registration in its three shapes. Note that this part stays API-wide even inside one operation’s menu: what an agent needs is the document, and the config never narrows to a single endpoint. Its base URL follows the environment you have selected, so registering from a sandbox environment produces a sandbox registration.