llms.txt and an MCP config, generated from your docs.
Some readers are agents — or developers pairing with one. ApiGlow generates the take-away files an assistant actually uses, entirely client-side: the app calls no model and runs no server. They sit where each is wanted — the whole API on the home page, this endpoint in its own menu.
REAL SCREENSHOT, SHOWN AT 1:1
The whole doc as one Markdown.
llms-full.txt concatenates the documentation into a single Markdown file — the schema’s info, servers and security schemes, the prose pages, every operation and every webhook. It is the format assistants ingest in one piece, and its completeness is guarded by a test that walks the internal model and fails on anything the export silently ignores.
The map next to the territory.
llms.txt is the index of the same content, per the llmstxt.org convention: the prose pages under their nav groups, one link per operation grouped by tag, one per webhook, a Workflows section listing each declared scenario with its Arazzo recipe, closing on where to find the full text and the OpenAPI file — a link stated honestly, naming the overlays and hidden operations the published file does not reflect. Links are absolute URLs into the host page’s own routes, so an agent that reads the map can cite the territory. Operations hidden via schema control are absent here too — one pruning, every surface. In the app, llms.txt closes the navigation’s documentation zone as a button: the reader’s agent is one click from the map.An MCP config for your API — in the shape your tool takes it.
The home page generates the JSON block a reader pastes into their agent’s client config — Claude Desktop, Claude Code, and the like. It wires an off-the-shelf OpenAPI-to-MCP bridge, running on the reader’s machine, to this API’s schema URL; the bridge is picked from a card that links to each option’s own documentation.
The same registration also comes out as a claude mcp add one-liner for a terminal, and as install links for Cursor and VS Code. All three are generated from one config, so the command a reader pastes installs exactly what the block in front of them says.
Credentials come out as clearly marked placeholders, never as the values stored in the reader’s environments — a file meant to be handed to an agent must not carry anyone’s token. A scheme that cannot be expressed as a header is reported rather than approximated, and a schema provided inline gets no card at all: there is nothing for a bridge to fetch, and absent beats wrong.
Every endpoint, ready to leave the page.
Each operation carries a “Copy page” menu that answers one question — give me this page somewhere else. Copy the endpoint as Markdown, or read the source first in a raw view that can save it as a file. Hand it to ChatGPT or Claude in a new tab, the documentation already embedded in the prompt. Or take the whole API: llms-full.txt and the MCP registration, which stays API-wide even here, because what an agent needs is the document rather than one endpoint.
A reader pairing with an assistant does not have to describe your endpoint to it, or paste a screenshot of it. They hand over the same Markdown your documentation is built from.
Files to host, not features to configure.
The documentation is a hash-based single page — no crawler or LLM can browse it by URL. So the two files are meant to be generated, then dropped next to the host page and served statically at the site root (https://docs.example.com/llms.txt). Regenerate them when the schema changes; they are snapshots, not mirrors.
Or skip the hand-copying: apiglow bake writes both as served files — with links re-pointed at the baked Markdown mirror of every page, which is what an agent can actually fetch.
See it in the live demo.