FusionAuth is Good to agents.
Discry independently scored how well an AI agent can discover and understand the FusionAuth 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 · 91/100What we found
- An agent integrating FusionAuth lands on excellent reference docs: every endpoint page leads with the HTTP method and path, uses realistic example values (richard@piedpiper.com, username 'neo', real UUIDs and JWTs), and documents each field with type, default, version-availability ('Available since 1.30.0') and deprecation flags — comprehension scored 91/100 (A).
- Discovery is strong for an auth vendor: robots.txt allows all AI crawlers, a publicly accessible OpenAPI v3 spec exists (github.com/FusionAuth/fusionauth-openapi), an official FusionAuth MCP server is listed on PulseMCP and Glama, and all /docs/apis/* pages are in the sitemap.
- FusionAuth ships TWO llms.txt files — a root site-wide one and a dedicated, well-structured /docs/llms.txt (47KB) that indexes every API group — so an agent can quickly map the full API surface to markdown sources.
- Multi-step workflows are well covered: 20+ framework quickstarts ('add auth in 15 minutes'), a Get Started step sequence, and chained flows like Start Forgot Password Workflow -> Change Password give an agent end-to-end task guidance, not just isolated endpoints.
- The main gaps are agent-discovery niceties rather than substance: no llms-full.txt, no /.well-known/mcp.json, and the AGENTS.md only appears in a tooling repo (fusionauth-node-cli) rather than a primary repo. Error docs explain status codes and surface descriptive field errors, but stop short of explicit recovery steps (no backoff / Retry-After guidance).
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Add a /.well-known/mcp.json declaring the existing official FusionAuth MCP server's tools and auth — the server already exists in the registries, so surfacing it at the well-known path is a near-zero-cost discovery win.
- 02Publish an llms-full.txt (or expose the docs llms.txt content as a single concatenated markdown bundle) so agents can ingest core API usage in one fetch instead of crawling dozens of pages.
- 03Add explicit error-recovery guidance to the Error Codes and key endpoint pages: for the top 5-10 failures (401 invalid key, 400 duplicate field, 503 throttling) state the concrete fix and any retry/backoff expectation, not just the status-code meaning.
- 04Make the root-domain llms.txt API-focused (or have it point first to the docs llms.txt). Today it reads as a product/marketing link list; an agent assessing capability hits company, careers, and legal links before API docs.
- 05Promote AGENTS.md to the primary developer-facing repos (client SDKs, fusionauth-site, OpenAPI repo) with API-usage context, rather than leaving it only in fusionauth-node-cli.
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 thoroughly documented. The Errors object is a machine-parseable JSON structure with general and field-level error codes plus descriptive messages, and a complete HTTP status-code table maps each code to its meaning. Multiple auth methods are documented with realistic curl examples. Search/pagination is offset-based (startRow + numberOfResults + sortFields). No specific rate limits or rate-limit header names are published (FusionAuth is primarily self-hosted; a 503 is the only documented throttling signal), and idempotency keys are not documented.