Opsera is Poor to agents.

What we found

• —An agent that respects robots.txt would be blocked before reading anything: docs.opsera.io serves 'Disallow: /' for all user-agents plus a Content-Signal of 'ai-train=no, search=no, ai-input=no', so a well-behaved crawler never reaches the otherwise-usable API pages.
• —Once past the robots barrier, an agent finds genuinely task-oriented REST docs: endpoints lead with method, URL and a plain-language purpose ('Retrieves the live or completed execution status of a pipeline run'), backed by realistic JSON request/response samples with plausible IDs, emails and timestamps.
• —There is no machine-readable OpenAPI/Swagger spec anywhere: an agent must reconstruct the API surface by parsing prose tables spread across a dozen pages, and it will hit inconsistencies (mixed /api/v1 and /api/v2 versions, MongoDB-style snake_case fields like token_id and __v next to camelCase, and a typo endpoint '/api/v1/pipeline/summay').
• —Discovery signals for AI are unusually strong for a GitBook site: llms.txt, llms-full.txt, per-page .md variants, a sitemap, an 'Agent Instructions' block, and an official PulseMCP registry listing all exist — undercut only by the site-wide (32K-token) llms.txt that dumps every product page rather than foregrounding the API.
• —An agent hitting errors gets partial self-correction help: the User Management page shows a failing request and its fix (case-sensitive siteRole -> 400), and the MCP guide has a Troubleshooting section for 401/expired tokens/connectivity, but most individual endpoints list no per-error recovery steps.

What to change

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

1. 01Stop blocking AI agents in robots.txt: replace 'Disallow: /' and the 'ai-train=no, search=no, ai-input=no' Content-Signal with rules that allow GPTBot, ClaudeBot, Google-Extended and CCBot to reach the /api-platform-and-integration pages — this single change unblocks every downstream discovery and comprehension signal for compliant agents.
2. 02Publish a machine-readable OpenAPI 3.x spec at a stable path (e.g. https://docs.opsera.io/openapi.json) covering the v2 pipeline, task, user, group and tool endpoints — this is the highest-impact comprehension win and lets agents generate clients instead of scraping prose tables.
3. 03Trim llms.txt to an API-focused, right-sized index (<50KB): lead with the API Platform section and core endpoints rather than dumping onboarding guides and release notes back to 2021, so an agent can understand the API in under ~5K tokens.
4. 04Normalize naming and versioning: consolidate on /api/v2, use a single casing convention in documented response bodies, fix the '/api/v1/pipeline/summay' typo, and standardize the response envelope so an agent isn't guessing which shape a given endpoint returns.
5. 05Add explicit error-recovery guidance and rate-limit documentation per endpoint: publish the rate limits and their header names, and give each common error (400/401/403/404/429) an actionable 'what to do' line, extending the good siteRole-casing example to the rest of the surface.