Loading ToolBench
AI-powered text-to-speech with voice cloning using NeuTTS models via Model Context Protocol
The server provides 5 tools with basic descriptions and schema definitions via FastMCP. However, critical gaps prevent higher scores: (1) Most tool descriptions are vague and lack actionability, they describe WHAT without explaining WHEN or WHY to call each tool. E.g., 'tts_synthesize' lacks guidance on speaker selection best practices, expected latency, or when to use voice cloning vs. built-in speakers. (2) Parameter descriptions are incomplete, 'ref_text' in tts_add_speaker merely says 'Exact transcript' but does not explain sensitivity to accents, background noise, or minimum/maximum duration implications. (3) Output schemas are not documented in the code, tools return strings and JSON, but the structure of returned JSON is not formally specified. (4) Error handling is absent, tools do not document what failures look like, when retries are safe, or what the LLM should do if synthesis fails. (5) Composition is weak, tts_add_speaker and tts_synthesize should cross-reference: after cloning, what's the next natural step? The descriptions do not guide the agent. (6) No per-parameter types for some inputs (e.g., wav_path is just 'string' with no validation hint). Average tool description length is ~100 chars (below baseline 194), and parameter descriptions average ~40 chars (below baseline 72). Only 3 of 5 parameters have explicit type+description pairs.
Clone a new voice from an audio sample and persist it for future use.
Get started with Cheema Text-to-Voice. Returns a complete usage guide with examples for all tools. Call this first if you're new!
List available NeuTTS backbone models and show which one is currently loaded. Returns a JSON object with 'current' (the active model) and 'available' (all known model repo IDs).
List all available speaker voices. Returns a JSON object mapping speaker names to their metadata (language, source: builtin/custom).
Convert text to speech using a specified speaker voice.
Output schemas not documented. Tools return JSON structures (e.g., tts_list_speakers returns 'JSON object mapping speaker names to metadata') but the exact field names, types, and nesting are not formally specified. LLMs cannot reliably extract data or plan downstream calls without seeing the schema.
Parameter descriptions lack validation constraints and format specifications. E.g., 'wav_path' (in tts_add_speaker) does not state file encoding, sample rate range, mono vs. stereo requirement, or maximum file size. 'ref_text' lacks guidance on punctuation sensitivity or length limits. LLMs cannot validate inputs before calling tools, risking invalid state.
Tool descriptions are too short and lack context for when to use each tool. 'tts_synthesize' (45 chars) does not explain: when to use vs. voice cloning, expected output quality, latency, or speaker selection hints. Average tool description is ~100 chars; baseline is 194 chars.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 60 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 45 | - | v1 |
No error handling or recovery guidance. Tools do not document expected failures (e.g., invalid speaker name, malformed WAV, ref_text mismatch). Without error classification and recovery hints, LLMs cannot plan retries or ask users for clarification.
Weak tool composition and chaining hints. After tts_add_speaker succeeds, how does the agent know to call tts_synthesize with the new speaker name? Descriptions do not guide the agent through multi-step workflows or cross-reference related tools.
Parameter descriptions lack explicit type hints for format/range. E.g., 'language' in tts_add_speaker accepts a string but does not enumerate valid codes (en-us, de, fr-fr, es). LLMs will hallucinate invalid language codes without an enum constraint.