Chroma is Agent-Ready to agents.
Discry independently scored how well an AI agent can discover and understand the Chroma 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 · 100/100Comprehension
55% of score · 96/100What we found
- An agent looking for Chroma would find it instantly and completely: robots.txt explicitly opts in to AI training and input, a well-structured API-focused llms.txt indexes every doc page, a valid .well-known/mcp.json points to a live MCP endpoint, and the official Chroma MCP server is listed on both PulseMCP and Glama — a perfect discovery sweep.
- Every REST reference page ships as clean markdown with an embedded, complete OpenAPI 3.1 fragment (real spec live at api.trychroma.com/openapi.json), including multi-language x-codeSamples in Python, TypeScript, and Rust — an agent can read the exact request/response schema and copy working code without JS rendering.
- Endpoint descriptions are task-oriented ('Queries a collection using dense vector search with metadata and full-text search filtering') rather than bare interface notes, and the getting-started guide even hands agents a ready-made install prompt for Claude Code / Cursor / Codex.
- Capability boundaries are exceptionally well documented: a full quotas-and-limits table (max dimensions, records per collection, concurrent reads/writes, results returned) plus a troubleshooting page — an agent learns limits from docs rather than by failing against them.
- The one gap is REST-level error recovery: HTTP 401/404/500 responses are documented with a JSON shape but no per-error 'what to do next' guidance, and there is no rate-limit retry/backoff instruction — so an agent hitting a 401 or a concurrency ceiling must infer the fix.
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Add per-status error-recovery guidance to the REST reference (e.g. '401: verify the x-chroma-token header and that the key matches the target tenant'; '404: confirm the collection UUID/CRN and database exist') so agents can self-correct instead of guessing.
- 02Document behavior at the concurrency and quota ceilings — what status/error surfaces when the 10-concurrent-reads or 300-results-per-query limit is exceeded, and the recommended backoff or batching pattern.
- 03State idempotency semantics explicitly for write endpoints (add/upsert/create-collection), clarifying which operations are safe to retry and whether get_or_create is the idempotent path, so agents can safely re-issue failed writes.
- 04Fix the /api-reference/openapi.json endpoint, which currently serves the Mintlify 'Plant Store' placeholder spec; point it at the real chroma-frontend spec so agents probing the conventional path don't ingest a decoy.
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.
Chroma documents a machine-parseable JSON error format ({error, message}) with standard HTTP status codes (401/404/500) on every endpoint. Auth is a single API-key scheme (x-chroma-token). Cloud quotas and per-collection concurrency limits (10 concurrent reads/writes) are published rather than request-rate limits, and pagination is documented via limit/offset query parameters. Idempotency keys are not documented, though get_or_create semantics provide idempotent-like collection creation.