apideck.com is Agent-Ready to agents.
Discry independently scored how well an AI agent can discover and understand the apideck.com 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 · 95/100Comprehension
55% of score · 100/100What we found
- An agent arriving cold would be fully oriented in seconds: a curated llms.txt with per-page token budgets, an enumerated llms-full.txt index of every operation, native markdown for every page (via .md or Accept: text/markdown), and a dedicated 'Building with LLMs' page pointing to an MCP server, an agentic CLI, and installable API skills. This is documentation engineered for agents, not retrofitted for them.
- The error documentation is a model for agent self-correction: beyond the HTTP status table, ~20 named error types each carry an explicit recovery instruction (e.g. 401 → 'handle the error and let the user reconnect the integration', ConnectorNotFoundError → 'verify your service_id is spelled correctly and enabled'), and the JSON error body proxies downstream connector errors so an agent can diagnose the true failure.
- Discovery is nearly perfect (95/100) — the only miss is the absence of a .well-known/mcp.json, which is largely moot given Apideck already ships a first-party MCP server (229 tools) listed on the Glama registry and a public OpenAPI 3.1 spec set on GitHub.
- Comprehension scored a clean 100/100: task-framed guides for real end-to-end jobs (accounts-payable automation, AR automation, employee sync), realistic copy-pasteable examples (real company names, addresses, ISO currency/VAT values), rigorously consistent snake_case naming, and a unified rate-limit contract that normalizes every downstream connector.
- Robots policy uses the emerging Content-Signal standard (search=yes, ai-input=yes, ai-train=no) with a blanket Allow — agents are explicitly welcomed to read and act on the docs while training is opted out, so nothing blocks live agent consumption.
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 manifest that declares the existing Apideck MCP server and its auth model — it is the single remaining discovery gap and would let MCP-aware agents auto-discover the server without going through the docs.
- 02Document idempotency support explicitly: state whether write operations (e.g. POST /accounting/bills, POST /crm/companies) accept an idempotency key, so agents retrying after a timeout can avoid creating duplicate records.
- 03Serve the /errors reference as markdown too (the .md variant currently 404s while the HTML page resolves) so agents pulling docs via the .md convention get the full error-recovery catalog they need most.
- 04Consider claiming/listing the MCP server on Smithery and PulseMCP in addition to Glama to widen registry-based discovery across the agent tooling ecosystem.
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: Bearer API-key auth plus Vault-managed OAuth2 for downstream connectors, a machine-parseable JSON error model (type_name, message, downstream_errors passthrough, and a ref link back to the error doc), unified rate-limit headers (x-downstream-ratelimit-*) with Retry-After mapping and automatic SDK retry, and cursor-based pagination. Idempotency keys are not documented.