Loading ToolBench
A Model Context Protocol server providing ElevenLabs text-to-speech integration
The server has 4 tools with basic naming and visible schemas, but critical gaps in descriptions and parameter quality reduce overall score. Tool names start with action verbs (good), but descriptions are terse (under 100 chars for 3 of 4 tools), and parameter descriptions are minimal or missing. Schemas are present but lack detail around format constraints, enums, and error cases. No evidence of output schema documentation. Error handling guidance is absent. The tool composition is reasonable (separate concerns: generate_simple, generate_script, get_audio, delete_job), but the interface lacks LLM-friendly affordances like pagination, natural identifiers, or recovery hints.
Delete a voiceover job from history
Generate audio from a structured script with multiple voices and actors. Accepts either: 1. Plain text string 2. JSON string with format: { "script": [ { "text": "Text to speak", "voice_id": "optional-voice-id", "actor": "optional-actor-name" }, ... ] }
Generate audio from plain text using default voice settings
Retrieve a generated audio file by job ID
Descriptions are uniformly terse (35-50 chars). Critical tool generate_audio_script lacks clarity on input format expectation, 'JSON string containing script array or plain text' is vague about which is preferred, required format details, and error paths. Descriptions should be 100 - 200 chars to guide LLM selection.
Parameter descriptions are either missing or cryptic. 'script' param in generate_audio_script has a lengthy schema description but lacks guidance on format preference. 'voice_id' in generate_audio_simple says 'Optional voice ID to use for generation' but does not explain what happens if omitted (does it use a default? which one?) or how to discover valid voice IDs (should call a discovery tool first?).
No output schemas documented. Tools return results but LLM has no structured expectation of response fields. E.g., generate_audio_simple likely returns a job_id, but this is not declared. Without documented return types, downstream tools cannot be reliably chained.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 50 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
No error handling or recovery guidance. If generate_audio_simple fails (invalid voice_id, text too long, API quota exceeded), the tool description provides no hint about root causes or corrective actions. LLM cannot diagnose or retry intelligently.
delete_job tool lacks confirmation/dry-run pattern. Agents can invoke irreversible deletion with no safeguard. Consider requiring explicit confirmation step or offering a separate 'preview_delete' tool.
voice_id parameter in generate_audio_simple is optional but its discovery mechanism is opaque. Web UI imports a getVoices() method (seen in clients/web-ui/src/routes/api/voices/+server.ts) but this is NOT exposed as a tool. LLM cannot discover or validate voice IDs without a dedicated discovery tool.
generate_audio_script accepts both plain text AND JSON string (polymorphic input). This violates single-responsibility and confuses the LLM about which format to use. Split into two tools: generate_audio_simple (text) and generate_audio_multi_voice (structured script object with explicit schema).
job_id parameter in get_audio_file and delete_job has no format constraint. Is it a UUID? A numeric ID? An encoded string? Lack of format guidance invites invalid input and wastes retries.