MCP server wrapper for VoiceStudio (OmniVoice engine) - voice cloning, synthesis, voice design, and ASMR audio processing
VoiceStudio MCP demonstrates solid definition quality with comprehensive parameter descriptions and well-structured schemas. All 6 tools have clear descriptions (194-500+ chars, well above 20-char minimum). Parameters use Annotated[T, Field(description=...)] pattern consistently, providing per-parameter LLM guidance. Tool names follow verb_noun convention (clone_voice, synthesize_speech, list_voices, etc.). However, output schemas are not explicitly documented in the source, and error handling guidance is minimal. No tool annotations (readOnlyHint/destructiveHint) visible despite tools having clear risk profiles (WRITE, DESTRUCTIVE). Parameter validation constraints are present (ge/le bounds on numeric params) but some enum-like parameters (stereo_pan, reverb) use string descriptions instead of formal enum constraints, inviting hallucinated values.
Save a voice profile from a reference audio (5-30s WAV ideal). Two input modes: (A) ref_audio_path: local file path (WAV/MP3/etc., 5-30s ideal). (B) audio_url: YouTube (or yt-dlp-supported) URL. Combined with ts/tf it downloads + slices a clip into a temp file and uses that as the reference.
Delete a voice profile and its reference audio. Returns a dict with status and voice_name.
Generate speech using voice design keywords (instruct mode) instead of a cloned voice. Supports the same ASMR post-processing effects as synthesize_speech.
Get metadata of a single voice profile. Returns a dict with full profile fields (name, description, language, source, ref_audio_path, created_at).
List all saved voice profiles. Returns a list of dicts with name, description, language, source, ref_audio_path, created_at.
Generate speech audio from text using a cloned or designed voice. Supports optional ASMR post-processing effects (stereo panning, silence padding, reverb, binaural beats, EQ filtering).
Output schemas not documented. list_voices, get_voice_info, and delete_voice lack explicit return type documentation. LLMs cannot plan downstream tool calls or extract required fields without knowing response structure.
Enum-like parameters use string descriptions instead of formal JSON Schema enums. stereo_pan accepts 'center'|'L'|'R'|'L<->R'|'L->R'|'R->L' and reverb accepts 'none'|'small_room'|'large_room', but these are documented as free-form strings. LLMs may hallucinate invalid values like 'center-left' or 'medium_room'.
No tool annotations visible. Tools with clear risk profiles (clone_voice=WRITE, delete_voice=DESTRUCTIVE, synthesize_speech=WRITE) lack readOnlyHint/destructiveHint/idempotentHint annotations. Agents cannot distinguish safe from dangerous operations without reading descriptions.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 60 | <=2025-11-25 | v2 |
Minimal error handling guidance. No recovery hints in descriptions. E.g., clone_voice_from_audio could fail if ref_text doesn't match audio content, but no guidance on how to retry or what to do next. Descriptions mention prerequisites but not failure modes.
Mutually exclusive parameters not clearly marked. clone_voice_from_audio accepts ref_audio_path OR audio_url (not both), but the description says 'Use EITHER this OR audio_url, not both' only in individual param descriptions. A single note in the tool description would be clearer for LLM parsing.