llms.txt
What the two plain-text corpus files contain, how they are generated, and when their contents change.
Two files let an agent read Wellworn without an MCP client and without a key. Neither is rate limited, and both are generated from the database on every request rather than built at deploy time.
| File | What it holds | Size today |
|---|---|---|
/llms.txt | The map: what the service is, how to install it, the eight tools, the pages, and the URL scheme | about 3.4 KB |
/llms-full.txt | Every served verdict, in the exact block the MCP returns | about 28 KB |
Both are served as text/plain; charset=utf-8.
/llms.txt
The map file, in order: a paragraph on what the service answers; a one-line corpus census; the install command and the anonymous allowance; the eight tools with a one-line description each; the public pages with what each holds; the URL scheme for the five templated page types; a note on which pages are served noindex; and the licence.
The census line reads the database at request time and looked like this on 2026-09-08:
Corpus right now: verdicts served 25, flagged for recheck 0, traps 58, catalog tools 28242.Those four numbers are the only part of the file that moves on its own. The rest changes when someone edits the route, which happens when a tool or a page type is added.
/llms-full.txt
The whole served corpus as blocks, one per verdict, separated by a blank line, each preceded by its canonical URL. The header carries the count and the day it was generated:
# Wellworn verdicts, in the form the MCP returns them
# 25 served verdicts, generated 2026-09-08
# Verdicts are CC BY-SA 4.0. Source and provenance for each one are on its page.
URL https://wellworn.dev/verdicts/transactional-email-solo
VERDICT …The blocks come out of the same renderer the MCP calls, through the same mapping, so a block here is byte for byte what recommend or compare would return for that verdict, minus the remaining: line. That includes the 3,200-character cap and the [RECHECK] marker.
Verdicts of every kind are in the file, including the ones alternatives serves with its own layout; here they are rendered as compact blocks like the rest. The file holds up to 5,000 verdicts, ordered by verification date, newest first.
When the content changes
| Change | Reaches the files |
|---|---|
| A reviewer publishes or retires a verdict | Next request |
| The nightly pass flags a verdict for recheck | Next request after 02:00 UTC |
| A trap is published against a verdict's pick | Next request |
| A new tool or page type | When the route is edited and deployed |
Neither route sets a cache header of its own, and Cloudflare reports cf-cache-status: DYNAMIC on both, so what you fetch is what the database holds at that moment. At 28 KB the full file is cheap to refetch; there is no incremental feed and no If-Modified-Since support, so compare the generated date in the header line if you want to skip work.
Using them
Reading /llms-full.txt once is a reasonable substitute for many small recommend calls when you are working offline or want the whole corpus in context. It is also the honest way to see how small the corpus is: the header line states the count and the blocks below it are the whole of it.
The live counts sit on wellworn.dev/stats, which is the same query the census line runs.