CloudRail is Poor to agents.
Discry independently scored how well an AI agent can discover and understand the CloudRail 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 · 12/100Comprehension
55% of score · 66/100What we found
- An agent trying to find CloudRail's API would likely fail at discovery: cloudrail.com now redirects to Belden (post-acquisition), there is no robots.txt, llms.txt, sitemap, or MCP-registry listing, and the real reference lives on an undiscoverable subdomain (developer.cloudrail.com).
- An agent that follows the linked Device Management docs to azure.cloudrail.com hits an EXPIRED TLS certificate — a hard failure that blocks any automated HTTPS request outright.
- Positive: once located, the developer.cloudrail.com reference is genuinely usable — task-oriented endpoint descriptions, ~86 copy-pasteable cURL examples with realistic values (real box IDs, MAC addresses), and a documented multi-step 'Device Creation Workflow' that chains credentials → discovery → devices with async/skip caveats.
- There is no machine-readable contract an agent can ingest: the API points to a Postman collection as its 'source of truth' rather than a public OpenAPI/Swagger spec, and api.cloudrail.com/openapi.json returns 403.
- Error handling is a blind spot — the response envelope is described but there is no error-code table or recovery guidance, and no rate limits, pagination, or idempotency; an agent would discover failure modes only by hitting them.
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Renew the expired TLS certificate on azure.cloudrail.com immediately — it is a hard blocker that fails any agent (or human) HTTPS request to the Device Management docs and app.
- 02Make the API discoverable: add robots.txt, llms.txt, and sitemap.xml on developer.cloudrail.com, and cross-link the IoT API from the (Belden) marketing site so agents can find it after the acquisition redirect.
- 03Export the Postman collection to a public OpenAPI 3.x spec at a stable URL (e.g. developer.cloudrail.com/openapi.json) to give agents an ingestible, machine-readable contract.
- 04Add an error reference: document HTTP status codes, the error envelope schema, and concrete recovery steps (what to do on 401/403/404), plus rate limits.
- 05Document capability boundaries and provide examples in more than cURL (add at least one JS/Python/SDK snippet per endpoint).
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.
Authentication is a single non-expiring API key sent in an x-api-key header. Responses are JSON wrapped in a `data` envelope with a status code and success flag; the error envelope is described but no error-code table or recovery guidance exists. No rate limits, pagination, or idempotency are documented. The API self-identifies as version 0.1 beta and names its Postman collection (not an OpenAPI spec) as the source of truth.