Copper is Poor to agents.

What we found

• —An agent looking for Copper's API would struggle to discover it programmatically: there is no robots.txt, no llms.txt/llms-full.txt, an empty sitemap.xml, and no .well-known/mcp.json — the only machine-readable surface is a publicly downloadable Postman collection (no native OpenAPI/Swagger spec).
• —Once an agent reaches the docs, comprehension is solid: the MkDocs site has a clean, resource-organized hierarchy (people, leads, companies, opportunities, projects, tasks, activities, webhooks), endpoint pages lead with the HTTP method and URL, and headings nest logically — agents can parse structure reliably.
• —Code examples use realistic values (real-looking IDs like 27140448, plausible emails, addresses, phone numbers) and are copy-pasteable, but they are curl-only — an agent generating client code in Python or JS gets no language-native sample.
• —Capability boundaries are unusually well-covered for a CRM API: explicit rate limits, a 100k-record search cap, a documented 'no file uploads' limitation with a workaround, and team-permission caveats all appear — an agent can anticipate limits rather than discovering them by failing.
• —Error recovery is the weak point of an otherwise usable reference: the Responses page lists bare HTTP codes (400, 422, 429, 500) with only their generic meanings — no guidance on which parameter failed a 422 or how to back off from a 429 — so a self-correcting agent has little to act on.

What to change

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

1. 01Publish an llms.txt at the domain root that names the API, summarizes the core CRM resources (people, leads, companies, opportunities, tasks, activities), and links to the authentication, pagination, and key endpoint pages — the single highest-impact discovery fix.
2. 02Add a robots.txt that explicitly allows AI crawlers (GPTBot, ClaudeBot, Google-Extended, CCBot) and populate the currently-empty sitemap.xml with the full set of documentation URLs so agents and crawlers can enumerate the docs.
3. 03Ship a native OpenAPI 3.x spec (the existing Postman collection can be converted as a starting point) and link it prominently — this turns the API from 'human-readable only' into something an agent can ingest as a tool schema.
4. 04Document the error-response JSON body shape and add per-error recovery guidance: show the actual error payload, explain what triggers a 422 and which field to fix, and tell agents to honor the rate-limit window on a 429.
5. 05Expand examples beyond curl to at least one language-native SDK sample (Python/JS) and add 2–3 end-to-end workflow guides (e.g., 'lead intake → convert to person + opportunity → log activity') so agents can chain operations for real tasks.