Exa is Agent-Ready to agents.
Discry independently scored how well an AI agent can discover and understand the Exa 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 · 91/100What we found
- An agent discovering Exa lands on an unusually complete signal set: robots.txt carries an explicit Content-Signal: ai-train=yes, ai-input=yes directive, a 27KB structured llms.txt and a 1.2MB llms-full.txt both resolve, and every documentation page is served as clean markdown (.md) — this is an AI-native API that documents itself for machines first.
- Endpoint reference pages embed full OpenAPI 3.1.0 specs (servers: https://api.exa.ai) with realistic examples (real arxiv URLs, plausible IDs) in bash, JavaScript, and Python — an agent can construct a valid /search or /answer call directly from the docs without guesswork.
- The Agent API guide is a genuine end-to-end workflow (install SDK → set key → create run → poll for completion → return structured JSON → process rows → connect data sources → continue from a previous run), so an agent chaining operations has a documented path rather than isolated endpoints.
- Exa's official MCP server is listed across Smithery, Glama, and PulseMCP, and a .well-known/mcp.json points to a live hosted MCP endpoint — an agent can adopt Exa via MCP without writing HTTP code.
- The main friction is naming drift: the core Search/Contents API is camelCase (numResults, imageLinks) while some newer surfaces use snake_case duplicates (image_links, source_count, subpage_target), and error docs describe formats without giving agents explicit recovery steps (no Retry-After / backoff guidance on 429).
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Publish a single canonical, downloadable OpenAPI spec (e.g., https://exa.ai/docs/openapi.json) rather than only embedding it per reference page — standalone spec paths currently 404, forcing an agent to scrape each page to assemble the full surface.
- 02Add explicit error-recovery guidance: for the top error scenarios (429, 401, 400 validation), tell agents what to DO (e.g., 'on 429 back off and retry with exponential delay', which parameter failed on a 400) instead of only documenting the error object shape.
- 03Resolve casing inconsistency across APIs — standardize on camelCase (or snake_case) end-to-end so an agent doesn't have to track that imageLinks vs image_links or source_count vs sourceCount refer to the same concept in different endpoints.
- 04Flesh out .well-known/mcp.json with inline tool declarations (names, descriptions, schemas) rather than only a pointer to the hosted server URL, so an agent can enumerate capabilities from the manifest alone.
- 05Replace the placeholder AGENTS.md in exa-py ('Read CLAUDE.md') with real coding-agent context, and add AGENTS.md to exa-mcp-server / exa-js so agents get first-class setup guidance in the primary repos.
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.
Auth is a single x-api-key header (plus an OpenAI-compatible route). Error responses are documented as a machine-parseable JSON object in the embedded OpenAPI schema. Per-endpoint rate limits are published as an explicit QPS table; the Agent API documents cursor/paginated list endpoints. No idempotency-key support is documented.