Eden AI is Good to agents.
Discry independently scored how well an AI agent can discover and understand the Eden AI 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 · 81/100Comprehension
55% of score · 93/100What we found
- An agent discovering Eden AI lands in strong shape: robots.txt carries an explicit Content-Signal (ai-train=yes, ai-input=yes), a 20KB structured llms.txt indexes every endpoint with one-line task descriptions, a 435KB llms-full.txt provides the full corpus as markdown, a valid OpenAPI 3.1.0 spec is publicly reachable at /docs/api-reference/v3-openapi.json, and a valid /.well-known/mcp.json advertises a live hosted MCP server (edenai.mintlify.dev/mcp, auth: none).
- Every documentation page is available as clean markdown — each page has a .md twin and each HTML page opens by pointing agents to /docs/llms.txt — so an agent parsing the docs never has to fight JS-rendered layout to extract structure. Field naming is consistently snake_case throughout (job_id, file_id, total_tokens, provider_params).
- Error handling is genuinely agent-usable: the docs include an HTTP status table that tells an agent what to DO — 429 means back off and retry or switch to a model with more headroom, 400 returns a typed validation error, 451 documents EU region gating with a programmatic code: region_not_allowed — and built-in fallbacks let the agent list backup models instead of writing retry logic.
- The remaining discovery gaps are agent-native surfaces beyond the web: there is no AGENTS.md in the edenai GitHub org (including the official edenai-skill Claude Code skill repo), and Eden AI's live MCP server is not listed in the Glama/Smithery/PulseMCP registries — so an agent browsing MCP catalogs rather than crawling the docs would not find it.
- Endpoint-reference request examples are auto-generated OpenAPI placeholders ("<string>", 123) even though the hand-written quickstart and guides use realistic values (model 'openai/gpt-4', Bearer YOUR_API_KEY, fallbacks). An agent copying a reference example gets the correct shape but must invent plausible model names and payloads itself.
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01List the already-running Mintlify-hosted MCP server (declared in /.well-known/mcp.json) in the Glama, Smithery, and PulseMCP registries — the endpoint exists, so registry presence is the one missing discovery hop for agents that find tools via MCP catalogs. Fastest win.
- 02Add an AGENTS.md to the primary edenai GitHub repos (edenai-apis, edenai-skill, SDKs) with orientation for coding agents — setup, auth, and the OpenAI-compatible base URL. A rising standard that is currently absent and cheaply closed (highest-weight remaining discovery gap).
- 03Replace auto-generated placeholder values ("<string>", 123) in the OpenAPI endpoint-reference examples with realistic, copy-pasteable payloads (a real model id like 'openai/gpt-4o', a plausible prompt) so an agent can run a reference example without inventing values.
- 04Fix the 500 errors returned by some individual /api-reference/*.md and /v3/llms/*.md pages so reliable per-page clean markdown is fetchable directly, not only via the aggregated llms-full.txt.
- 05Document the Retry-After response header for 429s and add request-level idempotency keys to strengthen execution-layer guarantees for autonomous agent retries.
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 well documented for an agent. Auth is a Bearer-token pattern (plus free sandbox tokens and BYOK); errors return machine-parseable OpenAI-compatible JSON (e.g. {"error": {...}}) with an HTTP status table pairing codes to recovery actions (400 typed validation error, 402 insufficient credits, 429 back-off, 451 EU region gate with code: region_not_allowed). Rate limits (7 req/sec default, upgradable to 15), automatic provider fallbacks, async-job polling/webhooks with idempotency notes, and offset-based pagination are all described. Idempotency is documented at the webhook-delivery level; there is no request-level idempotency-key header. These are documented claims only; live testing requires a full Discry Audit.