Auth0 is Agent-Ready to agents.
Discry independently scored how well an AI agent can discover and understand the Auth0 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
- Auth0 is deliberately agent-first: they have an official MCP server, agent-skills repo, AGENTS.md in SDKs, a 'Review Auth0 Agent Experience Score' docs page, and a Documentation Index callout on every page directing agents to llms.txt
- The Management API documentation is exceptionally comprehensive with detailed pagination guidance (offset vs checkpoint), scope-based auth explanation, and practical curl examples
- Both llms.txt (405KB) and llms-full.txt (742KB) exist and are API-focused, though both exceed the ideal 50KB threshold for single-context-window consumption
- Multi-step workflow documentation is best-in-class: the Authorization Code Flow page walks through a 10-step sequence with diagram, then links to implementation guides
- The only significant gap is .well-known/mcp.json — ironic given Auth0 has an official MCP server but doesn't advertise it via the standard discovery mechanism
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Add .well-known/mcp.json pointing to the official Auth0 MCP server — trivial win given the server already exists
- 02Create a condensed llms.txt under 50KB covering core auth flows (Authorization Code, Client Credentials, Device) with the current comprehensive version becoming llms-full.txt
- 03The current llms.txt is already labeled correctly but could benefit from a focused subset for agents that only need core API operations
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.
JWT-based Management API access tokens with scope-based permissions. Bearer auth in Authorization header. JSON error responses with structured error codes. Both offset-based and checkpoint-based (cursor) pagination documented with per-plan limits (50 items for public cloud, 100 for private). Checkpoint IDs expire after 24 hours. Rate limits documented per endpoint category. X-Correlation-ID header for request tracking. No idempotency keys mentioned.