CloudBackend is Not Agent-Ready to agents.
Discry independently scored how well an AI agent can discover and understand the CloudBackend 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 · 19/100Comprehension
55% of score · 31/100What we found
- An agent trying to integrate CloudBackend hits a wall immediately: there is no REST API and no OpenAPI/Swagger spec. Access is only via compiled SDKs (C++/Java/Swift) that must be downloaded and installed on Ubuntu — an agent cannot call an HTTP endpoint to accomplish anything.
- The core documentation lives in a proprietary XML/JavaScript help viewer at docs.cloudbackend.com that renders as a chatbot UI and navigation soup when scraped — an agent gets almost no usable content, and the C++/Java reference is auto-generated Doxygen that is nearly all index links and method signatures with little task context.
- There is zero AI-discovery tooling: no llms.txt, no llms-full.txt, no .well-known/mcp.json, no AGENTS.md in the GitHub SDK repo, and no MCP registry listing. The only positive discovery signal is a permissive robots.txt that does not block AI crawlers.
- Positive: the SDK does ship real, multi-language example code plus per-language tutorials (Web UI, C++, Java, Swift) and clearly-named domain concepts (Tenant, Group, Role, Container, Object, ACL) — the raw material for good docs exists, it is just locked behind an unparseable viewer and stale tooling.
- The GitHub SDK repo (CloudBackend-AB/CloudBackendSDK) has only 3 stars and was last updated March 2024, signaling low momentum — an agent evaluating this API would find little community footprint or recent maintenance.
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 the root of cloudbackend.com that summarizes the platform, links to the SDK tutorials and concept pages, and states plainly that access is SDK-based (no REST API) — this is the single fastest win and would immediately give agents an entry point.
- 02Expose the documentation as clean, static markdown (or server content negotiation for text/markdown) instead of the XML/JS help viewer; the current viewer returns a chatbot shell when fetched, so no agent can read the docs at all.
- 03Add an AGENTS.md to the CloudBackendSDK GitHub repo covering install steps, the test-account credentials, and a minimal 'store your first object' walkthrough so coding agents can bootstrap without the marketing site.
- 04Document capability boundaries and error handling explicitly — rate limits, quotas, async error/callback semantics, and recovery steps — since an SDK's exceptions and callbacks are invisible to an agent reading the docs.
- 05If a REST/HTTP surface exists behind the SDKs, publish an OpenAPI spec; if it does not, add a prominent 'no REST API — SDK only' statement so agents don't waste cycles hunting for endpoints.
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.
CloudBackend is a Backend-as-a-Service (the 'Singularity' dbPaaS) accessed through compiled SDKs (C++, Java, Android, Swift, Objective-C) and a JavaScript/HTML web SDK — not a public REST API. Authentication is a tenant-scoped username/password login (public GitHub test accounts are provided). The SDK exposes both a synchronous and asynchronous API, but error formats, rate limits, pagination, and idempotency are not documented in any agent-consumable form.