delete_voice
Delete your voice clone and its provider samples. A voice in an active call cannot be deleted.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| voice_id | Yes | ||
| request_id | Yes |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Delete your voice clone and its provider samples. A voice in an active call cannot be deleted.
| Name | Required | Description | Default |
|---|---|---|---|
| voice_id | Yes | ||
| request_id | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint=true and idempotentHint=false, so the safety profile is covered. The description earns credit for disclosing a real side effect beyond the obvious one — that provider-side samples are also deleted — and for stating the active-call precondition, which the annotations do not convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, the destructive scope front-loaded and the constraint second. Every sentence carries information and nothing is padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Return values need not be explained since an output schema exists, and the destructive/blast-radius picture is decent. However, for a permanently destructive operation with two fully undocumented required parameters, the description should say what request_id is for and whether a failed delete (voice in active call) leaves anything changed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and neither required parameter is mentioned. The meaning of voice_id is inferable, but request_id (a UUID request token) is completely unexplained — especially notable given idempotentHint=false, since an agent cannot tell whether request_id provides idempotency or is purely for tracing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Delete your voice clone') and adds the scope detail that provider samples are removed too. It does not explicitly distinguish itself from rename_voice or create_voice, but the operation is unambiguous from the name plus description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a precondition ('A voice in an active call cannot be deleted') rather than guidance on when to choose this over alternatives such as rename_voice. Usage is implied by the verb but there is no explicit when/when-not framing or routing to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.