Anam is Good to agents.
Discry independently scored how well an AI agent can discover and understand the Anam 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 · 79/100Comprehension
55% of score · 96/100What we found
- An agent could bootstrap Anam almost entirely from machine-readable assets: a well-structured llms.txt indexes every endpoint with task-oriented descriptions and links to per-page .md files, and a full 218KB OpenAPI (swagger.json) is publicly reachable and referenced from every reference page.
- Comprehension is near-perfect (96/A): every endpoint page leads with purpose + method/URL, code examples use real UUIDs across TypeScript, JavaScript, Python and bash, field naming is consistently camelCase, and multiple end-to-end guides (quickstart, full-app, custom-LLM, LiveKit, tool-calling) show how to chain operations.
- robots.txt is explicitly agent-friendly — it uses a Content-Signal header (ai-train=yes, search=yes, ai-input=yes) and allows all crawlers, so an AI bot indexing the docs is welcomed rather than blocked.
- The single largest discovery gap is the absence of an AGENTS.md in the primary SDK repos (javascript-sdk, python-sdk) — a coding agent working in Anam's own repos gets no dedicated instructions file, and the official MCP server is not surfaced in the major MCP registries (Glama/Smithery/PulseMCP).
- Error-recovery guidance is present but thin: the FAQ gives actionable fixes for the top connection errors (403 → check key, missing video → check element IDs, timeouts → add retry logic, expired token → refresh), but there is no consolidated error reference mapping each status/error code to a fix.
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Publish a machine-readable rate-limit contract: document request quotas and the response header names an agent should read (e.g. Retry-After / X-RateLimit-*) so autonomous callers can back off instead of failing blind — this is the biggest missing execution signal.
- 02Add an AGENTS.md to the primary open-source repos (javascript-sdk, python-sdk, anam-examples) pointing coding agents at the SDK entry points, session-token flow, and docs.anam.ai — a cheap discovery win that currently scores zero.
- 03List the official Anam MCP server in Glama, Smithery, and PulseMCP so agents discovering capabilities through MCP registries can find it; today a registry search for 'anam' returns only unrelated fuzzy matches.
- 04Add a dedicated Errors reference that enumerates the common status/error codes with an explicit recovery step for each (top 5-10 scenarios), rather than leaving recovery guidance scattered in the FAQ.
- 05Fix the stale internal links in the FAQ (e.g. /concepts/multilingual, /sdk-reference/interrupt-command, /concepts/custom-llms now resolve to /personas/... and /javascript-sdk/reference/... paths) so an agent following cross-references doesn't hit dead ends.
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 documentation is solid: a clearly-explained two-tier auth model (server-side API key exchanged for a 1-hour client session token), JSON error responses with HTTP status codes (400/401/500) described per endpoint, and page-based pagination (page/perPage query params returning a { data, meta } envelope with total/currentPage/lastPage/prev/next). Gaps: no explicit API rate limits and no idempotency-key support are documented, so an agent would only discover throttling behavior by hitting it.