elevenlabs_delete_speech_engine
Delete Speech Engine. Delete a Speech Engine resource
Bulk support: accepts speech_engine_ids for batched execution.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| account | No | ||
| speech_engine_id | Yes | ||
| speech_engine_ids | No |
Delete Speech Engine. Delete a Speech Engine resource
Bulk support: accepts speech_engine_ids for batched execution.
| Name | Required | Description | Default |
|---|---|---|---|
| account | No | ||
| speech_engine_id | Yes | ||
| speech_engine_ids | No |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states 'Delete Speech Engine' while annotations declare destructiveHint: false. This is a direct contradiction—deleting a resource is inherently destructive. The description also fails to disclose any side effects, irreversibility, or permission requirements beyond what the annotations (which are contradictory) imply. Per rules, a contradiction yields a score of 1.
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?
The description is extremely concise: two sentences effectively communicate the core action and bulk capability. No redundant information or filler. Every word earns its place, making it highly efficient.
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?
For a delete operation with no output schema and no annotations, the description should disclose irreversible effects, required permissions, and the difference between single and bulk deletion. It only mentions bulk support without clarifying the single-ID path or any resulting side effects. The annotation contradiction further undermines completeness. This is insufficient for a mutation tool.
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%, so the description must compensate. It explains that speech_engine_ids enables batched execution, adding meaning to that parameter. However, it does not clarify the relationship between speech_engine_id (required) and speech_engine_ids (optional) — e.g., whether both can be provided, or if speech_engine_ids overrides the single ID. The required parameter speech_engine_id is left unexplained. Given the low coverage and partial compensation, a score of 2 is appropriate.
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?
The description clearly states 'Delete Speech Engine' — a specific verb and resource. It distinguishes itself from sibling delete tools like elevenlabs_delete_voice or elevenlabs_delete_project by naming the exact resource type. The additional mention of bulk support adds purpose nuance without ambiguity.
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 mentions bulk support via speech_engine_ids, implying a use case for batch deletion, but provides no guidance on when to use this tool versus alternatives (e.g., other delete endpoints). It does not state prerequisites, exclusions, or conditions under which single vs. batch should be used. Some context is present, but it lacks explicit when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.