Nimble is Agent-Ready to agents.
Discry independently scored how well an AI agent can discover and understand the Nimble 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 · 90/100Comprehension
55% of score · 100/100What we found
- An agent discovering Nimble lands cleanly: the Mintlify-hosted docs expose a valid llms.txt index (21.5KB, sectioned, 145 described links), a 1.5MB llms-full.txt corpus, a downloadable OpenAPI 3.1 spec at /api-reference/openapi.json (27 paths, ~340 inline examples), a sitemap, and a robots.txt that explicitly signals ai-train=yes, ai-input=yes — nothing an agent needs is gated or blocked.
- Comprehension is effectively perfect: every endpoint page leads with method, path, and a task-oriented summary, and code examples ship in Python/Node/cURL with realistic values (asin B0DLKFK6LR, keyword 'iphone 17', zip 90210) rather than 'string'/'123' placeholders — an agent can copy-paste and run without guessing.
- Nimble documents its capability boundaries explicitly, which is rare: a published blocked-domains list (PayPal, Stripe, Spotify, Netflix-adjacent, etc.), per-driver capability tables (vx6-vx10, render vs stealth), and stated max_results/limit ceilings mean an agent learns what it cannot do from the docs instead of by failing against the API.
- Error recovery is spelled out as actions, not just codes: docs instruct 'implement exponential backoff on 429', 'use the retry_after value to schedule the next request', and expose a --debug mode for inspecting the full request/response — the self-correction guidance that separates agent-usable docs from human-only reference.
- Nimble is unusually invested in agent onboarding: an official Nimble MCP Server is listed on Smithery, a /.well-known/mcp.json points to a live MCP endpoint, and there are first-class connector guides for Claude, OpenAI, LangChain, Vercel AI SDK, and Google ADK — the main gap is the absence of an AGENTS.md (a CLAUDE.md exists in the agent-skills repo, but not the AGENTS.md standard).
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Add an AGENTS.md to the primary public repos (Nimbleway/agent-skills, cookbook, nimble-cli). A strong CLAUDE.md already exists in agent-skills, so this is largely a rename/duplication to the emerging cross-tool standard — the single cheapest way to close the one soft spot in an otherwise A-grade discovery profile.
- 02Enrich /.well-known/mcp.json with inline tool declarations (name, description, input schema per tool) and auth guidance, rather than only pointing to the hosted MCP endpoint. An agent reading the well-known file today learns the server exists but must connect to enumerate capabilities.
- 03Publish a consolidated 'Errors & Recovery' reference page that maps each documented status (400/401/402/422/429/500) to a concrete fix ('402 - top up budget or upgrade trial', '422 - which parameter failed validation'), consolidating the recovery guidance currently spread across the introduction, rate-limit, and integration pages.
- 04Add an explicit note on the async/task model clarifying that result retrieval is task-based (task_id then /results) and not paginated, so agents do not attempt cursor/offset pagination — and document whether repeated identical requests are idempotent, since neither is currently stated.
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 documented thoroughly for a scan-tier assessment. Auth is a single Bearer-token scheme (BearerAuth) declared in the OpenAPI security block and the introduction page. Errors return a machine-parseable JSON envelope ({error:{code,message,retry_after}}) with per-status schemas (Error400/402/429/500) referenced across all endpoints. Rate limits are stated numerically (83 QPS / 5,000 QPM per key) with named headers (X-RateLimit-Limit/Remaining/Reset) and a documented Retry-After / retry_after recovery path. Long-running work uses an async task pattern (task_id then /v1/tasks/{id} then /results) rather than result-set pagination, so cursor/offset pagination is not applicable and idempotency keys are not documented. These are documentation claims only; live verification requires a full Discry Audit.