Clidey (WhoDB) is Needs Work to agents.
Discry independently scored how well an AI agent can discover and understand the Clidey (WhoDB) 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 · 45/100Comprehension
55% of score · 96/100What we found
- An agent trying to reach the canonical docs at docs.whodb.com would fail: every path returns an Envoy 'fault filter abort' error, so the hosted documentation is effectively unreachable. Agents must fall back to the GitHub repo — which, fortunately, is excellent.
- The GitHub repo is unusually agent-instrumented: a canonical AGENTS.md (with CLAUDE.md/.codex/.agents pointing to it), a glama.json MCP manifest, and a published GraphQL SDL. An agent gets clear operating rules and a machine-readable API contract without any live calls.
- WhoDB ships a first-class MCP server (whodb-cli mcp serve) listed and A-rated on the Glama registry, with ~10 task-oriented tools (whodb_query, whodb_audit, whodb_diff, whodb_erd, whodb_explain, whodb_confirm). This is the single strongest agent-readiness signal — an agent can drive the product natively via MCP.
- Capability boundaries are exceptionally clear: Community vs Platform feature split, exact supported-database lists, explicit 'read-only, never writes to source' guarantees, and a detailed FAQ. An agent can reason about what WhoDB can and cannot do before acting.
- Discovery signals a machine would auto-check (llms.txt, sitemap on the docs host, .well-known/mcp.json) are entirely absent, and the primary docs host being down compounds this — so passive discovery scores poorly despite the strong hand-built agent artifacts in the repo.
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Fix the docs.whodb.com host — it returns 'fault filter abort' on every path. A dead documentation domain is the highest-impact failure: agents (and the search engines that feed them) cannot read the canonical docs at all.
- 02Publish an llms.txt (and llms-full.txt) at docs.whodb.com summarizing WhoDB's capabilities, the GraphQL API surface, and the MCP tool catalog, with links to the CLI README and schema. This is a fast discovery win that would lift the Discovery grade immediately.
- 03Serve a sitemap.xml on the docs host listing the API/CLI/MCP pages so crawlers and agents can enumerate documentation instead of relying on the GitHub tree.
- 04Add a systematic error-recovery reference: map common GraphQL/MCP errors (connection failures, ambiguous-connection, write-confirmation-required, permission-denied) to explicit recovery steps. Today error handling is implied rather than tabulated.
- 05Expose the GraphQL SDL (and MCP tool schema) directly from the docs host — e.g. a /schema endpoint — so agents can fetch the contract from the product domain rather than raw.githubusercontent.com.
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.
WhoDB exposes a GraphQL API (not REST) with a fully published SDL schema. GraphQL responses carry structured errors; the MCP server documents a write-confirmation/token flow and a 'multiple connections' error case. Pagination is explicit (pageSize/pageOffset args, virtualized/streamed grid, paginated results). No rate limits or idempotency keys are documented — appropriate for a self-hosted, single-tenant tool but leaves those behaviors unspecified for agents.