Which integrations are available for this server?

Provides text-to-speech synthesis using Google Translate's TTS endpoint, supporting multiple languages and accents.

How do I use text-to-speech?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@text-to-speech convert 'Hello, how are you?' to speech with a British accent" 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.

text-to-speech

by ahamed-kashif

Overview Schema Source Related Servers Discussions Admin

Local

Text-to-Speech MCP Server

An MCP server that exposes a text-to-speech tool, powered by the free, no-API-key gTTS library (which wraps Google Translate's internal TTS endpoint).

Free — no API key, no billing, no GCP account.
Many languages — English, Bengali, Spanish, and ~60 more.
File output — saves an MP3 and returns its path.
Resilient — retries transient/rate-limit failures with exponential backoff.

Note: gTTS uses an undocumented Google endpoint. It requires internet access and can rate-limit or change without notice — great for personal/internal use, less suited to high-volume production. The engine is isolated in engine.py so it can be swapped for Google Cloud TTS or an offline engine later.

Requirements

uv
Python 3.12 (uv will provision it)

Related MCP server: mcp-tts-server

Setup

uv sync

This creates .venv/ and installs the project (and its deps: gtts, mcp).

Optional configuration — copy .env.example to .env and edit:

Variable	Default	Meaning
`TTS_OUTPUT_DIR`	`./output`	Where MP3s are written when no `output_path` is given
`TTS_MAX_RETRIES`	`3`	Max synthesis attempts before failing
`TTS_RETRY_BACKOFF`	`1.0`	Base backoff seconds (1s, 2s, 4s, …)
`TTS_DEFAULT_LANG`	`en`	Default language code
`TTS_DEFAULT_ACCENT`	`com`	Default accent TLD

Run

uv run tts-server
# or
uv run python -m tts_server.server

The server speaks MCP over stdio.

Tools

`text_to_speech`

Arg	Type	Default	Description
`text`	string	— (required)	Text to speak
`language`	string	`en`	Language code (`en`, `bn`, `es`, …)
`slow`	boolean	`false`	Speak more slowly
`accent`	string	`com`	Accent TLD: `com` (US), `co.uk` (UK), `com.au` (AU), `co.in` (India)
`output_path`	string	auto	Output MP3 path; auto-generated under `TTS_OUTPUT_DIR` if omitted

Returns: Saved <N> KB MP3 to <path>, or Error: <reason>.

`list_languages`

No arguments. Returns supported code: name pairs.

Install in an MCP client

This is a standard stdio MCP server, so it works with any MCP-compatible client (Claude Code, Claude Desktop, Cursor, Windsurf, Continue, etc.). Every client needs the same three things:

Field	Value
command	`uv`
args	`["--directory", "<ABS_PROJECT_PATH>", "run", "tts-server"]`
env (optional)	e.g. `{ "TTS_OUTPUT_DIR": "<ABS_OUTPUT_PATH>" }`

Replace <ABS_PROJECT_PATH> with the absolute path to this project. Using uv --directory <path> run means the client can launch the server from anywhere and still resolve the right virtual env and .env. Make sure uv is on the client's PATH (or use the absolute path to the uv binary — find it with which uv).

Claude Code (CLI)

# user scope = available in every project; use --scope project for just this repo
claude mcp add text-to-speech --scope user -- \
  uv --directory /abs/path/to/text-to-speech-agent run tts-server

Verify, inspect, or remove:

claude mcp list                 # health check
claude mcp get text-to-speech   # show config
claude mcp remove text-to-speech

Tools load when a session starts, so open a new session after adding.

Claude Desktop

Edit the config file (Settings → Developer → Edit Config, or directly):

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json

Add (see claude_desktop_config.example.json):

{
  "mcpServers": {
    "text-to-speech": {
      "command": "uv",
      "args": ["--directory", "/abs/path/to/text-to-speech-agent", "run", "tts-server"],
      "env": { "TTS_OUTPUT_DIR": "/abs/path/to/text-to-speech-agent/output" }
    }
  }
}

Then fully restart Claude Desktop.

Cursor / Windsurf / other JSON-config clients

These use the same mcpServers JSON shape as Claude Desktop. Add the block above to the client's MCP config (e.g. Cursor: Settings → MCP, or ~/.cursor/mcp.json), then reload the client.

Generic stdio client

Any client that can launch a stdio server: configure it to run

uv --directory /abs/path/to/text-to-speech-agent run tts-server

and (optionally) pass environment variables from the table in Setup.

Troubleshooting

Server fails to start / "uv not found" — use the absolute path to uv (which uv) as the command, since GUI clients often don't inherit your shell PATH.
Tools don't appear — restart the client (Claude Code: start a new session).
MP3s land in the wrong place — set TTS_OUTPUT_DIR in the client's env block (it overrides .env).
Synthesis errors — gTTS needs internet and may rate-limit; the server retries automatically, but check connectivity if it persists.

Project layout

src/tts_server/
  server.py   # MCP tools, validation, response shaping
  engine.py   # gTTS wrapper + retry/backoff (only file importing gTTS)
  config.py   # env-driven settings
  utils.py    # filename gen, language validation, file sizing
tests/        # unit tests (retry paths, mocked gTTS)
output/       # generated MP3s

Tests

uv run python -m pytest -q

Available Tools

2 tools

list_languagesA

List the language codes and names supported for text_to_speech.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that it lists supported codes and names, but does not disclose any behavioral traits such as authentication needs, rate limits, or idempotency. For a simple read-only list, the description is adequate but lacks depth.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that is front-loaded and contains no wasted words. Every word is necessary.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero parameters and the existence of an output schema, the description is complete enough for an agent to understand and use the tool correctly. The sibling tool name provides context for when to call this tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are 0 parameters, and schema coverage is 100%. The description adds meaning by specifying that the output includes language codes and names, which is not evident from the empty schema. This provides useful context beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists language codes and names for text_to_speech. It uses a specific verb (list) and resource, and distinguishes from the sibling tool text_to_speech which performs speech synthesis.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is used to get supported languages before using text_to_speech, but it does not explicitly state when to use it or provide alternatives or exclusions. The context signals include a sibling tool name, which hints at the connection, but no explicit guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

text_to_speechA

Convert text into spoken audio (MP3) using Google TTS (gTTS).

Args:
    text: The text to speak. Required, must be non-empty.
    language: Language code such as "en", "bn", "es". Defaults to "en".
    slow: Speak more slowly when True.
    accent: Google domain TLD controlling accent for some languages,
        e.g. "com" (US), "co.uk" (UK), "com.au" (AU), "co.in" (India).
    output_path: Where to write the MP3. If omitted, a timestamped file
        is created under the configured output directory.

Returns:
    A human-readable status string including the saved file path, or an
    "Error: ..." message describing what went wrong.

ParametersJSON Schema

Name	Required	Default
`slow`	No
`text`	Yes
`accent`	No	com
`language`	No	en
`output_path`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry the burden. It explains the conversion process, parameter effects, and return format. However, it omits details like network dependencies, file overwriting behavior, or authentication needs, which are relevant for a tool using an external service.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with a clear lead sentence, followed by well-organized Args and Returns sections. Every sentence adds value with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (5 parameters, no schema descriptions, no annotations), the description covers all parameters and the return value comprehensively. The presence of an output schema is noted, and the description aligns with it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description compensates fully by explaining each parameter (required, defaults, examples, behavior). It adds significant meaning beyond the bare schema types and names.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool converts text to spoken audio (MP3) using gTTS, with a specific verb ('Convert') and resource ('text into spoken audio'). It distinguishes from the sibling tool 'list_languages' by its action and output format.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The context of siblings (list_languages) implies this tool is for speech generation, not language listing. However, no explicit when-to-use or when-not-to-use guidance is provided, leaving some ambiguity.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

2 tool updatesv0.1.0Jul 7, 2026
- First observedlist_languages
- First observedtext_to_speech

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.2/5.0

Scored 2026-07-07 11:45 across 2 tools

Disambiguation5/5

The two tools have clearly distinct purposes: one lists supported languages, and the other converts text to speech. There is no overlap or ambiguity.

Naming Consistency5/5

Both tools follow a consistent verb_noun pattern (list_languages, text_to_speech), making the naming predictable and intuitive.

Tool Count3/5

With only two tools, the server is quite thin but still covers the core functionality for a simple text-to-speech service. The count is borderline for the domain.

Completeness4/5

The domain is well-covered by listing languages and converting text to speech with various options. No major gaps are apparent, though additional settings tools could be added.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Texttospeech Mcp C
io.github.varvararatta
MCP server for Text-to-Speech
Text-to-Speech Speech Processing Audio Processing
2
Document Player AOAuth
com.documentplayer
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/
Education & Learning Tools Text-to-Speech Workplace & Productivity
11
tts A
com.brainiall
Hosted pay-per-use TTS: 54 neural voices, 9 languages incl. Brazilian Portuguese. $10 free credits.
Text-to-Speech Audio Processing
2
VoiceLabsOAuth
now.voicelabs
AI voice generation: text-to-speech and voice cloning from any MCP client.
Text-to-Speech Speech Processing Audio Processing
1

Related MCP Servers

MCP Audio Server
Text-to-Speech Audio Processing Multimedia Processing
BatchLion
A
license
Not graded
quality
D
maintenance
Enables text-to-speech conversion with smart language detection (using Google TTS for Chinese) and audio file playback with playback controls for Claude Desktop.
Updated a year ago (2025-07-11 11:28 UTC)
2
MIT
mcp-tts-server
Text-to-Speech Audio Processing AI & Machine Learning
kaichen
A
license
Not graded
quality
C
maintenance
Enables text-to-speech generation using the Groq API, supporting multiple audio formats and optional local playback.
Updated a year ago (2025-03-30 06:33 UTC)
20 npm
1
MIT
TTS MCP Server
Text-to-Speech Speech Processing
activebook
A
license
Not graded
quality
D
maintenance
Provides Text-to-Speech (TTS) functionality using Google TTS API, enabling audio generation, voice listing, and style templates via MCP.
Updated a year ago (2025-09-05 05:54 UTC)
20 npm
1
MIT
yuppie-mcp-tts
Text-to-Speech Speech Processing
yuppie1949
A
license
A
quality
B
maintenance
Provides text-to-speech synthesis using Microsoft Edge's free TTS engine, supporting multiple voices, languages, and audio output options (base64 or file).
Updated 22 days ago (2026-08-29 06:08 UTC)
3
MIT

Text-to-Speech MCP Server

Requirements

Setup

Run

Tools

text_to_speech

list_languages

Install in an MCP client

Claude Code (CLI)

Claude Desktop

Cursor / Windsurf / other JSON-config clients

Generic stdio client

Troubleshooting

Project layout

Tests

Available Tools

Output Schema

TDQS

Output Schema

TDQS

Tool Schema Changelog

TDQS

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

MCP Audio Server

mcp-tts-server

TTS MCP Server

yuppie-mcp-tts

`text_to_speech`

`list_languages`