Machine readers
What a model gets — llms.txt, the raw Markdown of any page, and a real MCP server.
Documentation is read by models as much as by people, and all four answers below are generated from the same collections the pages render from — so none of them can drift from what is published.
| Path | What it is |
|---|---|
/llms.txt | An index: site name, summary, then every page as a linked entry |
/llms-full.txt | The same pages, whole, concatenated into one Markdown file |
<page>.md | Any page's own Markdown source |
/mcp | An MCP server — list_pages, search_docs, read_page |
Markdown, not HTML
Everything here hands over the Markdown as it was written, which is why the
collection schema asks Content to store rawbody. A model given rendered HTML
has to undo a layout to find a heading; one given the source reads what the
author wrote, with the code fences still fences and an MDC block still a
component call.
<page>.md is served by a middleware rather than a route, because .md is a
suffix on the last path segment and not a segment of its own — there is no Nitro
route pattern meaning "any path ending in .md".
Why both llms files
The llmstxt.org convention names two, and they answer different questions: a model that has read the index still has to fetch sixty pages, and a model handed the full file has already read them. Which one is cheaper depends on the question, so the site publishes both.
Why a real MCP server
/mcp speaks the protocol through the official SDK rather than being a JSON
endpoint of duxt's own design. A client connects to it the way it connects to
anything else, instead of someone writing an adapter around a shape only this
theme has.
Its search is a LIKE over titles and descriptions, not the index the browser
uses: that one is built client-side from the collection dump, and a server tool
has the database itself.