Loading ToolBench
voicevox-mcp is a minimal STDIO-only server with 2 tools. Both tools have basic descriptions and input schemas, but significant quality gaps undermine usability: (1) tool naming lacks action verbs, 'speakers' should be 'list_speakers' to match LLM expectations; (2) descriptions are under 30 chars on 'speakers', well below the 194-char baseline; (3) no parameter descriptions for the 'text' param in 'speak'; (4) no output schemas documented, LLMs cannot reason about return structures; (5) no error handling or recovery guidance; (6) no tool annotations (destructiveHint, idempotentHint); (7) environment variables (SPEAKER_ID, VOICEVOX_API_URL) are hardcoded in source instead of injected safely; (8) the 'speak' tool hardcodes side effects (saves to /tmp/, plays audio via macOS afplay) with no documentation or control, this is a destructive operation (WRITE risk) that should declare so and offer a dry-run.
Synthesizes text-to-speech using VOICEVOX with the configured speaker, saves output to /tmp/voicevox.wav, and plays the audio
Fetches the list of available speakers from VOICEVOX
Tool naming violates verb-first convention. 'speakers' should be 'list_speakers', LLMs infer intent from action verbs, and 'speakers' is ambiguous (fetch? describe? manage?). 'speak' is too generic and doesn't convey synthesis or TTS.
Parameter 'text' in 'speak' tool lacks description. The schema declares z.string() but does not explain expected length, encoding, or language constraints. LLMs cannot reason about parameter usage without descriptions.
'speakers' tool description is 59 chars ('Fetches the list of available speakers from VOICEVOX'), below the 194-char baseline and below best practice (10 - 1024 chars). Does not explain WHEN to call it or what structure is returned.
No output schemas documented. Both tools return {content: [{type: 'text', text: ...}]} but LLMs have no way to know what fields to expect in the JSON response. For 'speakers', what is the structure of speaker objects? For 'speak', what does 'OK' convey, success? Error details?
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 39 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 27 | - | v1 |
'speak' tool performs destructive operations (writes /tmp/voicevox.wav, plays audio via afplay) with no dry-run, confirmation step, or option to suppress side effects. Agents cannot safely test or compose this tool. No destructiveHint annotation.
No error handling or recovery guidance. If VOICEVOX is unreachable, API fails, or SPEAKER_ID is invalid, raw fetch errors or thrown exceptions are returned. LLMs receive no actionable next steps.
Credentials and secrets hardcoded in environment variable resolution within tool logic. VOICEVOX_API_URL, SPEAKER_ID, and SPEED_SCALE are read at runtime with no validation or secure injection pattern. If any are logged, they leak into traces.
'speak' tool hardcodes output file path (/tmp/voicevox.wav) and macOS-specific audio playback (afplay). No platform detection, no option to return audio data or specify output path. Coupling to host environment and OS reduces portability.