Massed Compute is Good to agents.
Discry independently scored how well an AI agent can discover and understand the Massed 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 · 71/100Comprehension
55% of score · 84/100What we found
- An agent can act on this API almost immediately: Massed Compute ships an official MCP server (14 tools mapping 1:1 to /api/v1 endpoints, listed on Glama and mcpservers.org) plus four downloadable Agent Skills (GPU selection, launch playbook, cost control, safe terminate) following the open Agent Skills standard — a level of agent tooling that puts it ahead of most infrastructure APIs.
- A valid OpenAPI 3.0.0 spec is publicly downloadable (redocusaurus/plugin-redoc-0.yaml) and the reference is Redoc-rendered, so an agent can ingest the full contract of all 14 endpoints without scraping.
- Error recovery is genuinely agent-usable: a symptom -> cause -> fix troubleshooting table tells an agent exactly what to do on 401, 402, and 429, and documents the SXM-vs-PCIe image-compatibility constraint — self-correction guidance most APIs lack.
- Discovery has a self-inflicted gap: the only llms.txt lives on the marketing domain (massedcompute.com), is Yoast-generated and product/blog-focused, and never links to the actual API docs on vm-docs.massedcompute.com — so an agent starting from llms.txt would not find the API reference.
- Naming is inconsistent enough to trip an agent: request params are camelCase (productName, sshKeys) while response fields are snake_case (price_cents_per_hour, os_booted), the same concept appears as vcpu / vcpus / vcpu_count, and price is returned as both a number (0.99) and a string ("0.990000").
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Publish an API-focused llms.txt on vm-docs.massedcompute.com that links the OpenAPI spec, the endpoint reference, the MCP setup guide, and the Agent Skills — the current marketing-domain llms.txt doesn't point agents to any of these.
- 02Add an AGENTS.md to the massed-compute-mcp GitHub repo so coding agents working against the MCP server / API get repo-level context (none currently exists).
- 03Normalize naming across the contract: pick one casing convention for request and response fields, use a single term for vCPU count, and return price consistently as a number — inconsistency forces agents to guess field shapes.
- 04Document error-response bodies in the OpenAPI reference (not just success 200/202): add the JSON error schema and 4xx/5xx responses per endpoint so agents can parse failures programmatically.
- 05State concrete rate limits (requests/window and the relevant response headers) rather than the current qualitative '429 -> wait a minute', so agents can back off precisely.
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.
Bearer-token auth is clearly documented (Authorization: Bearer {api_token}) with a dedicated token-provisioning guide. Error handling is covered via an MCP troubleshooting table (401/402/429, image incompatibility) with actionable fixes, but the API reference itself documents only success responses (200/202) and no error-body schema. Rate limiting is acknowledged (429 -> 'wait a minute') but without specific numeric limits or header names; no pagination or idempotency support is documented.