These docs are built to be read by coding agents as much as by people. Two conventions make that work: an llms.txt index and a Markdown twin of every page.
llms.txt
llms.txt is a standard from llmstxt.org: a Markdown file at the site root that gives an LLM the canonical list of documentation pages with one-line descriptions, so it can pick the right pages to read instead of guessing URLs or trusting stale training data.
Ours is at foony.io/llms.txt. It’s generated from the docs navigation at build time, so it always matches exactly the pages that exist.
Every page as Markdown
Append .md to any docs URL and you get the page as plain Markdown, with no HTML to strip:
curl https://foony.io/docs/publish-subscribe.md
The Markdown versions absolutize their internal links and point them at other .md pages, so an agent that follows links stays in Markdown. Each one also ends with a pointer back to llms.txt, so a page fetched in isolation still tells the agent how to find everything else.
Using this with your agent
For a one-off question, paste the relevant .md page into the conversation. For ongoing work against Foony, tell the agent where the index is. A line like this in a CLAUDE.md, AGENTS.md, or Cursor rules file works well:
Foony Realtime docs: fetch https://foony.io/llms.txt for the page list,
then fetch pages as Markdown by appending .md to their URLs.
Agents with web access, Claude Code, Cursor, and similar, will then pull current docs instead of inventing an API from memory. The SDK README files on npm and the TypeScript types are accurate too, so type-aware agents get a second grounded source.
Keeping answers honest
Generated code is only as good as its sources. If an agent produces Foony code that doesn’t match these docs, the docs win, and we’d genuinely like to know, since it usually means a page is unclear. The Errors reference and each SDK page carry the exact names and defaults, so point your agent there when it hallucinates an option.