Perplexity is Agent-Ready to agents.
Discry independently scored how well an AI agent can discover and understand the Perplexity 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 · 83/100Comprehension
55% of score · 100/100What we found
- An agent discovering Perplexity lands on a best-in-class footprint: a clean API-focused llms.txt, a 3.6MB llms-full.txt, every doc page available as raw .md, an official OpenAPI 3.1 spec at /openapi.json, and a hosted Docs MCP server. Discovery is nearly frictionless.
- robots.txt uses the newer Content-Signal directive explicitly granting ai-train=yes, search=yes, and ai-input=yes — Perplexity actively invites agent/AI consumption rather than merely tolerating it.
- Documentation is genuinely agent-usable: task-oriented endpoint descriptions, multi-language copy-pasteable examples (Python/TypeScript/curl), and — rare — explicit error-recovery guidance (429 -> exponential backoff + jitter, 5xx -> retry + log X-Request-ID, dedicated SDK error-handling guide). An agent hitting an error is told what to DO, not just the code.
- The one real discovery gap: no AGENTS.md exists in any perplexityai GitHub repo (api-cookbook, search_evals), so a coding agent cloning their cookbook gets no agent-specific orientation file.
- .well-known/mcp.json resolves to a live hosted Docs MCP server (auth=none) but only as a server pointer without inline tool declarations — functional for discovery, minimal for introspection.
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 flagship repos (api-cookbook, search_evals). This is the quickest remaining discovery win and would push the discovery dimension toward an A.
- 02Enrich .well-known/mcp.json with inline tool declarations and explicit auth metadata so agents can introspect capabilities without a round-trip to the server endpoint.
- 03Document idempotency keys for the agent/chat write endpoints so agents can safely retry on transient failures without risking duplicate side effects.
- 04Keep the /openapi.json spec in lockstep with the docs and link to it prominently from the API reference — it is present and high quality, and it should be promoted as the canonical machine-readable contract.
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 characteristics are documented well. Auth is Bearer API key (with programmatic token generate/revoke endpoints and a separate org-scoped analytics key). Errors are documented with HTTP status codes and an HTTPValidationError schema in the OpenAPI spec. Rate limits use a leaky-bucket model tied to usage tiers, with the X-Request-ID header called out for support. Cursor-based pagination (next_page/has_more) is documented for analytics endpoints. No idempotency-key mechanism is documented.