Loading ToolBench
MCP server providing image generation and text-to-speech capabilities via VseGPT API
Both tools have significant quality gaps. Tool names use action verbs (generate_image, generate_speech) which is correct per naming patterns, but descriptions are verbose and poorly structured for LLM consumption. Input schemas are present with type definitions, but parameter descriptions lack actionable constraints. Output is unstructured (raw file paths as strings). Error handling is minimal, no recovery guidance, no categorization of error types. No validation of inputs (e.g., voice_id enum not enforced at schema level despite being listed). The server mixes documentation examples into descriptions rather than using formal constraints.
Using prompt, generate image via VseGPT api call. Prompt must be in English language!! :return URL path to file in format like "C:/Test/image_file.png" (URL local path). If user require markdown, local path can be rendered like this: 
Generate speech via provided text. Params: - text - text to speech - voice_id - one of voices [alloy, ash, ballad, coral, echo, fable, onyx, nova, sage, shimmer, verse] - instructions - instructions of HOW generate speech. Examples of instructions: (Instructions For Bedtime Story) Affect: A gentle, curious narrator, guiding a magical, child-friendly adventure through a fairy tale world. Tone: Magical, warm, and inviting, creating a sense of wonder and excitement for young listeners. Pacing: Steady and measured, with slight pauses to emphasize magical moments and maintain the storytelling flow. Emotion: Wonder, curiosity, and a sense of adventure, with a lighthearted and positive vibe throughout. Pronunciation: Clear and precise, with an emphasis on storytelling, ensuring the words are easy to follow and enchanting to listen to. - (Instructions For Dramatic) Voice Affect: Low, hushed, and suspenseful; convey tension and intrigue. Tone: Deeply serious and mysterious, maintaining an undercurrent of unease throughout. Pacing: Slow, deliberate, pausing slightly after suspenseful moments to heighten drama. Emotion: Restrained yet intense—voice should subtly tremble or tighten at key suspenseful points. Emphasis: Highlight sensory descriptions ("footsteps echoed," "heart hammering," "shadows melting into darkness") to amplify atmosphere. Pronunciation: Slightly elongated vowels and softened consonants for an eerie, haunting effect. Pauses: Insert meaningful pauses after phrases like "only shadows melting into darkness," and especially before the final line, to enhance suspense dramatically. - (Instructions For Mad Scientist character style) Delivery: Exaggerated and theatrical, with dramatic pauses, sudden outbursts, and gleeful cackling. Voice: High-energy, eccentric, and slightly unhinged, with a manic enthusiasm that rises and falls unpredictably. Tone: Excited, chaotic, and grandiose, as if reveling in the brilliance of a mad experiment. Pronunciation: Sharp and expressive, with elongated vowels, sudden inflections, and an emphasis on big words to sound more diabolical. - (Instructions For Emo teenager character style) Tone: Sarcastic, disinterested, and melancholic, with a hint of passive-aggressiveness. Emotion: Apathy mixed with reluctant engagement. Delivery: Monotone with occasional sighs, drawn-out words, and subtle disdain, evoking a classic emo teenager attitude. - Tool returns URL path to file in format like "C:/Test/speech.mp3" (URL local path).
Descriptions are bloated and poorly structured. generate_speech description is 1100+ characters with embedded instruction examples. LLMs cannot effectively parse this, descriptions should be 50-200 chars explaining WHAT, WHEN, and key constraints. The examples belong in separate documentation or parameter constraints, not the tool description.
voice_id parameter lists allowed values in the description ('alloy, ash, ballad, ...') but does NOT declare them as a JSON Schema enum. This forces LLMs to parse free-text constraints and allows hallucinated voices like 'thunderbolt' to be passed, causing API failures.
Parameter descriptions are minimal or absent. 'prompt_eng' has description 'English language prompt for image generation' (28 chars), acceptable baseline. But 'text', 'voice_id', and 'instructions' lack actionable format/constraint guidance. E.g., instructions has no length limits, content guidelines, or examples of what happens when it's malformed.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 41 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Output schema is not documented. Both tools return raw strings (file paths) with no structured metadata. LLMs cannot know whether the return value is a local path, a URL, or a base64 string without reading the code. The generate_speech code also has a subprocess call to autoplay with MPC-HC, an undocumented side effect that breaks portability.
Error handling is minimal. Both tools raise ValueError with raw API response text (e.g., 'f"{response.status_code}: {response.text}"'). LLMs receive no recovery guidance. Should categorize errors (e.g., 'API rate limited, retry in 30s', 'Invalid prompt, too long or contains prohibited content') and suggest next steps.
generate_speech has a side effect (subprocess.Popen to auto-play audio) that is not declared in the tool description or signature. This violates single responsibility, the tool should generate and return audio, not auto-play it. Side effects should be explicit and configurable.
No input validation at the schema or tool level. The code checks for VSEGPT_API_KEY but does not validate prompt length, text length, or voice_id against the declared enum. LLMs will pass invalid inputs, causing avoidable API errors.
Output is not composable. Both tools return local file paths (e.g., 'C:/Test/image_file.png'). Downstream tools in a multi-tool agent have no way to accept these paths as input, there is no read_image_file or process_audio_file tool defined. The server is incomplete for chaining.