DuploCloud is Good to agents.

What we found

• —An agent evaluating DuploCloud finds a strong discovery surface for an infrastructure platform: robots.txt explicitly signals ai-train=yes and ai-input=yes with no bot blocks, and both llms.txt (a structured, described index) and a 523KB llms-full.txt are served, so an agent can ingest the documentation corpus without scraping HTML — though the llms.txt is a ~130KB site-wide dump of all 241 pages rather than a right-sized agent map.
• —Every documentation page is available as clean markdown via a .md suffix (GitBook), meaning an agent gets loss-free, well-structured content (H1 to H2 to H3 nesting) rather than JS-rendered pages that parse poorly.
• —An agent looking to programmatically drive DuploCloud finds a genuine machine surface via the duploctl CLI/Python SDK, whose reference documents task-oriented operations ('Create a new tenant', 'Retrieve DNS configuration for a tenant') with realistic examples and per-endpoint Pydantic (JSON Schema) request models — but there is no single consolidated, downloadable OpenAPI/Swagger spec at standard paths.
• —The API is agent-discoverable through the ecosystem: a DuploCloud MCP Server is listed on the Glama registry (wrapping duploctl commands as MCP tools), so an MCP-capable agent can find and adopt it without custom integration.
• —The primary weakness for autonomous agents is operational boundary documentation: there is no systematic rate-limit, pagination, or idempotency documentation, and error recovery is scattered across per-method 'Raises' notes and FAQ how-tos rather than a consolidated error-code-to-fix reference, so an agent would learn several failure modes only by failing.

What to change

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

1. 01Publish a single consolidated OpenAPI/Swagger spec for the DuploCloud REST API at a standard, publicly linkable path (e.g. docs.duplocloud.com/openapi.json). The duploctl SDK already carries per-resource Pydantic schemas; exporting them as one OpenAPI document would move the openApiSpec check from partial to pass and give agents a machine-readable contract for the whole API.
2. 02Add an AGENTS.md to the primary public repos (duploctl and/or docs). A real CLAUDE.md exists in duploctl, but a dedicated AGENTS.md with build/test/usage context is the rising cross-tool standard and would upgrade the agentsMd check.
3. 03Create a dedicated API limits page documenting rate limits (with response header names), pagination approach for list operations, and any idempotency guarantees. This is the single biggest comprehension gap — agents currently have no way to plan retry/backoff or paging behavior from the docs.
4. 04Consolidate error handling into an error-code-to-recovery reference (e.g. 'expired token -> regenerate via Profile page', '429 -> back off'). Recovery guidance exists today only as scattered FAQ how-tos and per-method DuploError notes; a single actionable table would let agents self-correct.
5. 05Right-size llms.txt: the current file is a ~130KB site-wide index of all 241 pages, which pushes an agent to wade through everything to find core capabilities. Trim it to a curated, API/SDK-focused map (<50KB) leading with authentication and the duploctl resource commands, and leave the exhaustive corpus to llms-full.txt. Optionally also serve a .well-known/mcp.json declaring the DuploCloud MCP tools so MCP-capable agents can discover the server directly from the domain.