Plausible is Needs Work to agents.

What we found

• —Plausible's documentation is excellent for comprehension but nearly invisible to agent-discovery infrastructure: there is no llms.txt, no llms-full.txt, and no AGENTS.md, so an agent that doesn't already know the doc URLs has no machine-readable entry point and must scrape Docusaurus HTML.
• —Positive: a real, official MCP server exists (built by the Sentry team, getsentry/plausible-mcp) and Plausible documents it at /docs/data-access — an agent wanting to query Plausible data can discover a ready-made natural-language tool instead of wiring the REST API by hand. This is the strongest discovery signal on the site.
• —The Stats API is built around a single consolidated endpoint (POST /api/v2/query) with task-oriented descriptions, ISO8601 date handling, consistent snake_case naming, and roughly eight realistic worked examples — an agent can understand and call the entire analytics surface from one answer-first page.
• —Capability boundaries are unusually well documented: explicit rate limits (600 req/hr), a dedicated 'Quirks' section, plan-gating (Stats = Business, Sites = Enterprise), a 2,000-character URL cap, and data-URI exclusions — an agent learns the limits before it fails rather than after.
• —Error recovery is the weak spot: the Stats and Sites APIs document only success responses with no 400/401 error body schema or fix guidance, so a rejected request leaves an agent guessing which field was invalid; only the Events API offers real debugging guidance (x-plausible-dropped header, X-Debug-Request header, /api/health endpoint).

What to change

Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.

1. 01Publish an llms.txt (and llms-full.txt) at plausible.io/llms.txt indexing the Stats, Events, and Sites API reference pages with one-line descriptions. This is the single highest-leverage discovery fix and would point any agent straight at the machine-readable docs.
2. 02Generate and host an OpenAPI spec at a stable public URL (e.g. /docs/openapi.json) for the v2 query, events, and sites endpoints. It is the highest-weighted discovery check (5) and currently a hard fail, and it unlocks client codegen and automatic tool wiring.
3. 03Document error responses: add the actual 400/401 JSON error body shape for the Stats and Sites APIs and map common causes (invalid metric/dimension, malformed date_range, expired key, plan not entitled) to explicit fixes. This is the biggest remaining comprehension gap.
4. 04Add an AGENTS.md to the plausible/analytics and plausible/docs repositories so coding agents working with the SDK or self-hosted build get setup and usage context.
5. 05Add the /docs documentation pages to a sitemap — the root sitemap.xml currently lists only marketing and blog URLs — so crawlers and agents can enumerate the API reference.