Attio is Good to agents.
Discry independently scored how well an AI agent can discover and understand the Attio 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 · 86/100Comprehension
55% of score · 91/100What we found
- An agent landing on the docs is well-served: the canonical docs (docs.attio.com) ship an auto-generated, 56KB sectioned llms.txt with per-page descriptions, a 652KB llms-full.txt, a real robots.txt signaling 'ai-train=yes', and every page mirrored as clean .md — a near-complete agent-readiness stack from the Mintlify platform.
- A valid public OpenAPI 3.1.0 spec (Attio API v2.0.0, 45 paths / 75 operations) is published at api.attio.com/openapi/api and linked from the docs, so an agent can ingest the full machine-readable contract in one fetch.
- Endpoint descriptions are genuinely task-oriented and self-correcting: 'Creates a new person, company or other record... If you would prefer to update records on conflicts, please use the Upsert record endpoint instead' — an agent is told both what the call does and how to recover from the common failure.
- The registry's stated base domain (developers.attio.com) is a thin Mintlify alias: a naive GET to /llms.txt or /robots.txt returns a 352KB HTML SPA shell unless the agent sends an Accept: text/plain header, and the rich files only live on docs.attio.com. An agent that doesn't follow the pointer or negotiate content type sees almost nothing.
- The AGENTS.md in the official attio/docs repo is the un-customized Mintlify boilerplate ('First-time setup: Customize this file...' with empty terminology and content-boundary sections), so a coding agent gets generic docs-tooling instructions rather than Attio-specific guidance.
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Serve the rich llms.txt, llms-full.txt, robots.txt, sitemap.xml and .well-known/mcp.json directly on developers.attio.com (the advertised developer domain) with correct text/plain and application/json content types — not just on docs.attio.com behind content negotiation — so an agent that starts at the registered docs URL succeeds without header tricks.
- 02Customize the attio/docs AGENTS.md with Attio-specific terminology (object/record/list/entry semantics), auth and scope conventions, and the OpenAPI spec location, turning a partial boilerplate file into a real coding-agent on-ramp.
- 03Add a dedicated REST API error/status-code reference that catalogs the common failure codes (400, 401, 404, 409/conflict, 422, 429) with explicit recovery steps — extend the excellent rate-limit recovery pattern to the rest of the error surface so agents can self-correct beyond 429.
- 04Point .well-known/mcp.json at a stable production MCP endpoint instead of the current 'main-kill-isr.mintlify.me' preview URL, and include explicit tool declarations so agents can discover Attio's MCP capabilities reliably.
- 05Trim per-endpoint token cost: each endpoint .md embeds the entire ~117KB OpenAPI document, so reading one endpoint pulls the whole spec — scope the embedded OpenAPI to the single operation to make individual endpoint reads token-efficient.
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 well. Auth covers OAuth 2.0 (with a dedicated tutorial) and bearer API keys, with per-endpoint scopes. Errors are machine-parseable JSON (status_code, type, code, message). Rate limits are explicit (100 req/s read, 25 req/s write, plus score-based limits on list endpoints) with a Retry-After header. Both limit/offset and cursor pagination are documented. No idempotency-key header is documented, though upsert endpoints provide idempotent create-or-update by matching attribute. Claims are documentation-based and would require a live audit to verify.