Voicemod is Poor to agents.
Discry independently scored how well an AI agent can discover and understand the Voicemod 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 · 38/100Comprehension
55% of score · 65/100What we found
- An agent starting at voicemod.net gets actively misdirected: the site ships a 52KB llms.txt that covers the company, product features, and tutorials with zero mentions of the Control API, Cloud API, or their documentation subdomains — the one discovery artifact Voicemod built points agents away from the developer surface.
- The API documentation is fragmented across three properties (control-api.voicemod.net, cloud-api.voicemod.net, doc.voicemod.tech) with no unified index; the third is a JS-rendered Postman page that returns only 'Loading Collection...' to a scraper, making the legacy REST API effectively invisible to agents.
- A machine-readable AsyncAPI spec for the WebSocket Control API exists (asyncapi.yaml in the public GitLab repo voicemod/kit/control-api-documentation) but is not linked from the docs site, was last updated in October 2023, and there is no OpenAPI spec at all for the REST Cloud API.
- The Docusaurus docs themselves read well for agents: task-oriented endpoint descriptions, answer-first pages (method + URL at top), Python and JavaScript examples, a documented JSON error object, and honest capability notes like the 200-character TTS limit and a Known Issues section.
- An agent cannot self-serve credentials: both APIs require filling in a web form (Typeform for Control API) and waiting for an API key by email, so even a perfectly informed agent stalls at authentication.
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Make the existing llms.txt API-aware: add a Developer APIs section linking control-api.voicemod.net and cloud-api.voicemod.net with one-line descriptions, or ship dedicated llms.txt files on the doc subdomains themselves.
- 02Publish the AsyncAPI spec at a stable URL on control-api.voicemod.net (e.g. /asyncapi.yaml), refresh it, and add an OpenAPI spec for the Cloud API's REST endpoints — the content already exists in the docs.
- 03Retire or replace doc.voicemod.tech: the Postman-generated page is JS-rendered and unparseable by agents; fold the legacy REST reference into the Docusaurus Cloud API docs.
- 04Document rate limits and add recovery guidance to error docs (e.g. what to do on 401 vs 403, retry behavior for 202 async jobs, port-cycling guidance formalized for Control API connection failures).
- 05Add an AGENTS.md to the public GitLab kit repos and list the Control API in MCP registries — a local WebSocket voice-control API is a natural MCP server candidate and currently invisible in agent tooling ecosystems.
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.
Auth is API-key based across all three API surfaces, but keys are requested via a Typeform form with email delivery — no self-serve provisioning. Error responses are documented as machine-parseable JSON (message/description/code, errors array for Cloud API). No rate limits or pagination documented anywhere; a request-id signing/verification scheme is documented for the legacy REST API but no idempotency keys.