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., "@io.github.Engr-FaizanAli/text-to-speech Read aloud: The deployment completed successfully."
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.
Give your AI assistant a voice — locally, with no API key, no account, and no cloud service.
Text to Speech is an open-source Model Context Protocol (MCP) server that lets AI assistants read text aloud on the user's computer. It uses the speech synthesizer already present on the host operating system, so nothing you ask it to say ever leaves your machine.
Runs on Windows, macOS, and Linux. Install is one line:
uvx text-to-speech-mcpThe server exposes one model-controlled tool:
speak_text(text: string)Use it for user-provided text, assistant answers, accessibility workflows, or spoken progress updates while an agent works.
Most text-to-speech MCP servers wrap a cloud API, which means an account, a key, per-character billing, and your text leaving the machine. This one uses the speech engine your operating system already ships, so it works offline, costs nothing, and keeps text local — which matters if you work anywhere that regulates where data may go.
It also ships an agent narration skill, so an assistant knows how to narrate, not just that it can.
Local playback through the platform's built-in synthesizer by default:
Windows SAPI, macOS say, or espeak-ng on Linux.
No cloud API and no API key for the default setup.
FIFO playback: concurrent requests are spoken one at a time, in order.
Blocking tool completion: each call returns after its audio finishes.
Bounded input and queue sizes to prevent unbounded resource use.
Temporary generated WAV files are removed after playback by default.
Standard MCP stdio transport through the official Python SDK.
Optional Piper, Transformers MMS, and local HTTP backends for advanced users.
The MCP server source is open source under the MIT License. Windows SAPI and the macOS
saycommand are proprietary components of their operating systems; they are not open-source speech engines.espeak-ngis separately licensed open-source software.
Related MCP server: VOICEVOX TTS MCP
Python 3.10 or newer.
An MCP client that supports stdio MCP servers.
uv/uvx is recommended for package-based MCP installation.
Per platform, for the zero-configuration default:
Platform | Synthesis | Playback | Extra install |
Windows 10/11 | SAPI via PowerShell |
| None |
macOS |
|
| None |
Linux / other Unix |
|
|
|
On Debian or Ubuntu that is typically:
sudo apt install espeak-ng alsa-utilsSet TEXT_TO_SPEECH_BACKEND or TEXT_TO_SPEECH_PLAYER to override either
choice. If a required command is missing, the server reports which one and how
to install it rather than failing silently.
Configure an MCP client to run the published PyPI package:
uvx text-to-speech-mcpFor MCP clients that accept command-based server configuration, use:
command = "uvx"
args = ["text-to-speech-mcp"]
startup_timeout_sec = 30
tool_timeout_sec = 300
enabled = trueSome clients use TOML, JSON, or a graphical settings page. Use
uvx text-to-speech-mcp as the server command and restart the client after
changing its configuration.
git clone https://github.com/Engr-FaizanAli/text-to-speech-mcp.git
cd text-to-speech-mcp
python -m pip install .Then configure the client to run text-to-speech-mcp directly.
Read arbitrary text:
Use the Text to Speech tool to read aloud: The deployment completed successfully.Read the final answer:
Use the Text to Speech tool to read your final response aloud before displaying it.Read visible intermediate progress updates in order:
Use the text_to_speech MCP server's speak_text tool for spoken progress updates.
For every meaningful intermediate update that you display to me:
1. Call speak_text with the exact update text you are about to display.
2. Wait for the call to finish before producing or speaking the next update.
3. Then display the same update in text.
Also call speak_text with the exact final answer before displaying it. Never
narrate hidden reasoning, chain-of-thought, secrets, credentials, raw tool
output, terminal logs, or source code unless I explicitly ask you to read that
content aloud. Do not invoke speech calls in parallel. If the tool is
unavailable, continue normally in text and report the failure once.The text_to_speech portion is an example client-side server name. Clients may
display a different namespace while keeping the tool name speak_text.
Field | Value |
Tool name |
|
Input |
|
Result | Completion message after local playback finishes |
Ordering | FIFO, one active playback at a time |
Queue limit | 32 pending requests |
Network use with a built-in backend | None |
The tool is model-controlled under MCP. The user decides when to ask the model to call it, and the MCP client may show or require approval for tool calls.
With any of the built-in backends, text is passed from the MCP client to a local
Python process and then to the operating system's speech components. It is not
sent to this project, an external API, or a cloud TTS provider. Generated WAV
files are written to a text-to-speech-mcp directory inside the system
temporary directory (%TEMP% on Windows, /tmp on macOS and Linux) and
deleted after playback unless TEXT_TO_SPEECH_KEEP_AUDIO=true is set.
The http backend is the exception: whether text leaves the machine depends
entirely on the endpoint you configure.
Do not ask an AI assistant to speak secrets, credentials, private keys, hidden reasoning, or sensitive tool output.
The default requires no configuration. TEXT_TO_SPEECH_BACKEND is unset and the
server selects sapi, say, or espeak to match the host platform.
To pin one explicitly, or to use a backend that is not built into the OS, set
TEXT_TO_SPEECH_BACKEND to sapi, say, espeak, piper,
transformers_mms, or http. The last three require their own local model,
binary, Python dependencies, or endpoint. TEXT_TO_SPEECH_FALLBACK_BACKEND
names a second backend to try if the first fails. See
backend configuration.
A speech tool alone does not tell an assistant when or how to speak. Left to improvise, agents narrate hidden reasoning, skip the parts you actually needed, or read a paraphrase instead of what is on screen.
skills/project-tts-responder/SKILL.md
is a ready-made narration policy built on speak_text. Copy it into your
project's .claude/skills/ directory:
Mode | Behaviour |
Batch (default) | One playback at the end of a turn, covering every visible update plus the final answer |
Streaming | Narrate each update as it appears — good for demos and walkthroughs |
Read on request | Read a named file or block of text verbatim |
It also handles the parts that are easy to get wrong:
Interactive questions are narrated before the picker opens. An interactive question tool is itself the pause, and its options live in the tool's parameters rather than in visible text — so any rule that narrates "once the options are visible" fires only after the user has already answered. This is the most common way narration silently fails.
Speaks exactly what is on screen, never a paraphrase.
Never speaks hidden reasoning, secrets, credentials, or raw tool output.
One playback call per turn, never parallel, with defined behaviour when a call fails.
The skill applies when you ask for audio. To make a project narrate every response, say so in that project's own agent instructions — for example "narrate every response in Batch mode unless I opt out".
MCP transport: stdio
MCP tool implementation: official Python MCP SDK
Registry metadata: server.json using the 2025-12-11 schema
Package registry: PyPI
Registry ownership marker: this README's mcp-name comment
Registry namespace: io.github.Engr-FaizanAli/text-to-speech
MIT. See LICENSE.
Read text aloud locally and return after playback finishes.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to read aloud. Do not include secrets or hidden reasoning. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide hints (readOnlyHint=false, etc.), so the description adds meaningful context by stating the tool operates locally and returns after playback finishes. This discloses timing and execution location beyond what the structured fields convey, though it does not discuss potential failures or platform dependencies.
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 a single, front-loaded sentence that is both concise and information-dense. Every phrase adds value, and there is no fluff or redundancy.
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 tool's low complexity (1 parameter), available annotations, and presence of an output schema, the description covers the essential behavioral contract: it reads text aloud, does so locally, and waits for playback to finish. No additional context is needed for an agent to invoke it correctly.
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 already covers the single parameter with a clear description ('Text to read aloud. Do not include secrets or hidden reasoning.'). The tool description adds no new semantics for the parameter, and with 100% schema coverage, the baseline of 3 is appropriate.
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 uses a specific verb ('Read text aloud') and names the resource ('text'), making the tool's purpose immediately clear. It also adds a distinguishing behavioral detail ('locally', 'return after playback finishes') that fully disambiguates it from any hypothetical alternatives.
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 explains what the tool does but provides no guidance on when to use it versus alternatives or any exclusions. There are no sibling tools, but the description does not explicitly state a canonical use case or context, leaving the agent to infer applicability from the purpose alone.
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.4.1speak_textScored across 1 tool
Only one tool exists, so there is no possibility of confusion between tools. The purpose of speak_text is singular and clear.
The single tool name follows a clear verb_noun pattern ('speak' + 'text'), which is consistent and intuitive. With only one tool, there are no mixed conventions.
The server has exactly one tool, which feels thin for a text-to-speech service. While it covers the core action, users might expect additional tools for voice configuration or listing available options.
The tool provides the fundamental speak action but lacks obvious capabilities like voice selection, speed adjustment, or cancellation. This leaves notable gaps for a complete TTS workflow.
MCP server for Text-to-Speech
AI voice generation: text-to-speech and voice cloning from any MCP client.
MCP server exposing the AceDataCloud Fish Audio API (text-to-speech with voice conditioning)
MCP server for AI dialogue using various LLM models via AceDataCloud