Cypress is Good to agents.
Discry independently scored how well an AI agent can discover and understand the Cypress 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 · 67/100Comprehension
55% of score · 100/100What we found
- An agent evaluating Cypress finds a deliberately agent-optimized documentation surface: llms.txt advertises purpose-built markdown, full-JSON, and chunked-JSON doc formats (/llm/markdown/, /llm/json/full/, /llm/json/chunked/) with explicit llm_guidance on which to use — a rare, best-in-class signal.
- Discovery is strong but not perfect: robots.txt explicitly allows every major AI crawler (GPTBot, ClaudeBot, anthropic-ai, CCBot) with a Content-Signal ai-train=yes header, an AGENTS.md ships in cypress-io/cypress, and an official Cypress Cloud MCP server is listed on PulseMCP — yet there is no OpenAPI spec and no .well-known/mcp.json.
- Comprehension is reference-quality: command pages lead with a one-line task description, show realistic copy-pasteable examples across E2E/component and JS/TS variants, and maintain a clean Syntax→Usage→Arguments→Examples heading hierarchy an agent can parse reliably.
- Error recovery is a standout — the common-errors page enumerates each failure (e.g. 'element cannot be interacted with'), lists its four possible causes, and gives explicit remediations ({ force: true }, guarding commands, splitting cross-origin visits into separate tests). An agent can self-correct instead of only discovering limits by failing.
- The main penalty is a rubric artifact: Cypress is an SDK/testing framework, not a REST service, so the OpenAPI-spec check (weight 5) and .well-known/mcp.json check register as fails even though the machine-readable JSON doc corpus arguably serves the same purpose for agents.
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Serve /llms-full.txt (currently 404) as a concatenated dump of the existing /llm/markdown/ tree — the content already exists, so this is a near-zero-cost fix that recovers the llms-full.txt discovery signal agents probe for by convention.
- 02Publish a machine-readable spec for the Cypress Cloud REST API (OpenAPI/Swagger) and link it from llms.txt — this is the single highest-weight discovery gap (weight 5) and would let agents programmatically drive Cloud endpoints.
- 03Add a /.well-known/mcp.json declaring the official Cloud MCP server's tools and OAuth flow so agents can auto-discover the MCP integration without a web search.
- 04Cross-link the AGENTS.md and the 'work-with-ai-agents' / AI-skills pages from llms.txt so an agent landing on the discovery file finds the agent-authoring guidance in one hop.
- 05Keep the purpose-built markdown/JSON doc formats prominent — they are a differentiator; surfacing them above the fold on the docs landing page would reinforce Cypress's agent-readiness lead.
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.
Cypress is a testing framework/SDK rather than a REST API, so traditional service-execution concepts (rate limits, pagination, idempotency) largely don't apply. Its execution surface — command errors and recovery — is exceptionally well documented, with a dedicated common-errors page listing causes and explicit fixes for each failure. cy.request supports the full set of HTTP methods; Cloud auth uses record keys/project IDs and the Cloud MCP uses OAuth.