Loading ToolBench
MCP server for generating Voiceroid explanation scenarios for Exia
This server has significant structural issues. All 4 tools are explicitly registered in src/server.ts with Zod schemas and descriptions. However, parameter descriptions are either absent or minimal, input/output schemas are incomplete, and error handling lacks recovery guidance. The tool set exhibits poor composition, exiaVoiceroidExplain duplicates logic from three other tools (generateScenario, setupExia, saveScenario), violating the single-responsibility principle. Three tools (setupExia, saveScenario, exiaVoiceroidExplain) are mutually dependent but lack documented prerequisites. Error messages are vague ('シナリオの生成に失敗しました: [object Object]') and do not guide the LLM toward recovery. Output schemas are not documented, the LLM cannot predict what generateScenario returns, forcing guesswork. Naming is reasonable (all tools start with verbs), but parameter 'topic' has no type annotation in descriptions and the schema shows only JSON types without semantic constraints.
All-in-one tool that generates a scenario, sets up exia if needed, saves the scenario, and launches the exia application
Generate a Voiceroid explanation scenario for a given topic
Generate a scenario and save it to exia's scenario directory
Setup exia by cloning the repository and installing dependencies
All tool descriptions are extremely brief (10-30 chars) and lack actionable context for LLM selection. 'Generate a Voiceroid explanation scenario for a given topic' does not explain when to call this vs saveScenario, what format the output is in, or whether it persists state.
Parameter 'topic' lacks description in all four tools. The Zod schema declares z.string() but provides no semantic guidance: Is 'topic' a single word, a phrase, or a full prompt? Are there length/content constraints? What happens if topic is empty or contains special characters?
Output schemas are not documented. generateScenario and saveScenario return {content: [{type: 'text', text: string}], isError?: boolean} but this is inferred from code, not declared. The LLM cannot plan downstream operations without knowing the response structure.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 39 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 40 | - | v1 |
Composition violation: exiaVoiceroidExplain duplicates 100% of the logic from generateScenario, setupExia, and saveScenario. The LLM cannot reason about which to call, it must guess whether to compose three tools or invoke one mega-tool. This violates single-responsibility and forces the LLM to reason about hidden ordering constraints.
Error handling is non-actionable. When scenario generation fails, the response is 'シナリオの生成に失敗しました: [object Object]'. The LLM receives no guidance on whether to retry, ask the user, or try a different tool. Error messages do not include the invalid value or the constraint violated.
setupExia has no parameters and no description of prerequisites. If called when exia is already set up, does it fail? Reinstall? Skip? The LLM cannot reason about idempotency or whether it is safe to call unconditionally.
No confirmation step for irreversible operations. exiaVoiceroidExplain is marked IRREVERSIBLE and launches an Electron application, modifying the filesystem and starting a subprocess. The LLM can invoke this accidentally. No dry-run, no confirmation mechanism.
Dependencies between tools are undocumented. saveScenario and exiaVoiceroidExplain depend on setupExia being called first (or exiaManager.checkSetup() succeeding), but this constraint is not stated in descriptions. An LLM might call saveScenario before setupExia, causing a silent failure.
No semantic constraints on 'topic' parameter. The LLM can pass empty strings, extremely long strings, or special characters without validation guidance. Descriptions should specify length, character constraints, and examples of valid topics.