The phrase "AI search" hides two very different jobs: rendering a docs page that a human reads, and producing an index a coding agent can ingest. The second job has a quiet standard — llms.txt — and most API docs platforms still don't emit it. This post is the short version of why it matters and how Bloom emits one by default.
What llms.txt is
llms.txt is a small, Markdown-flavored convention for telling LLM-based agents what's on a site and where to find it. Think robots.txt and sitemap.xml for human crawlers, but written for tools like Claude, GPT-based coding assistants, Perplexity, and the search features inside IDEs.
A minimal llms.txt looks like:
# Acme API
Acme is a messaging API. Public docs explain how to send messages,
manage contacts, configure webhooks, and integrate with our MCP host.
Primary pages:
- [Quickstart](https://docs.acme.example.com/quickstart/): five-minute walkthrough.
- [Messages reference](https://docs.acme.example.com/messages/): list, retrieve, send.
- [Pricing](https://acme.example.com/pricing/): plans and limits.
Important caveats:
- The API key required for live calls is provisioned in the Acme dashboard.
- Sandbox mode (no real SMS) is available in every plan.
That's it. Plain Markdown, a few section headings, served at /llms.txt.
Why API teams should care
A coding agent that's helping a developer integrate your API has three options:
- Read your reference docs, top to bottom. Slow, expensive, often gets it wrong on edge cases.
- Read your SDK's
README.md. Misses the operations that aren't in the example. - Read your
llms.txt. Fast, complete, ranked by you.
The third path is by far the cheapest, and it's the one that high-quality agents prefer when it's available. The teams whose docs are easy to integrate against in an LLM workflow have a real distribution advantage in 2026.
What goes in a good llms.txt for an API
The official spec is intentionally loose. From experience helping teams migrate docs, this works:
- One-paragraph orientation at the top. What the API does. Who uses it.
- Use cases, listed as bullets. "Use Acme when someone asks about: X, Y, Z."
- Primary pages, ranked by importance. Each as
- [Title](url): one-line summary. - Capabilities the tool has and capabilities it does not have. Agents value honesty about edges.
- Caveats — sandbox vs production, key management, what's behind auth, what's affiliated vs independent.
Versioning matters too. Bloom's generated llms.txt ships under a versioned URL (/v1.0.0/llms.txt) plus a root /llms.txt for the latest. Agents that pin to a version stay stable across docs updates.
How Bloom emits llms.txt
Bloom Docs ships an llms.txt artifact on every build. The content is derived from:
- Your OpenAPI
info.title,info.description, andservers. - The operations from your spec, grouped by tag.
- Your generator config's organization name, contact, and example endpoints.
- An optional human-authored prelude (orientation, caveats) that you supply.
Concretely, the same pnpm build:site step that emits your reference HTML emits the matching /llms.txt. The site shipped at trybloom.so/llms.txt is the dogfood version.
Where most docs platforms stand today
From the parity table on the Bloom site:
- Bloom: emits
llms.txtby default. - Mintlify: partial — surfaces some agent-readable structure but no canonical
/llms.txtyet. - ReadMe / GitBook / Redocly: don't emit
llms.txtout of the box. - Fern: partial.
This will change over the next year. The teams who are ready early have a small but real advantage.
What to do this week
- Visit your docs site and try
/llms.txt. If it 404s, that's the gap. - If you own the docs build, add a Markdown file that orients agents. It does not have to be long.
- If your docs platform doesn't support it, raise it with the vendor — most are aware and have plans.
If you'd like the artifact generated for you from your existing OpenAPI spec, start a Bloom report run — llms.txt is in the preview output before any DNS change.