Thunder Compute is Agent-Ready to agents.
Discry independently scored how well an AI agent can discover and understand the Thunder Compute 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 · 95/100Comprehension
55% of score · 91/100What we found
- An agent looking for this API would find it effortlessly: a valid public OpenAPI spec (api.thundercompute.com:8443/openapi.json), an API-focused docs llms.txt with per-endpoint descriptions, a 256KB llms-full.txt, and an official remote MCP server listed on PulseMCP, Glama, and Cursor Directory.
- Thunder Compute ships an official OAuth-authenticated remote MCP server exposing 28 tools, plus an AGENTS.md in the thunder-cli repo that spells out MCP setup and CLI commands — this is a rare case of infrastructure built specifically for coding agents, not just human developers.
- Endpoint documentation is genuinely task-oriented and answer-first: each page leads with what you can accomplish (e.g. 'Append an SSH public key to an existing instance's authorized_keys') plus behavioral gotchas (private key returned only once) before the embedded OpenAPI schema.
- Capability boundaries are unusually well documented for a GPU cloud — a dedicated Compatibility page lists known incompatibilities (managed memory/UVM, FFmpeg GPU accel, GPU profilers) WITH workarounds, alongside Restrictions and Technical Specifications pages.
- The one soft spot: two OpenAPI specs coexist with divergent field naming (snake_case cpu_cores/gpu_type in the canonical openapi.json vs camelCase cpuCores/gpuType in docs/swagger.json), and error-recovery guidance is thin — errors are documented as codes but with vague, mostly 'retry or contact support' remediation.
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Add per-error recovery guidance: map the documented 400/401/500 (and any 429) responses to explicit agent actions — e.g. 'on 401, refresh your Bearer token'; 'on 429, wait for the Retry-After header' — so agents can self-correct instead of failing.
- 02Reconcile the two specs: retire or align docs/swagger.json with the canonical openapi.json so field naming is consistently snake_case; the current camelCase/snake_case split risks agents constructing malformed request bodies.
- 03Document rate limits and pagination explicitly — publish the limits and header names, and state the pagination model for list endpoints (or confirm none) so agents don't discover throttling by failing.
- 04Serve a /.well-known/mcp.json manifest advertising the remote MCP endpoint and its tool declarations, so agents can discover the MCP server programmatically instead of only via docs or third-party registries.
- 05Add an AGENTS.md to the thunder-compute-documentation repo (currently only the CLI repo has one) so agents working directly against the docs source get the same orientation.
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.
The OpenAPI spec documents a clean, machine-parseable error format (ErrorResponse with integer code, error slug, and human message) and Bearer API-key auth, with OAuth 2.0 for the remote MCP server. Rate limits, pagination, and idempotency keys are not documented — an agent would learn those boundaries only by hitting them.