Okta is Good to agents.
Discry independently scored how well an AI agent can discover and understand the Okta 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 · 85/100What we found
- An agent can fully discover Okta's surface area: the complete Management API is published as a public OpenAPI spec (github.com/okta/okta-management-openapi-spec + the @okta/openapi npm package) and rendered in a modern reference portal, so capabilities are machine-readable rather than scraped.
- Endpoint documentation is task-oriented and agent-friendly — descriptions lead with what you accomplish ("Creates a new user with a password and recovery question and answer. The new user is able to sign in after activation") rather than just the HTTP signature, and examples use realistic, consistent values (isaac.brock@example.com) instead of placeholders.
- There is no llms.txt, llms-full.txt, or .well-known/mcp.json at developer.okta.com, so an agent gets no curated, token-efficient entry point — it must crawl the full portal or load the OpenAPI spec to orient itself.
- Okta ships an official, first-party MCP server (announced 2025-09-22) and is listed in MCP registries (Glama), so an agent already has a sanctioned execution path beyond the raw REST API — a strong signal most APIs lack.
- Capability boundaries are well-mapped: rate limits, 429/Retry-After behavior, compatibility and versioning rules, and deprecation policy are all documented, so an agent can reason about limits before hitting them rather than discovering them by failing.
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Publish an llms.txt at developer.okta.com that links the Core Okta API overview, authentication guide, OpenAPI reference, rate-limit, and error-code pages — the single highest-impact discovery fix, since the curated content already exists and only needs an agent-facing index.
- 02Add an llms-full.txt (or a markdown-content-negotiation path) covering core user/group/app/session flows so agents can ingest the essentials in <5K tokens instead of parsing the JS-rendered reference portal.
- 03Expand error documentation from descriptions to recovery steps for the top 10–15 error codes (e.g., which parameter failed on E0000001, exact remediation on 429) so agents can self-correct instead of just classifying the failure.
- 04Surface the official OpenAPI spec and MCP server directly from developer.okta.com discovery surfaces (a .well-known/mcp.json pointing at the MCP server, plus a prominent spec-download link) so agents find the sanctioned paths without a web search.
- 05Promote an AGENTS.md into the primary API/SDK repositories (it currently lives in okta/odyssey, the design-system repo) so coding agents working against the Okta SDKs get first-party guidance.
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 thoroughly. Errors return a consistent machine-parseable JSON envelope (errorCode, errorSummary, errorId, errorLink, errorCauses) cataloged across ~250 codes. Rate limits are documented per-bucket with explicit 429 behavior and per-user thresholds; cursor-based pagination uses Link headers. General idempotency-key support is not documented.