Frontegg is Needs Work to agents.
Discry independently scored how well an AI agent can discover and understand the Frontegg 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 · 36/100Comprehension
55% of score · 97/100What we found
- An agent that reaches any Frontegg doc page comprehends it almost perfectly: every page is published as clean markdown (with 'Copy for LLM', 'View as Markdown', and 'Open in Claude/ChatGPT' affordances), and a 47KB llms.txt indexes the entire site with described sections — comprehension scored A (97/100).
- But an agent trying to DISCOVER the API programmatically hits dead ends: the docs domain has no robots.txt (404), an empty sitemap.xml (200 but 0 bytes), no llms-full.txt, no .well-known/mcp.json, and no downloadable OpenAPI spec at a guessable path (the bundled openapi.yaml is referenced in the docs but not fetchable, and api.frontegg.com is WAF-blocked) — discovery scored F (36/100).
- Frontegg actually ships agent tooling the discovery rubric doesn't reward: an official @frontegg/coding-agent-skills npm package that teaches coding assistants correct SDK patterns, plus an official frontegg/frontegg-mcp-server repo — yet there is no AGENTS.md in its public repos and the MCP server is not listed in Glama, Smithery, or PulseMCP, so agents browsing those registries won't find it.
- Error self-correction is a standout: a complete ER-code table with causes, a dedicated troubleshooting section giving explicit resolution steps (e.g. 401-on-refresh → blocked third-party cookies → switch to a custom domain), and 429 back-off guidance — an agent can recover from common failures without guessing.
- Capability boundaries are unusually well documented: per-endpoint rate limits broken out by plan tier (Launch/Scale/Enterprise) and by IP vs VendorId, so an agent can anticipate throttling. Minor blemish: internal test/lint demo pages (e.g. 'Title In Title Case Should Be Warning Only') and Redocly scaffold boilerplate leaked into the published docs and llms.txt.
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Add a robots.txt on developers.frontegg.com (it currently 404s) that explicitly allows GPTBot, ClaudeBot, Google-Extended, and CCBot and points to a sitemap — a fast, directly recoverable discovery win.
- 02Fix sitemap.xml: it returns 200 but 0 bytes. Generate a real sitemap enumerating all doc pages (and their .md variants) so crawlers and agents can discover the full surface.
- 03Publish a downloadable OpenAPI spec at a stable, discoverable URL (e.g. developers.frontegg.com/ciam/api/openapi.yaml or .json) and link it from llms.txt — today the bundled spec powers the reference docs but cannot be fetched, blocking agents that want the machine-readable contract.
- 04Add an llms-full.txt full-text bundle — the per-page .md content already exists, so concatenating it into a single llms-full.txt is low-effort and gives agents one comprehension payload.
- 05Add an AGENTS.md to the primary public repos (frontegg-mcp-server, SDKs) and submit the official frontegg-mcp-server to Glama/Smithery/PulseMCP — the tooling already exists; making it discoverable closes two failed checks at once.
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.
Frontegg thoroughly documents its authentication methods (API key, OAuth2/OIDC, JWT, M2M client-credentials, SAML SSO), a machine-parseable JSON error format backed by a full ER-code reference table, and exceptionally granular per-endpoint rate limits with explicit 429 back-off guidance. Pagination and idempotency support are not surfaced in the scanned pages.