OVHcloud is Good to agents.
Discry independently scored how well an AI agent can discover and understand the OVHcloud 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 · 60/100Comprehension
55% of score · 91/100What we found
- An agent can discover OVHcloud's entire API surface without authentication: the public index at api.ovh.com/1.0/ enumerates ~70 top-level product schemas, each downloadable as machine-readable JSON or YAML across both v1 and v2 branches — a rare, high-value discovery signal.
- An agent reading the docs gets clean, LLM-optimized markdown for free: every guide page is served natively as text/markdown via a .md suffix with frontmatter and a lastUpdated date, explicitly labeled 'optimized for AI/LLMs'. No HTML-to-markdown lossiness.
- Documentation is strongly task-oriented and workflow-first: the domain-management guide chains a full lifecycle (order to tasks to contacts to eligibility rules to WHOIS to DNS to transfer) as linked .md guides, with copy-pasteable examples in 7 SDK languages and realistic-looking credentials.
- The biggest discovery gap is the absence of any llms.txt / llms-full.txt / .well-known/mcp.json — an agent has no single curated entrypoint, so it must crawl the 19 locale sitemaps or the API index to orient itself.
- OVHcloud is well-represented in the MCP ecosystem — it ships an official first-party MCP server (labs.ovhcloud.com and ovhcloud.com/public-cloud/mcp-server, remote MCP with OAuth2) and is listed on third-party registries (mcpmarket.com, Claude Code Marketplaces, GitHub) — but its only AGENTS.md (in ovh/ovhcloud-docs) targets docs-site contributors with Rspress/pnpm build commands, not agents consuming the API — a missed chance to guide coding agents.
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Publish an llms.txt at docs.ovhcloud.com (and api.ovh.com) that curates the highest-value entrypoints: the first-steps auth guide, the /1.0/ schema index, the SDK repos, and the per-product workflow guides. This is the single highest-impact discovery fix and would lift the Discovery grade.
- 02Add an API-consumer AGENTS.md (distinct from the docs-build one) covering request signing, the AK/AS/CK flow, endpoint discovery via /1.0/, rate-limit handling, and the official SDKs — so coding agents get correct context on first read.
- 03Attach explicit error-recovery guidance to error codes across the API (not just AI Endpoints troubleshooting): e.g. 'on 429, honor Retry-After and back off exponentially', 'on 401 Client::Unauthorized, re-run the signature with a fresh timestamp'. This would move errorRecoveryGuidance from partial to pass.
- 04Provide a concise, cross-product 'API overview' page (or a slimmed llms-full.txt) so an agent can grasp core capabilities in under ~5k tokens instead of paging through 70 product schemas — improving token efficiency.
- 05Publish a .well-known/mcp.json declaring the official OVHcloud MCP server and its tool set so MCP-capable agents can auto-discover it from the domain.
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.
Errors return machine-parseable JSON (e.g. {"class":"Client::Unauthorized","message":"..."}) with HTTP status codes. Request signing is fully documented (SHA1 of AS+CK+METHOD+QUERY+BODY+TSTAMP) plus a v2 OAuth2 branch. Rate limits are documented per service (e.g. Public Cloud: 60 req/min, OpenStack projects 20 req/s) with 429 responses. Pagination is supported on list endpoints. Idempotency keys are not surfaced in the documentation reviewed.