Plivo is Good to agents.
Discry independently scored how well an AI agent can discover and understand the Plivo 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 · 62/100Comprehension
55% of score · 100/100What we found
- An agent landing on Plivo's docs gets near-ideal comprehension: the site runs on Mintlify, exposes both a root llms.txt and a dedicated /docs/llms.txt documentation index, and every page renders to clean markdown with a banner pointing agents to the index — so an agent never has to scrape JS-rendered HTML.
- Endpoint pages are answer-first and task-oriented ('Send an SMS, MMS, or WhatsApp message to one or more recipients') with realistic, copy-pasteable examples in eight languages (cURL, Python, Node.js, Ruby, PHP, Java, .NET, Go) and consistent snake_case field naming throughout.
- Error recovery is a standout: the Messaging overview maps 400/401/404/429/500 to specific causes AND solutions, and the dedicated error-codes page gives every code a reason plus concrete next steps (use short codes, implement exponential backoff, verify E.164 format, check WABA status) — exactly the self-correction guidance agents need.
- Discovery is the weak dimension: no llms-full.txt, no /.well-known/mcp.json, and no AGENTS.md in the primary SDK repos, so coding agents working in a repo get no Plivo-specific guidance file.
- Plivo ships an official MCP server (github.com/plivo/mcp, with a /docs/faq/developer-tools/mcp-server page), but it could not be confirmed as listed in a major MCP registry (Glama/Smithery/PulseMCP), and there is no standard OpenAPI/Swagger spec — only a public Postman collection — so programmatic spec ingestion is harder than it should be.
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Publish a standard OpenAPI/Swagger spec at a stable, public URL (e.g. /openapi.json) and link it from the docs. This is the single highest-impact discovery fix (weight 5) — it turns the existing Postman collection into a tool-generatable, machine-ingestable contract.
- 02Add an AGENTS.md to the primary SDK repos (plivo-python, plivo-node, etc.) with setup, auth, and code-conventions guidance. It's a rising standard (weight 3) and a quick win for coding agents.
- 03List the official Plivo MCP server in the major registries (Glama, Smithery, PulseMCP) so agents discovering tools by registry can find it without crawling GitHub.
- 04Ship an llms-full.txt (or expand /docs/llms.txt into a full-content variant) so agents can pull complete API usage content in one fetch rather than following dozens of links.
- 05Publish specific messaging rate-limit numbers and the rate-limit response header names (alongside the existing 429 guidance) so agents can implement precise backoff rather than blind retries.
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 to a high standard: machine-parseable JSON responses with an api_id and numeric error_code, an HTTP status-code table, offset/limit pagination with a meta object (next/previous/total_count), and HTTP Basic Auth with copy-pasteable examples. Rate limiting is acknowledged (429 + exponential backoff guidance, plus a voice Account Limits page covering CPS/concurrency), though specific per-account messaging rate-limit numbers are not published. Idempotency keys are not mentioned anywhere in the scanned docs.