A Model Context Protocol server providing VoiceVox text-to-speech functionality for LLMs
Two tools with basic but incomplete documentation. Both tools have descriptions and input schemas, but parameter descriptions lack depth, and output schemas are undocumented. Tool naming follows verb_noun convention (get_voices, text_to_speech). The server has functional tools for TTS, but falls short of production-grade quality in several areas: missing output schema documentation, incomplete parameter constraints, and no error recovery guidance.
Get a list of available voices in VoiceVox
Convert text to speech using VoiceVox and save to a file
Output schemas not documented. Both tools have no explicit documentation of what fields they return. LLMs cannot plan downstream operations or extract expected data from responses.
get_voices description is vague (15 chars). Does not explain what structure is returned, when to call it, or how to use the response in a workflow. Minimal context for tool selection.
text_to_speech lacks recovery guidance in error cases. If VoiceVox API is unreachable or speaker_id is invalid, no guidance on how to retry or what the LLM should try next.
speaker_id parameter has no validation description. Is it an integer ID only, or can it accept speaker names? What is the valid range? Does the API reject invalid IDs gracefully?
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 58 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 35 | - | v1 |
speed parameter default of 1.3 is unusual and may cause surprises. No explanation of valid range (e.g., 0.5 - 2.0) or consequences of out-of-range values.
text_to_speech modifies state (writes files, plays audio) but description does not explicitly say so. LLMs need to know which tools have side effects for idempotency reasoning.
No pagination or result limits documented. If get_voices returns 100+ speaker/style combinations, this could bloat responses. No guidance on limiting results.