Cube Dev is Good to agents.
Discry independently scored how well an AI agent can discover and understand the Cube Dev 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 · 71/100Comprehension
55% of score · 87/100What we found
- An agent integrating Cube would find first-class machine-readable specs — five public OpenAPI documents (openapi.json, core-data.yaml, api.yaml, chat.yaml, scim.yaml) plus an openspec.yml in the repo — a strong, discoverable contract that most scanned APIs lack.
- An agent looking for Cube's MCP would succeed immediately: an official cubedevinc MCP server is listed on both PulseMCP and Glama, and the docs cover a hosted OAuth MCP endpoint and agent-to-agent Chat API recipes — Cube is explicitly building for agent consumption.
- Endpoint docs are task-oriented and answer-first (e.g. 'Run the query and get the results', 'Cancel a running query by its request ID', 'Trigger pre-aggregation build jobs') with realistic copy-pasteable curl examples and real response payloads.
- The discovery layer is split: the primary cube.dev/llms.txt is a marketing/article index (comparisons, roundups), while the genuinely useful API index lives at docs.cube.dev/llms.txt — an agent starting at the root domain gets the weaker file first.
- Naming is inconsistent across the REST surface: the core query API is camelCase (queryType, responseFormat, preAggregations) but the newer Metadata API uses snake_case (is_primary_key, table_references, data_sources), forcing an agent to handle both conventions.
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Publish AGENTS.md in the cube-js/cube repo (and reference it from the docs) — it is the single missing rising-standard discovery signal and a quick win given Cube's existing agent focus.
- 02Point cube.dev/llms.txt at the API/docs index (or link docs.cube.dev/llms.txt prominently) so an agent landing on the root domain reaches API-focused content, not the marketing article roundup — and trim the docs llms.txt below ~50KB for token-efficient consumption.
- 03Add a dedicated errors reference that maps common 4XX/5XX responses to actionable recovery steps (which parameter was invalid, how to retry, how to resolve auth failures) rather than surfacing errors only inline per endpoint.
- 04Standardize field-name casing across the REST API — align the Metadata API's snake_case with the core query API's camelCase (or document the split explicitly) so agents don't have to branch on convention.
- 05Serve a .well-known/mcp.json manifest advertising the hosted MCP endpoint and its tools/auth so agents can auto-discover the MCP surface without reading prose docs.
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.
Execution characteristics are well documented: JSON error responses with status/error fields (4XX/5XX schemas in the OpenAPI spec), a dedicated Limits & quotas page plus a query-concurrency queue page, and offset/limit pagination with a `total` field on the REST API. Idempotency keys are not documented. All claims are documentation-only and require live testing (audit mode) to verify.