Plus AI is Good to agents.
Discry independently scored how well an AI agent can discover and understand the Plus AI 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 · 76/100Comprehension
55% of score · 96/100What we found
- An agent can read the entire Plus AI API with zero friction: GitBook serves a clean llms.txt index plus a .md version of every page, and robots.txt explicitly signals ai-train=yes / ai-input=yes on the docs domain — content negotiation and discovery both favor agents.
- Each API reference page embeds a complete, publicly accessible OpenAPI 3.1.0 spec (schemas, bearer security scheme, and typed error responses) with no signup wall, so an agent can generate a working typed client directly from the docs.
- The core two-step async pattern (create then poll, or a webhook callback) is documented end-to-end with copy-pasteable cURL and Python, including exponential-backoff handling for 429s and a realistic worked example (refresh a weekly report from an uploaded template + data file).
- Discovery gaps: no AGENTS.md in any public repo and no /.well-known/mcp.json manifest, so a coding agent probing for a machine-readable tool declaration finds nothing — even though an official Plus AI MCP server IS listed on PulseMCP and Glama.
- When a generation returns status: FAILED, the docs provide no recovery guidance — an agent would only learn the cause by trial and error, the main gap in otherwise strong error documentation.
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Add an AGENTS.md to the primary public repository / docs root — a rising standard and currently the single biggest discovery miss (full fail on a weight-3 check).
- 02Publish a /.well-known/mcp.json manifest pointing to the existing official MCP server so agents can auto-discover it directly instead of relying on a third-party registry lookup.
- 03Document explicit recovery guidance for API failure states — what causes status: FAILED and how to retry safely — to lift error-recovery guidance from partial to pass.
- 04Provide an API-focused llms.txt (or a dedicated API section with a description on every entry) rather than the current whole-product docs index, to lift llms.txt quality to pass.
- 05Serve a single consolidated openapi.json at a stable URL in addition to the per-page embeds, so an agent can pull the full spec in one request.
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.
Async, polling-based generation (create then poll, or webhook callback) authenticated with a bearer API key. Errors are machine-parseable JSON ({"message"} / {"error"}) with documented HTTP status codes. A rate limit is stated (3 create requests/min, beta) but header names are not specified. No cursor/offset pagination (list endpoints simply cap at 50-100 items) and no idempotency-key support are documented.