Cognition is Good to agents.
Discry independently scored how well an AI agent can discover and understand the Cognition 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 · 91/100What we found
- An agent looking to integrate Devin would land cleanly: docs.devin.ai publishes a structured llms.txt, a full llms-full.txt, and multiple public OpenAPI 3.1.0 specs (v3/v2/v1) linked directly from the index, so the entire surface is machine-discoverable without scraping HTML.
- Comprehension is genuinely strong (91/A): the Common Flows page gives end-to-end, chained multi-step workflows (create session -> poll -> download attachments -> schedule) with runnable Python plus curl, and the auth page documents 401/403/404 recovery steps explicitly — agent-usable, not human-only.
- A .well-known/mcp.json exists with a valid HTTP transport declaration and auth field, but it points at a Mintlify preview host (cognitionai.main-kill-isr.mintlify.me) rather than a production endpoint, so an agent trusting it verbatim could hit an unstable URL.
- No AGENTS.md is discoverable in a primary Cognition/Devin repo (the product is closed-source SaaS and githubOrg is null); Devin consumes the AGENTS.md standard but does not publish one, so a coding agent gets no repo-level conventions file.
- The llms.txt is API-focused (291 of 525 links are api-reference) with descriptions, but at ~90KB / ~22K tokens it exceeds the right-sized-for-agents bar, and there is no single consolidated capability-boundaries page, so understanding the full surface costs more tokens than an ideal overview would.
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Point .well-known/mcp.json at the production MCP endpoint (e.g. under docs.devin.ai or api.devin.ai) instead of the Mintlify preview host, so agents can trust the advertised server URL.
- 02Add an API-only llms.txt (or trim the current one) that fits under ~12K tokens and links just the core session/knowledge/playbook/schedule endpoints plus the OpenAPI specs, giving agents a right-sized entry point.
- 03Publish a single 'Limits & Constraints' page consolidating rate limits, ACU/usage quotas, and known limitations, so an agent learns boundaries from docs rather than by hitting 429s.
- 04Publish an AGENTS.md in a public integration/example repo (e.g. the Devin Handoff plugin or an examples repo) so coding agents pulling the repo get explicit build/test/convention context.
- 05Add per-error recovery guidance directly on individual endpoint pages (not only on the auth and common-flows pages) so an agent self-corrects without needing to cross-reference.
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: standard HTTP status codes with per-code troubleshooting, a Bearer-token principal/token auth model with RBAC service users, cursor-based pagination on a dedicated concepts page, and rate-limit plus idempotency references present in the OpenAPI 3.1.0 spec. These are documentation claims; live behavior would require a full Discry Audit.