Agave is Poor to agents.
Discry independently scored how well an AI agent can discover and understand the Agave 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 · 21/100Comprehension
55% of score · 78/100What we found
- An agent trying to discover Agave gets almost no agent-native signals: no robots.txt, no llms.txt, no .well-known/mcp.json, and no MCP-registry listing. It would have to find Agave through general web search, and the docs also live on a different domain (docs.agaveapi.com) than the brand domain (useagave.com), adding a discovery hop.
- Once at the docs, comprehension material is excellent: the Agave Link quickstart is a clean 5-step end-to-end workflow (get credentials, generate link token, serve Link, exchange for account token, read/write data) that an agent can chain directly.
- Examples are genuinely realistic and copy-pasteable, using proper UUIDs, real-looking addresses, plausible amounts, and full JSON responses shown across multiple source systems (Procore, Autodesk Build, Fieldwire, PlanGrid) rather than 'string'/'123' placeholders.
- The endpoint-level API reference is a JavaScript-rendered SPA ('Loading API Reference...') with no standalone OpenAPI/Swagger file at any standard path, so an agent scraping /reference gets an empty shell instead of machine-readable endpoint definitions; only a downloadable Postman collection (2024-09-10) partially fills the gap.
- Capability boundaries are strong: per-source-system rate limits, concurrency caps, async limits, prohibited fields, and troubleshooting FAQs let an agent anticipate constraints rather than discover them by failing.
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Publish llms.txt (and llms-full.txt) at docs.agaveapi.com covering the Agave Link auth flow and the unified endpoints — the single highest-ROI fix, currently a 0 on a table-stakes discovery signal.
- 02Expose the OpenAPI spec as a fetchable file (e.g. /openapi.json) linked from the reference page so agents can pull machine-readable endpoint definitions instead of a JS shell.
- 03Add a robots.txt that explicitly allows AI crawlers (GPTBot, ClaudeBot, Google-Extended, CCBot); today none exists, which reads as ambiguous or blocking.
- 04Ship and register an MCP server on Glama, Smithery, and PulseMCP so agents can discover and invoke Agave through MCP tooling.
- 05Add per-error recovery steps to the response-codes table (what to do on 400/401/409/429) by consolidating the existing source-system FAQ fixes into the core 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 unusually well documented for a scan-tier API: conventional HTTP status codes with standardized cross-source error normalization, detailed per-source-system rate limits plus Agave-level caps (150 req/min/linked account, concurrency limits) surfaced in response headers with exponential-backoff guidance, dedicated pagination and async-request pages, and idempotency referenced via the 409 conflict + idempotent-key behavior. Claims are documentation-only and would require live testing (audit mode) to verify.