Saleor is Agent-Ready to agents.
Discry independently scored how well an AI agent can discover and understand the Saleor 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 · 90/100Comprehension
55% of score · 96/100What we found
- An agent discovering Saleor lands cleanly: a well-structured, API-focused llms.txt maps every domain (products, checkout, orders, payments, webhooks) and links directly to the downloadable GraphQL schema, the API playground, and raw MDX source files — discovery is effectively solved.
- Saleor ships first-class agent infrastructure: AGENTS.md files across core, dashboard, and storefront repos plus a dedicated `saleor/agent-skills` repo following the Agent Skills Specification, and an official MCP server listed on both Glama and PulseMCP (mcp.saleor.app). This is a top-decile signal almost no competitor matches.
- Every documentation page carries a 'Copy for LLM' control and is mirrored as raw markdown/MDX on GitHub, so an agent never has to fight JS-rendered HTML to get clean, parseable content.
- Comprehension is excellent: task-oriented prose, realistic multi-language code samples (GraphQL, TS/TSX, HTTP, JSON), and dedicated end-to-end 'Recipes' (marketplace, multi-region, click-and-collect) that show how to chain operations rather than documenting endpoints in isolation.
- The one soft spot is error recovery: the API thoroughly documents error *structure* and codes (with enum references and GraphQL 'Did you mean' field suggestions), and the auth page gives concrete recovery flows (token refresh on expiry, throttling backoff), but there is no consolidated per-error 'what to do next' table covering the top failure scenarios.
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Add an llms-full.txt (currently 404). The llms.txt is already strong; a full markdown bundle of the core API-usage and concept pages would let an agent ingest Saleor's capabilities in a single fetch instead of crawling.
- 02Publish a /.well-known/mcp.json pointing at the existing official MCP server (mcp.saleor.app). The server already exists and is registry-listed — exposing it at the standard discovery path lets agents auto-detect it without a web search.
- 03Add an error-recovery layer to the error-handling docs: a table mapping the most common error codes (e.g., ExpiredSignatureError, PermissionDenied, UNIQUE, DISABLED_AUTHENTICATION_METHOD) to explicit fix steps, complementing the existing structure-focused explanations.
- 04Document idempotency for mutating operations (e.g., checkoutComplete / order creation). Agents that retry on timeout need to know whether a repeated mutation is safe; this is currently unaddressed.
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 documented to a high standard. Saleor's GraphQL error envelope is machine-parseable in two layers — query-level errors (an `errors` array with `message`, `locations`, and `extensions.exception.code`) and data-level mutation errors (a typed `errors` field with `field` + enum `code`), with explicit guidance to drive UX off `code` rather than `message`. Rate limiting is documented via login/password-reset throttling, a 100-item pagination cap, and a referenced usage-limits page (specific rate-limit header names are not named). Pagination follows the Relay cursor-connection spec. Idempotency keys are not documented in the scanned pages.