CData is Needs Work to agents.
Discry independently scored how well an AI agent can discover and understand the CData 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 · 67/100Comprehension
55% of score · 78/100What we found
- An agent can consume CData's API docs natively: every reference page is served as clean markdown (.md) with an embedded OpenAPI 3.1 spec, and a full llms.txt index lets the agent enumerate every endpoint before fetching a single page — best-in-class machine comprehension.
- An agent looking to integrate CData via MCP will find it immediately — the Official Connect AI server plus dozens of source-specific CData MCP servers are listed across PulseMCP, Glama, and Smithery.
- Endpoint descriptions are task-oriented ('execute a SQL query against one or more data sources', 'return a list of tables and views for a given schema') and the auth page ships a copy-pasteable curl example with realistic values, so an agent understands what /query, /batch, and /tables actually do.
- An agent would hit walls on failure: there is no rate-limit documentation, no dedicated error-code reference (the Errors page 404s), and error entries give only a code and message with no 'if X, do Y' recovery steps — combined with the 200-can-contain-an-error gotcha, an agent learns limits by failing.
- Several agent-discovery surfaces are closed off: no AGENTS.md in the public MCP repos, llms-full.txt and .well-known/mcp.json return 403/404, and the declared sitemap index blocks automated fetchers (403).
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Publish a dedicated Errors reference page listing the ErrorCode enum values, their meanings, and explicit recovery guidance (what to do on auth failure, timeout, or malformed query) — this directly lifts errorRecoveryGuidance and capabilityBoundaries.
- 02Document rate limits, concurrency limits, and any retry/back-off headers so an agent can throttle correctly instead of discovering limits by failing.
- 03Add multi-language request examples (Python, Java, Node) alongside curl on the core /query, /batch, and /exec pages — the drivers already exist, and surfacing them would move realisticExamples from partial to pass.
- 04Right-size the docs llms.txt (currently ~95KB) into a leaner API-focused index under 50KB, or split it into llms.txt + a reachable llms-full.txt (the current llms-full.txt returns 403).
- 05Allow automated fetchers to reach the sitemap (currently 403) and add an AGENTS.md to the public MCP-server repos — low-effort discovery wins.
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.
Auth is well-documented (OAuth and Basic/PAT for the standard REST API, JWT for Embed). The error format is a machine-parseable JSON object with a code and message plus an ErrorCode enum in the OpenAPI spec, and the docs flag a critical gotcha — a 200 response can still contain an error, so agents must inspect the body. No rate limits or idempotency keys are documented, and there is no API-level pagination (row limiting is delegated to SQL LIMIT inside the query), so an agent looking for pagination parameters will not find them.