Documentation an agent can read.

ApiGlow’s reader might be a person, 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, and no model is ever called.

Each take-away sits where it is wanted — the whole-API files in the header’s “Copy for AI” menu, on every page, and the per-page ones in each page’s “Copy page” menu. The short version is on the agents pillar; 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. It is the format assistants ingest in one piece. Copy or download it from the header’s “Copy for AI” menu, on any page.

llms.txt is the index of the same content, per the llmstxt.org convention. It carries:

• 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, and one per webhook
• pointers to the full text and the OpenAPI file

The header states the base URL and an orientation line on the auth schemes. The Reference link is qualified: when the documentation renders the schema through overlays, or hides operations the published file still declares, the link says so, so an agent reading the raw file knows it differs from what the humans see.

In the app, both files live in the header’s “Copy for AI” menu, each copied or downloaded, rather than in the navigation: they are generated on the spot, so there is no page to navigate to.

Every URL they hand out carries your environment’s {{variables}} filled in, since nothing outside the page knows them. A base URL that would need a sensitive value, or a variable nobody set, gives way to the document’s own server — never a file carrying a secret or a literal {{name}}.

Host them next to the page

The docs are a hash-routed application, so a crawler or an LLM cannot browse #/op/… URLs. That is 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.

The served versions carry more 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, so when the schema changes, re-run the bake — or regenerate by hand — and redeploy alongside the page.

The MCP config card

For agents that speak MCP, the home page generates a ready-to-paste server config. It wires an off-the-shelf OpenAPI→MCP bridge, running on the reader’s machine and 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, and the like), 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. All three are built from one config, so the command installs exactly what the block in front of you says.

Three behaviours 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, or mutualTLS — is reported as such rather than approximated.
• 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 rule governs the command and the install links too.

Two menus: this page, and the whole API

The take-aways are not only on the home page. Two menus answer two questions.

“Copy page” — give me this page somewhere else — sits on every endpoint and every prose page.

This page, 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, since the docs are hash-routed and there is no ?format=md address to hand anyone.

This page, 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, because browsers cap URL length. The truncation is marked, so a long page arrives visibly shortened rather than silently mangled.

“Copy for AI” — give an assistant or an agent the whole API — sits in the header, the same on every page.

The whole documentation, for an assistant. llms-full.txt and llms.txt, each copied or downloaded. Pasted into a chat, llms-full.txt is the documentation itself; llms.txt is a list of links an assistant can only follow when the bake serves the Markdown mirrors.

The whole API, wired to an agent. The MCP registration in two of its shapes: the claude mcp add … command, and the Cursor and VS Code install links. They come out of the same config as the home page’s card, so the command installs exactly what the card shows. The base URL follows the environment you have selected, so registering from a sandbox environment produces a sandbox registration. With an inline schema the section is simply absent, for the reason the card is.

An agent that fixes the schema

The other direction: an agent working on your API rather than with it. The schema audit grades what an agent will get from the document — its agent readiness category covers untyped inputs, ambiguous unions, unexplained enum values and errors returned as prose. And the npm package ships an agent skill, skills/apiglow-audit/SKILL.md, that runs apiglow audit, fixes the findings and audits again — without inventing what your API does, and without silencing a rule on its own.