Loading ToolBench
A Model Context Protocol server for VoiSpark voice and audio services, providing tools for text-to-speech, voice changing, voice cloning, and conversation generation.
Server has 6 tools with moderate definition quality. All tools have descriptions (prerequisite quality), but several have incomplete parameter schemas, undocumented return types, and missing error handling guidance. Tool naming is generally good (verb_noun pattern), but schemas show gaps: parameter types are sometimes inferred from Pydantic models rather than explicitly documented in JSON Schema. Output schemas are not documented in tool descriptions. The server relies heavily on prerequisite resources (conversation://models, textToSpeech://models, etc.) which is good for discoverability, but tool descriptions lack concrete examples of expected return structures. No security-critical parameters are exposed, but permission and audit requirements are not documented. Error handling is minimal, no recovery guidance or categorization of error types.
Transform an existing audio file to use a different voice. Prerequisites: 1. Call 'voiceChanger://models' resource to get available providers and models 2. Optionally call 'voices://providers' and 'voices://{provider_id}/{voice_type}/list' to explore available target voices Args: provider: Voice changer provider name obtained from 'voiceChanger://models' model_id: The voice changer model identifier from the provider's model list voice_id: The target voice identifier to transform the audio into audio_data: Base64 encoded audio file to be transformed Returns: Task details with voice transformation status and processed audio information
Clone a voice from an audio sample to create a new synthetic voice. Prerequisites: 1. Call 'voiceClone://models' resource to get available providers and models 2. Prepare audio sample (recommended: 10-30 seconds of clean speech) 3. Configure provider-specific settings based on the selected model Args: provider: Voice clone provider name obtained from 'voiceClone://models' model_id: The voice clone model identifier from the provider's model list audio_data: Base64 encoded audio sample for voice cloning configs: Provider-specific configuration (CartesiaVoiceCloneConfig or MiniMaxVoiceCloneConfig) Returns: Voice clone task details with processing status and cloned voice information
Generate AI conversation with specified parameters. Prerequisites: 1. First call 'conversation://models' resource to get available providers and model parameters 2. Call 'conversation://speakers' resource to get available speakers for configuration Args: provider: The conversation provider obtained from 'conversation://models' conversation: List of conversation turns defining the dialogue structure speaker: List of speaker configurations obtained from 'conversation://speakers' Returns: Task details with conversation generation status and task ID
Return/Output schemas are not documented for any tool. Descriptions mention 'Task details' or 'Detailed information' but provide no JSON Schema for responses. This forces LLMs to guess field names and types, causing chaining errors when trying to use outputs from one tool as inputs to another.
Parameter 'configs' in clone_voice tool uses a plain object type with union description ('CartesiaVoiceCloneConfig or MiniMaxVoiceCloneConfig') instead of proper JSON Schema oneOf. This is not machine-parseable and leaves LLM to guess the correct config structure for each provider.
No error handling guidance in any tool description. LLM does not know: (1) which errors are retryable, (2) what to do if a resource (like a model or provider) is not found, (3) what invalid parameter values look like or how to correct them. For example, if provider='invalid_tts' is passed to generate_tts, the tool will fail, but the description gives no hint that provider must match a value from textToSpeech://models.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 57 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 56 | - | v1 |
Generate TTS (Text-to-Speech) audio from text input. Prerequisites: 1. Call 'textToSpeech://models' resource to get available providers, models, and voices 2. Optionally call 'voices://providers' and 'voices://{provider_id}/{voice_type}/list' to explore additional voice options Args: provider: TTS provider name obtained from 'textToSpeech://models' text: The text content to convert to speech model_id: The TTS model identifier from the provider's model list voice_id: The voice identifier compatible with the selected provider and model Returns: Task details with TTS generation status and audio file information
Get detailed information about a specific historical task. Prerequisites: 1. Call 'history://list' resource first to get available history_id values Args: history_id: The unique identifier of the history record Returns: Detailed history information including task results and processing metadata
Get detailed information about a specific speaker. Prerequisites: 1. Obtain speaker_id from 'conversation://speakers' resource first Args: speaker_id: The unique identifier of the speaker Returns: Detailed speaker information including voice characteristics and capabilities
Descriptions lack concrete examples of required input structure. For generate_conversation, the 'conversation' parameter is typed as list of ConversationTurn objects with (text, speaker_index) properties, but the description doesn't show an example turn structure. Similarly, 'speaker' parameter expects list of SpeakerConfigItem but structure not shown.
No idempotency guarantees documented. generate_conversation, generate_tts, change_voice, and clone_voice all appear to be write operations (they return 'Task details' suggesting asynchronous processing). If an agent retries due to ambiguous failure, will these tools create duplicate tasks/audio files? Idempotency must be declared.
Parameters like audio_data in change_voice and clone_voice accept Base64-encoded binary but lack format constraints in schema. Description mentions 'Base64 encoded audio file' but no JSON Schema pattern or maxLength is specified, leaving LLM free to pass invalid or huge payloads.
No tool annotations (@readOnlyHint, @destructiveHint, @idempotentHint) visible in source. get_speaker_details and get_history are read-only but not marked as such. generate_conversation, generate_tts, change_voice, clone_voice are destructive/state-modifying but lack destructive annotation.