Strapi is Good to agents.
Discry independently scored how well an AI agent can discover and understand the Strapi API from what’s public — not whether it’s usable. Below: every signal we checked, what’s costing the score, and what to change.
SCORED UNDER RUBRIC 1.2 · A full re-launch under Discry Score 2.5 — a new behavioral instrument, not comparable to these scores — is in progress.
Discovery
45% of score · 79/100Comprehension
55% of score · 96/100What we found
- An agent crawling Strapi's docs is welcomed everywhere: robots.txt allows all bots, and both llms.txt (full doc index with per-page descriptions) and a 2.1MB llms-full.txt of clean markdown are published — every page also exposes explicit 'Markdown Mode' and 'AI Mode' toggles. This is among the most agent-optimized doc setups for a CMS.
- Comprehension is near-exemplary: endpoint pages lead with method + URL + a task-oriented purpose ('Returns a paginated list of documents. Supports filtering, sorting...'), each page opens with a 'Page summary' blockquote (answer-first), and examples ship in cURL, fetch, and axios with realistic values (e.g. documentId 'bw64dnu97i56nq85106yt4du', user@example.com).
- Strapi documents its own native MCP server (a /mcp JSON-RPC endpoint) with an explicit 'Known limitations' section, and multiple community Strapi MCP servers are listed across PulseMCP, Glama, and Smithery — an agent can discover a ready-made integration path immediately.
- Capability boundaries are unusually well covered: per-plan upload size limits, populate depth limits, 'cannot filter dynamic zones/polymorphic relations', foreign-key constraints, and rate-limited endpoints are all stated explicitly rather than left for an agent to discover by failing.
- Discovery is held back by Strapi's framework nature: there is no single canonical, fetchable OpenAPI spec (it is generated per-instance via an experimental CLI), no .well-known/mcp.json, and the llms.txt is oversized (~82KB / ~20K tokens) because it indexes the entire site rather than an API-scoped subset.
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Publish a canonical, hosted OpenAPI 3.1.0 spec for the standard Content API shape (the generic /api/:pluralApiId CRUD + Users & Permissions endpoints) at a stable URL, and graduate the OpenAPI generator out of 'experimental' — this is the single heaviest discovery signal and currently the biggest gap.
- 02Add a /.well-known/mcp.json pointing at the native Strapi MCP server so agents can auto-discover the official MCP integration without searching third-party registries.
- 03Ship an API-scoped llms.txt (or a second, trimmed file) covering just the REST/GraphQL Content API and auth, kept under ~50KB, so the index is right-sized for agent consumption instead of dumping the entire Cloud + CMS site.
- 04Consolidate error recovery into a single reference that maps each common status (400/401/403/405/429) to explicit fix steps — in particular, document the rate-limit Retry-After / back-off behavior, which is currently mentioned ('this endpoint is rate limited') without recovery guidance.
Execution coverage · INFORMATIONAL, UNSCORED
Whether an agent can actually complete a call and recover from errors is the deeper Audit layer — documented here, but not part of the Discry Score.
Execution characteristics are well documented. Errors return a consistent JSON object (status, name, message, details). Auth covers API tokens (Bearer), Users & Permissions JWT, and OAuth providers. Pagination is documented in both nested page/pageSize and offset start/limit forms with a meta.pagination response object. Rate limiting is acknowledged on specific auth endpoints and via configurable defaultLimit/maxLimit, but global numeric limits and Retry-After header semantics are not specified. No idempotency-key mechanism is documented.