LunarCrush is Needs Work to agents.
Discry independently scored how well an AI agent can discover and understand the LunarCrush 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 · 57/100Comprehension
55% of score · 81/100What we found
- An agent discovering LunarCrush lands unusually well: a purpose-built agent interface at lunarcrush.ai serves every endpoint as clean markdown (JSON/CSV optional) and its llms.txt lists all routes with parameters — the lunarcrush.com llms.txt explicitly redirects AI agents there rather than at the human marketing site.
- The canonical v4 reference (github.com/lunarcrush/api) gives every endpoint a task-oriented one-line purpose, a real curl example, a realistic JSON response, and a field-by-field schema in consistent snake_case, so an agent can construct correct calls without guessing field names or shapes.
- An official, registry-listed MCP server (PulseMCP + Smithery) means an agent can connect over MCP out of the box instead of hand-rolling REST calls — a strong native-agent on-ramp.
- Discovery is dragged down by missing machine-readable scaffolding: there is no OpenAPI/Swagger spec, no AGENTS.md in either official repo, and /.well-known/mcp.json falls through to the SPA shell instead of returning tool declarations.
- When calls fail, an agent is largely on its own: there is no error-code catalog, no documented rate limits, and no retry/recovery guidance, so failures are discovered by trial rather than read in advance.
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Publish an OpenAPI 3.1 spec at a stable path (e.g. https://lunarcrush.com/openapi.json) — the single biggest score lift (discovery weight 5) and it lets agents auto-generate typed clients from the already-thorough endpoint schemas.
- 02Add an Errors & Rate Limits page covering HTTP status codes, the {"error": ...} format, specific rate limits with their response headers, and concrete recovery steps (e.g. 'on 429, back off using the Retry-After header') — moves both errorRecoveryGuidance and capabilityBoundaries up.
- 03Serve a real /.well-known/mcp.json with tool declarations and auth info so the SPA catch-all no longer swallows it (the same class of fix already applied to robots.txt).
- 04Add an AGENTS.md to lunarcrush/api and lunarcrush/mcp-server with auth setup and example agent workflows — a low-effort discovery win as the standard rises.
- 05Add 2-3 multi-step workflow guides (e.g. 'trending scan -> topic drill-down -> top creators -> posts') to move multiStepWorkflows from partial to pass.
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 a single, clearly documented Bearer API-key scheme (Authorization: Bearer <API_KEY>). Responses use a consistent JSON config/data envelope and errors surface as machine-parseable {"error": "..."} objects, but there is no dedicated error-code catalog, no documented rate limits, and no idempotency guidance — an agent learns limits mainly by hitting them. Pagination (page/limit/desc, with documented defaults and maximums) is well specified.