Loading ToolBench
Text-to-Speech MCP server that announces task completion via audio notifications using edge-tts or native system TTS
The speakout MCP server exposes a single tool (announce_completion) with mixed quality. The tool has a detailed description and well-structured parameters with proper type definitions and enum constraints. However, the tool represents a narrow, specialized use case, announcing task completion via TTS, rather than a general-purpose utility. The parameter descriptions are adequate but somewhat verbose. The schema includes proper types and defaults. The fundamental issue is that this tool is designed to enforce a specific behavior pattern (mandatory calls after every task) on the LLM, which is an anti-pattern for tool design. The tool's purpose is more about agent orchestration/enforcement than exposing a capability. This limits its usefulness in a production agent toolkit.
Announce task completion via Text-to-Speech. IMPORTANT: You MUST call this tool every time you finish a task requested by the user. This includes completing code changes, answering questions, running commands, fixing bugs, or any other user request.
Tool enforces mandatory calling pattern rather than exposing a composable capability. The description includes 'IMPORTANT: You MUST call this tool every time...' which attempts to mandate LLM behavior through tool definitions. This is an anti-pattern, tools should expose capabilities; orchestration should be handled by system prompts or agent design, not tool descriptions.
Tool name 'announce_completion' uses a gerund (announce) rather than imperative verb (announce). Naming should be verb_noun (e.g., 'notify_completion', 'speak_message', 'announce_with_tts'). Current name is ambiguous about the primary action.
Parameter 'instance_name' with description 'Instance name for voice selection (default: 'default')' lacks clarity about what 'instance' means in this context. Is this a project name? A server instance? An agent name? The description should explain the semantic purpose.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 11 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 51 | - | v1 |
Output schema not documented. The function returns a string (either SUCCESS_HINT or error message text), but the tool definition provides no formal output schema. LLMs cannot plan follow-up actions without knowing the expected response structure.
Error handling returns free-text strings without structured error classification. When audio playback fails, the response is 'Audio notification failed. Please reply with a text summary...' This is not a recovery guide, it's a fallback instruction. Errors should categorize failures (retryable vs. fatal) and suggest corrective actions.