crewai is Agent-Ready to agents.
Discry independently scored how well an AI agent can discover and understand the crewai 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 · 93/100Comprehension
55% of score · 87/100What we found
- An agent discovering CrewAI would land on a near-complete discovery surface: robots.txt actively invites AI crawlers (Content-Signal: ai-train=yes, ai-input=yes), and llms.txt, llms-full.txt, a valid .well-known/mcp.json, a sitemap, and a machine-readable OpenAPI 3.0.3 spec are all present — a rare full sweep.
- CrewAI is unusually agent-native at the source: the repo ships an AGENTS.md and the quickstart tells coding agents to install dedicated skills via `npx skills add crewaiinc/skills`, plus an official CrewAI Enterprise MCP server is listed on PulseMCP and Glama.
- Every doc page is retrievable as clean markdown (each .md URL even opens with a pointer back to llms.txt), so an agent never has to parse JS-rendered HTML to comprehend the API.
- The AMP REST API is tightly scoped and task-oriented — GET /inputs → POST /kickoff → GET /status/{kickoff_id} — with a documented end-to-end workflow and realistic multi-language examples (travel-planning and outreach crews with plausible values), making it easy for an agent to chain calls.
- The main gap an agent would hit is operational boundaries: the AMP API publishes error codes but no rate limits, quotas, or retry/backoff guidance, and naming mixes snake_case (kickoff_id) with camelCase (taskWebhookUrl), so an agent could guess a field's casing wrong.
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Document AMP API rate limits and quotas (limits, headers, and Retry-After behavior) so agents can back off correctly instead of discovering ceilings by failing.
- 02Add explicit error-recovery guidance for the top error codes — e.g. what to do on 401 (refresh/replace bearer token), 422 (resubmit with the fields named in missing_inputs), and 500 (retry with backoff) — rather than just listing code meanings.
- 03Standardize field-name casing across the OpenAPI spec (kickoff_id is snake_case while taskWebhookUrl/stepWebhookUrl/crewWebhookUrl are camelCase) so agents can predict field names reliably.
- 04Trim or split the llms.txt: at ~53KB it edges past the ~50KB/12K-token guideline for a single agent-consumable index — an API-scoped variant would keep it well within a comfortable context budget.
- 05Populate .well-known/mcp.json with explicit tool declarations (it currently points to a Mintlify-hosted docs MCP endpoint with auth info but no tool list), so agents can enumerate capabilities without a live handshake.
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.
The CrewAI AMP REST API documents a clean HTTP bearer auth model (org-level and user-scoped tokens) and a machine-parseable JSON error format with typed Error and ValidationError schemas — 422 responses even return a missing_inputs array telling an agent exactly which inputs to supply. Rate limits, pagination, and idempotency keys are not documented for the AMP API (the async kickoff/status model has no list endpoints; client-side max_rpm exists only in the open-source framework).