Loading ToolBench
Azure Speech MCP Server — compatible with Copilot CLI, Claude Code, and Gemini CLI. Provides 'listen' (STT), 'speak' (TTS), 'talk' (full-duplex), and 'converse' tools so AI assistants can have voice conversations.
This server demonstrates strong tool design with clear, descriptive naming and well-documented parameters. All 10 tools have meaningful descriptions exceeding the 20-character minimum. Input schemas are present and properly typed for all tools. However, there are notable gaps: (1) output schemas are not documented, the server does not specify what fields tools return, making it difficult for LLMs to plan downstream actions or extract data; (2) no error handling guidance, tools do not indicate what errors are possible, how they should be handled, or what recovery actions are available; (3) some parameter descriptions lack format/constraint details. The tool composition is sound (each tool does one thing), and naming follows verb_noun convention. Overall, this is a well-above-average server that would benefit from documented return schemas and error recovery patterns.
Cancel an active listen, speak, talk, or converse operation. Returns immediately; the active tool finishes gracefully within ~100ms.
Listen to the user through their microphone and return what they said as text. Use this to START a voice conversation. After getting the user's words, respond with 'speak' (to say something) then 'converse' again (to listen for their reply). This speak→converse loop lets you call other tools between turns — research, edit files, query APIs — then speak results and listen for the next instruction. Use 'talk' only when you need a fast atomic speak+listen with no tools in between.
List available Azure Speech voices for the current region.
Listen through the microphone and return what the user said as text. Stops automatically when the user finishes speaking. This is listen-only — if you also need to speak, use 'talk' instead.
Speak multiple text segments with different voices in one call. Azure TTS requests are fired in parallel for speed, then audio plays back-to-back. Use this for multi-agent conversations to avoid multiple round trips.
No documented output schemas for any tool. LLMs cannot plan what data they will receive, forcing them to guess about return fields and structure. This violates the response-shaper pattern and makes composition fragile.
No error handling guidance. Tools do not indicate what errors are possible, whether they are retryable, or how the LLM should recover. For example, 'listen' could timeout, fail due to microphone unavailability, or encounter STT service errors, none of these scenarios are documented.
Parameter descriptions lack actionable format constraints. For example, 'silence_timeout' and 'energy_multiplier' have type and range info, but descriptions do not explain what happens if these values are at extremes or how to tune them for different environments.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 64 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 23 | - | v1 |
Stream multi-voice TTS in a SINGLE Azure request using SSML multi-voice tags. MUCH FASTER than multi_speak — one API call instead of N calls. Ideal for multi_chat responses: each model's response plays with its own voice, switching seamlessly within a single audio stream. Voice assignments by family: OpenAI (gpt-5.x, o1, o4)→DavisNeural, Claude→AvaNeural, Llama→AndrewNeural, DeepSeek→BrianNeural, Grok→GuyNeural, Gemini→AriaNeural, Cohere→JennyNeural, Phi/Mistral→EmmaNeural, Nova→JasonNeural, DO OSS→TonyNeural, Puter→SaraNeural.
Pause the active TTS playback (speak, talk, multi_speak, multi_speak_stream, converse, or listen background hum). The microphone stays open. Resume with the 'resume' tool, or let it auto-resume after 30 seconds.
Resume the paused TTS playback from where it left off.
Say something out loud (text-to-speech) WITHOUT listening for a reply. Use this for one-way announcements or final messages. If you want to speak AND hear the user's response, use 'talk' instead.
Speak and listen in one atomic operation (full-duplex). Say something and immediately start listening for the user's response, with no delay between them. The microphone opens as soon as TTS starts, so the response is captured while your message is still playing (or just after). Use this for natural back-and-forth when you don't need to call other tools between your message and their reply. If you need to process, research, or call tools between speaking and listening, use the speak→converse loop instead.
'get_voices' and 'cancel' have minimal descriptions (70 - 75 chars). While non-critical, they are below the 194-char average for A+ tools and lack context about when to call them or what data they reveal.
'pause' and 'resume' descriptions do not explicitly state that pause applies to TTS playback, not recording. This could confuse LLMs about whether the microphone stays open during pause.