adafruit.com is Poor to agents.

What we found

• —An agent can learn the entire API from a single ~1,000-token page — all four endpoints, full field schemas, and usage rules fit in one read, which is exceptional token efficiency.
• —There is no machine-readable surface at all: no OpenAPI spec, no llms.txt, no MCP presence. An agent must parse a human-oriented HTML page to use an API that would take an afternoon to spec formally.
• —robots.txt disallows /api/ for ALL crawlers — a crawler-based agent is barred from the very endpoints the documentation invites it to call, so the API is invisible to crawl-driven discovery.
• —Error behavior is completely undocumented: an agent that exceeds the 5 req/min limit or requests an unknown product ID discovers what happens only by failing, with no recovery guidance.
• —The docs contain real, copy-pasteable example URLs (product 998 = Raspberry Pi Model B, category 118 = Lasers) but zero code samples and zero example JSON responses.

What to change

Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.

1. 01Publish an OpenAPI spec for the four endpoints (/api/products, /api/categories, /api/product/[pid], /api/category/[cid]) — with a schema this small it is a quick win and the single largest discovery-score improvement available.
2. 02Add an llms.txt at www.adafruit.com/llms.txt that describes the Products API and links to /products_api and the endpoint URLs.
3. 03Add example JSON responses and a curl sample for each endpoint using the realistic IDs already cited in the docs.
4. 04Document error responses: the status code and body returned for unknown IDs and for exceeding the 5 req/min rate limit, plus any rate-limit headers agents should read.
5. 05Normalize the field-name prefixes (product_id vs products_description, sub_categories vs subcategories) or explicitly document the inconsistency so agents don't mis-key responses.