Perigon is Agent-Ready to agents.
Discry independently scored how well an AI agent can discover and understand the Perigon 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 · 93/100What we found
- An agent arriving cold would orient itself almost instantly: robots.txt explicitly allows every major AI crawler (GPTBot, ClaudeBot, anthropic-ai, PerplexityBot, CCBot) and points to an on-domain AGENTS.md that acts as a machine-readable index to the OpenAPI spec, auth guide, MCP endpoint, and .well-known discovery files. This is one of the most deliberately agent-native discovery layers a scan has surfaced.
- A hosted MCP server (streamable-HTTP at mcp.perigon.io/v1/mcp) is published with a valid .well-known/mcp/server-card.json declaring tools and required API-key auth, and is listed on Glama, PulseMCP (official), and Smithery — so an agent could connect via MCP without ever reading the REST docs.
- The full OpenAPI 3.0.1 spec is publicly reachable at /openapi.json with 29 paths and task-oriented endpoint summaries/descriptions ('Search and filter all news articles...'), giving an agent a complete, structured capability map. Parameter naming is uniformly camelCase across all 155 parameters — no casing drift.
- Comprehension is held back at only one margin: the OpenAPI parameters carry no inline example values and code samples lean on single-language curl, so an agent must infer some formats. Error recovery, by contrast, is strong — a dedicated Troubleshooting page gives explicit per-error fixes (401 check apiKey typos; 403 verify email + check plan; 404 check for invalid IDs; 500 dates must be YYYY-MM-DD and parentheses/quotes balanced) plus a step-by-step query-debugging method.
- llms-full.txt returns 404 — the only missing discovery artifact — but its absence is immaterial here because the OpenAPI spec plus a well-structured llms.txt already cover the same ground for an agent.
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Add inline example values to OpenAPI parameters and multi-language code samples (Python/TypeScript/Go) on endpoint reference pages so an agent can copy-paste working calls without guessing formats — the single biggest comprehension lift.
- 02Surface the Troubleshooting page's recovery guidance into the machine-readable layer (OpenAPI parameter descriptions or AGENTS.md) so an agent gets per-error, per-parameter self-correction hints without having to fetch the human docs page.
- 03Publish an llms-full.txt (or content-negotiated markdown for /docs pages) to complete the discovery set and give agents a single comprehensive markdown corpus without scraping the nav-heavy HTML docs.
- 04Surface concrete plan/quota capability boundaries (requests/month, history window, endpoint availability by tier) in the machine-readable surfaces (OpenAPI description or AGENTS.md), not only on the human pricing page, so an agent knows its limits before it hits a 429/403.
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.
Execution documentation is strong. Errors return machine-parseable JSON ({status, message, timestamp}) with a full HTTP status-code table (400/401/403/404/429/5xx). Rate limits are documented with named headers (X-Rate-Limit-Retry-After-Millis, X-Rate-Limit-Requests-Left, X-Rate-Limit-Duration-Millis, X-Rate-Limit-Total-Requests) and a worked example. Pagination has a dedicated docs page (size/page params). Idempotency keys are not mentioned (mostly a read-heavy GET API, so lower relevance). Claims are documentation-only and unverified by live testing.