AdButler is Good to agents.
Discry independently scored how well an AI agent can discover and understand the AdButler 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 · 71/100Comprehension
55% of score · 96/100What we found
- An agent discovering AdButler lands on an unusually complete machine-readable stack: a valid OpenAPI 3.0.0 spec (653 operations across 347 paths) at /openapi.json, a 133KB llms-full.txt that renders the entire API as clean markdown, and a structured product-level llms.txt — it can understand the whole surface without ever rendering an HTML page.
- AdButler ships an official MCP server (@adbutler/mcp-server, 600+ tools, hosted + npm) AND a dedicated 'skills' repo of nine end-to-end agent workflows (campaign launch, retail media, VAST, programmatic). This is among the most agent-forward API publishers scanned — an agent can drive the platform conversationally out of the box.
- Comprehension is near-perfect (96/A): every one of the 653 operations has a task-oriented summary ('Create a Catalog Ad Item'), schema examples use realistic values (real dates, real-looking IDs like 27419, plausible URLs), naming is consistently snake_case, and rate-limit/version boundaries are explicit.
- Discovery is held back (71/C) by missing low-effort signals: no AGENTS.md in any of the 11 public repos and no /.well-known/mcp.json — gaps that are surprising given how much heavier agent infrastructure already exists.
- The llms.txt is excellent but product/company-focused rather than API-focused, and the sitemap.xml lists only marketing/solution pages — so an agent relying on those two signals alone would not be routed to the actual API reference (it must find /openapi.json or /llms-full.txt directly).
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 SDK repos and the mcp-server/skills repos (worth 3 weight points, currently a full fail). Given the skills repo already exists, a short AGENTS.md pointing coding agents at it is a near-zero-effort discovery win.
- 02Publish /.well-known/mcp.json declaring the existing hosted MCP server endpoint and auth — the MCP server is already built, so exposing it via the well-known path closes a fail with minimal work.
- 03Make the llms.txt API-aware: add a section linking directly to /llms-full.txt, /openapi.json, and the /docs/api reference so the (otherwise product-focused) llms.txt routes agents into the technical docs. This lifts llms.txt quality from partial toward pass.
- 04Add the API reference and developer-guide URLs (/docs/api/, /developers/api-guides.html, /llms-full.txt) to sitemap.xml, which currently only lists marketing pages — improves doc crawlability for agents using sitemap-based discovery.
- 05Expand error documentation beyond the 429 case with explicit recovery steps for the top parameter/auth/not-found errors (e.g., what request_parameter_error returns and how to correct it), moving error-recovery guidance from partial to pass.
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.
Strong execution documentation. All requests use a secret API key via Basic Auth, with separate test-mode keys (no ad-serving cost) and live-mode keys. Errors return standard JSON semantically mapped to HTTP codes, backed by reusable error response schemas (resource_does_not_exist, request_parameter_error). Rate limits are explicitly tabled (600 req/min general, 60 req/min reporting, per account) with documented 429 behaviour. Pagination is offset-based via list_limit/list_offset. No idempotency-key mechanism is documented.