anchore.io is Needs Work to agents.
Discry independently scored how well an AI agent can discover and understand the anchore.io 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 · 57/100Comprehension
55% of score · 84/100What we found
- The scanned domain anchore.io does not resolve to a served site (returns a Fastly 'unknown domain' error) — an agent that follows the anchore.io hostname literally hits a dead end. All real, agent-usable documentation and the API live at docs.anchore.com, which the agent must discover indirectly.
- An agent that reaches docs.anchore.com is well served on comprehension: docs are API-first, published as clean markdown, use consistent snake_case fields and ISO-8601 timestamps, and expose a comprehensive OpenAPI 3.0.1 spec with 411 richly-described operations and capability-oriented tags.
- A high-quality llms.txt is present at docs.anchore.com (title, description, and linked sections generated from 451 doc pages), giving an agent a concise <5K-token map of the whole platform — a strong discovery signal that offsets the missing robots.txt.
- Workflow documentation is genuinely agent-friendly: the Quickstarts section contains end-to-end guides (e.g. zero-day triage: check feeds → query by vulnerability ID → query by package → remediate) with realistic curl examples using real CVE/GHSA IDs, image digests, and plausible JSON responses.
- No AGENTS.md exists in Anchore's public repos (syft, grype, anchore-engine), no .well-known/mcp.json is served, and no genuine Anchore MCP server appears in the major registries — so an agent gets no purpose-built agent scaffolding beyond the docs and OpenAPI spec.
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Make anchore.io resolve to (or redirect to) served content — ideally 301 to anchore.com/docs.anchore.com. As-is, any agent handed the anchore.io hostname fails before it starts; a redirect is the single highest-impact fix.
- 02Serve a robots.txt on docs.anchore.com that explicitly allows AI crawlers (GPTBot, ClaudeBot, Google-Extended, CCBot). It currently 404s, so agents get no crawl signal at all — an easy discovery win.
- 03Publish an AGENTS.md in the syft/grype repos and consider a .well-known/mcp.json plus an official MCP server listing — Anchore's API-first, CI/CD-embedded model is a natural fit for agent tooling and would capture the three failed low-weight discovery checks.
- 04Add explicit rate-limit and error-recovery guidance (429/Retry-After behavior, and per-error 'what to do next' steps beyond the ApiErrorResponse detail string) so agents can self-correct instead of discovering limits by failing.
- 05Broaden endpoint code examples beyond curl to at least one SDK language (the API is Apache-2.0 and OpenAPI-specified, so client generation is cheap) to move realisticExamples 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.
Anchore Enterprise is explicitly API-first with a comprehensive public OpenAPI 3.0.1 spec (411 operations across 20 tagged domains). Three auth methods are documented (HTTP Basic, OAuth2 Bearer, and API keys via a special _api_key username). Errors return a machine-parseable ApiErrorResponse JSON schema with a detail field; pagination is page-based (page / returned_count / total_count) with cursor support on some endpoints. Rate limits (no 429 handling) and idempotency keys are not documented.