Prismic is Needs Work to agents.
Discry independently scored how well an AI agent can discover and understand the Prismic 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 · 40/100Comprehension
55% of score · 87/100What we found
- An agent can read Prismic's docs as clean markdown out of the box — pages serve text/markdown via content negotiation and internal links use .md URLs (e.g. /docs/nextjs.md). Prismic explicitly states its documentation is 'written for humans and AI agents,' which is rare and a strong comprehension signal.
- Prismic ships an official MCP server (prismicio/prismic-mcp-server) and an official agent-skills repo (prismicio/skills, compatible with Claude Code, Codex, and Cursor), both listed across Glama, Composio, and mcp.so. An agent looking to operate Prismic content has first-party tooling, not just docs.
- There is no publicly accessible OpenAPI/Swagger spec (standard paths 404) and no AGENTS.md in the primary repos — so an agent doing machine-readable discovery of the API surface or repo conventions comes up empty, despite the strong human/MCP tooling.
- robots.txt allows all crawlers but carries a Content-Signal of ai-train=no, ai-input=no — Prismic deliberately signals that its content should not be used as AI training or AI input, a friction point for agent grounding even though crawling is permitted.
- The Content API is a single predicate-based query endpoint (documents/search) rather than many REST routes; examples use realistic values (real-looking IDs, ISO 8601 dates, named authors) and capability boundaries (URL length, rate limits, filter-to-field compatibility tables, visibility tiers) are clearly documented.
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Publish a machine-readable OpenAPI spec for the Content API (and the Asset/Migration APIs) at a discoverable path — this is the single biggest discovery gap (weight 5) and would let agents enumerate the API surface without scraping reference prose.
- 02Add an AGENTS.md to the primary repos (prismic-client, slice-machine, prismic-mcp-server) pointing agents to the skill, MCP server, CLI, and the .md docs. Quick win given Prismic already invests heavily in agent tooling.
- 03Reconsider the Content-Signal 'ai-input=no' directive in robots.txt — for an agent-readiness posture it tells RAG/agent tools not to ground on Prismic content, undercutting the otherwise excellent AI-facing docs.
- 04Add a dedicated error-codes-and-recovery section to the Content API reference: list HTTP status codes, the JSON error shape, and explicit recovery steps (e.g. refresh the ref on expiry, honor rate-limit backoff, supply an access token on 403) so agents can self-correct instead of failing blind.
- 05Add an llms-full.txt and tighten llms.txt to be API-focused rather than a marketing/product overview — the current llms.txt is well-structured but product-led, which dilutes its usefulness for an agent trying to understand the API specifically.
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 for a read-oriented API: explicit rate limits (200 req/s, CDN-cached queries exempt, SDK auto-retries after 1s), pagination (page/pageSize, max 100 pages per response), and a tiered access-token auth model (Open / Public-for-master / Private). There is no documented structured error-response schema, and idempotency is not addressed (the Content API is a read-only GET surface and is naturally idempotent).