Converts text into speech using OpenAI's TTS API to provide voice status updates.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@voice-status-report-mcp-server report progress on the data analysis"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that provides voice status updates using OpenAI's text-to-speech API. This allows language models to communicate with users through short voice messages: reporting on the progress of a task, or confirming that a command has been executed. It's espesially useful when working with Cursor or Claude code: you can give the agent a task, go on to do something else but keep receiving status reports on agent's progess and when it's done with its task and needs your attention.
This MCP server is meant to be batteries included: the description of the summarize tool (prepended to system message by most MCP clients) asks the model to use this tool to report on the progress of a task.
The server exposes the following tool:
summarize(text: str): Converts the provided text into speech using OpenAI's TTS API and plays it to the user. This is useful for providing status updates or confirmations after code changes or commands.
Related MCP server: Yak MCP
You'll need an OpenAI API key to use this server.
Update your claude_desktop_config.json (located in ~/Library/Application\ Support/Claude/claude_desktop_config.json on macOS and %APPDATA%/Claude/claude_desktop_config.json on Windows) to include the following:
{
"mcpServers": {
"voice-status-report": {
"command": "uvx",
"args": [
"voice-status-report-mcp-server"
],
"env": {
"OPENAI_API_KEY": "YOUR_OPENAI_API_KEY"
}
}
}
}The server accepts the following command line options:
--ding: Enable the ding sound that plays before each voice message. By default, the ding sound is disabled.
--voice [VOICE]: Choose the voice for speech generation. Available options: alloy, ash, coral (default), echo, fable, onyx, nova, sage, shimmer.
--speed SPEED: Set the speech speed (0.5-4.0, where higher is faster). Default is 4.0.
--instructions TEXT: Provide custom voice instructions for the TTS model. By default, the server uses a preset instruction for a calm, friendly voice.
# Run with ding sound enabled and a different voice
voice-status-report-mcp-server --ding --voice nova
# Run with a slower speech speed
voice-status-report-mcp-server --speed 2.0
# Run with custom voice instructions
voice-status-report-mcp-server --instructions "Voice should be confident and authoritative"{
"mcpServers": {
"voice-status-calm": {
"command": "uvx",
"args": [
"voice-status-report-mcp-server",
],
"env": {
"OPENAI_API_KEY": "YOUR_OPENAI_API_KEY"
}
},
}
}When using non-default arguments, you can use the following configuration:
{
"mcpServers": {
"voice-status-report-mcp-server": {
"command": "uvx",
"args": [
"voice-status-report-mcp-server",
"--ding",
"--voice", "nova",
"--speed", "3.0",
"--instructions", "Voice should be confident and authoritative"
],
"env": {
"OPENAI_API_KEY": "YOUR_OPENAI_API_KEY"
}
}
}
}Once connected, Claude can use the tool to provide audio feedback like:
"Added a new function to handle user authentication"
"Fixed the bug in the login form"
"Created a new file for the API client"
"Added OpenAI TTS documentation link"
This project is licensed under the MIT License - see the LICENSE file for details.
Use this to send a short audio message to the user concisely (one 10-15 word sentence) summarizing what you've done and why. Use this tool after every time you generated a code snippet or ran a command as well as when you give control back to the user.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions 'send a short audio message' but the input schema only expects a text parameter, creating potential confusion. The description says the message should be one 10-15 word sentence, but does not explain how the audio is generated or any limitations. Lacks details about side effects or format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: one defining the action and one specifying usage. It is succinct and front-loaded with purpose. However, it could be slightly restructured to separate the 'what' from the 'when' more clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and parameter descriptions, the description needs to cover all behavioral aspects. It covers purpose and usage well, but omits important details like what happens after sending the message, whether the text length is validated, and the format of the audio output. As a result, the agent may have unanswered questions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter 'text' with no description (0% coverage). The description implies that 'text' should be a concise sentence, but it does not explicitly link the parameter to the audio message content. The mention of 'audio message' in the description is not reflected in the schema, potentially confusing the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: sending a short audio message summarizing what was done and why. It specifies the exact verb 'summarize' and provides a clear resource. Although no sibling tools exist for comparison, the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: after every code snippet generation or command execution, and when handing control back to the user. This is highly directive and leaves no ambiguity about usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.3summarizeScored across 1 tool
Only one tool exists, so there is no risk of confusion between tools.
With a single tool, naming is trivially consistent.
A single tool is thin for a typical MCP server, but it may be appropriate if the server's scope is limited to providing a summary.
The tool covers the stated purpose of summarizing actions, but lacks additional voice-related functionality that might be expected (e.g., full report creation or audio control).
Calls your phone when an AI task finishes or is blocked — hear it, say what's next.
AI voice generation: text-to-speech and voice cloning from any MCP client.
Text to speech for your AI. Your AI can send text to Doc Player to read it aloud. You will see a reader window with the text and you can control the playback sentence by sentence. Find an example here: https://documentplayer.com/connect-ai/
Speech, transcription, voice agents, Trace, Recap, dubbing and narration with browser OAuth.
