A
licenseB
qualityD
maintenanceA Model Context Protocol server that provides text-to-speech capabilities using the Kokoro TTS model, offering multiple voice options and customizable speech parameters.
4
32
1
MIT
FlowSpeech MCP Server
FlowSpeech MCP Server
An MCP (Model Context Protocol) server that brings FlowSpeech text-to-speech capabilities directly into your LLM workflows.
What is FlowSpeech?
FlowSpeech is a context-aware text-to-speech tool that converts text into human-like audio with:
🎭 Emotion control — stage directions like
***(say cheerfully: Hello!)***⏸️ Pause control — natural pacing and rhythm
🎙️ 30+ voices — male and female voices across moods and styles
🌊 Human-like output — natural-sounding synthesis for creators, educators, and developers
Related MCP server: TTS-MCP
Installation
Run the MCP server directly with npx (no install needed):
npx mcp-flowspeech-serverOr install globally:
npm install -g mcp-flowspeech-serverConfiguration
Add to your MCP client config (e.g. Claude Desktop claude_desktop_config.json):
{
"mcpServers": {
"flowspeech": {
"command": "npx",
"args": ["-y", "mcp-flowspeech-server"],
"env": {
"FLOWSPEECH_OUTPUT_DIR": "~/flowspeech-audio"
}
}
}
}Environment Variables
Variable | Description | Default |
| Directory to save generated audio files |
|
Tools
flowspeech_tts
Convert text to speech with a single voice.
Parameters:
Name | Type | Required | Description |
| string | ✅ | Text to synthesize. Supports emotion stage directions. |
| string | Voice name (default: | |
| string | Custom file path for the output audio |
Example:
Convert this to audio with a cheerful tone using the Puck voice:
"***(say cheerfully: Good morning, everyone!)*** Today we're going to explore something amazing."flowspeech_tts_multi
Convert a two-speaker dialogue to speech.
Parameters:
Name | Type | Required | Description |
| string | ✅ | Dialogue with |
| string | Voice for Speaker1 (default: | |
| string | Voice for Speaker2 (default: | |
| string | Custom file path for the output audio |
Example:
Speaker1: Welcome to the show! I'm your host.
Speaker2: And I'm your co-host. Great to be here!
Speaker1: Today we're talking about AI voices.flowspeech_list_voices
List all available voices.
Parameters:
Name | Type | Description |
|
| Filter by gender (default: |
Available Voices
Voice | Gender | Style |
Puck | Male | Upbeat and playful |
Fenrir | Male | Excitable and energetic |
Zephyr | Female | Bright and cheerful |
Autonoe | Female | Bright and welcoming |
Charon | Male | Informative and narrative |
Kore | Female | Firm and focused |
Orus | Male | Firm and decisive |
Iapetus | Male | Clear and professional |
Umbriel | Male | Easy-going and relaxed |
Callirrhoe | Female | Easy-going and soothing |
Sulafat | Female | Warm and inviting |
Achernar | Female | Soft and tender |
Gacrux | Female | Mature and experienced |
… | … | 30+ total — use |
Emotion Stage Directions
FlowSpeech supports inline emotion control using the format ***(say <style>: text)***:
***(say cheerfully: Good morning!)***
Today I want to talk about something important.
***(say solemnly: This affects all of us.)***Links
🌐 Website: https://flowspeech.io
🎬 Demo: https://youtu.be/nkBI7WbggW8
License
MIT
Available Tools
3 toolsflowspeech_list_voicesA
List all available FlowSpeech voices with their descriptions and gender.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| gender | No | Filter by gender. Default: "all" | all |
TDQS
A3.8/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description is straightforward. It does not disclose any hidden behaviors or side effects; however, for a simple read-only listing tool, the behavior is inferred. Missing details like return format or pagination.
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?
Single concise sentence, front-loaded with purpose. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of a single optional parameter, the description is complete enough. No output schema exists, but listing tools typically return an array; description implies that provides descriptions and gender.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers 100% of parameters with descriptions. The description does not add significant additional meaning beyond what the schema already provides, though it mentions output contains descriptions and gender.
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 all available FlowSpeech voices with descriptions and gender. It distinguishes itself from sibling TTS tools by explicitly focusing on listing.
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?
No explicit guidance on when to use vs alternatives, but the purpose is self-evident. The context of sibling TTS tools implies usage before TTS calls, but no detailed context or when-not-to-use is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
flowspeech_ttsA
Convert text to speech using FlowSpeech — a context-aware TTS engine with emotion control and 30+ voices. Returns the file path of the generated audio.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to convert to speech. Supports emotion stage directions inside ***(say <style>: text)***: e.g. "***(say cheerfully: Hello!)***" | |
| voice | No | Voice name to use. Default: "Kore". Available: Puck, Fenrir, Zephyr, Autonoe, Laomedeia, Sadachbia, Leda, Aoede, Charon, Rasalgethi, Kore, Orus, Alnilam, Erinome, Iapetus, Schedar, Pulcherrima, Sadaltager, Umbriel, Callirrhoe, Achird, Zubenelgenubi, Algieba, Despina, Enceladus, Algenib, Sulafat, Vindemiatrix, Achernar, Gacrux | Kore |
| output_path | No | File path to save audio. Defaults to a timestamped file in ~/.flowspeech-mcp/audio |
TDQS
A3.7/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions the return is a file path and the emotion syntax, but lacks disclosure of safety, authentication needs, or potential side effects (e.g., file creation). Basic functionality is covered.
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?
Two sentences with no wasted words. The first sentence describes the core action and features, the second specifies the output. Very efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no output schema, and moderate complexity, the description covers the main points: what it does, the key feature (emotion control), and the return type. It could be more complete by noting the output format or any prerequisites, but is sufficient.
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?
Schema coverage is 100%, so the baseline is 3. The description adds value by providing an example of the emotion stage directions syntax, which goes beyond the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/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 speech with emotion control and 30+ voices, and returns a file path. However, it does not explicitly differentiate from the sibling tool 'flowspeech_tts_multi', leaving ambiguity about when to use each.
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 usage for text-to-speech with emotion control, but does not provide when-to-use or when-not-to-use guidance relative to the sibling tool. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
flowspeech_tts_multiA
Convert a two-speaker dialogue to speech using FlowSpeech. Assign Speaker1: and Speaker2: prefixes in the text.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Dialogue text with speaker labels. Example: "Speaker1: Good morning! Speaker2: Good morning! How are you?" | |
| voice_a | No | Voice for Speaker1. Default: "Charon" | Charon |
| voice_b | No | Voice for Speaker2. Default: "Kore" | Kore |
| output_path | No | File path to save audio. Defaults to a timestamped file in ~/.flowspeech-mcp/audio |
TDQS
A3.6/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description only mentions prefixes and conversion, omitting details like error handling, rate limits, or return behavior.
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?
Single sentence with clear, front-loaded purpose and no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but the description fails to mention what the tool returns (e.g., saved file path), leaving the agent uncertain of the outcome.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all params with descriptions; the description reinforces the prefix format but adds little new meaning 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 it converts a two-speaker dialogue to speech, specifying the required prefix format, and distinguishes from the sibling flowspeech_tts for single speaker.
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 description implies usage for two-speaker dialogues, contrasting with the single-speaker sibling, but lacks explicit when-not or alternative guidance.
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. Dates show when Glama detected each change.
3 tool updates
v0.1.0- First observed
flowspeech_list_voices - First observed
flowspeech_tts - First observed
flowspeech_tts_multi
TDQS
A3.9/5.0
Disambiguation5/5
Each tool has a clearly distinct purpose: listing voices, single-speaker TTS, and two-speaker TTS. No overlap or ambiguity.
Naming Consistency5/5
All tool names follow a consistent flowspeech_verb_noun pattern using snake_case, with clear and predictable naming.
Tool Count4/5
Three tools is slightly minimal but appropriate for a focused TTS server. The set covers the core functionality without feeling overly sparse.
Completeness4/5
The tool surface covers the essential operations: voice discovery, single-speaker TTS, and dialogue TTS. Minor gaps exist (e.g., no explicit voice selection or emotion control parameters documented), but the core workflow is complete.
Maintenance
ActivityInactive
ResponsivenessNo issues
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
MCP server for Text-to-Speech
MCP server exposing the AceDataCloud Fish Audio API (text-to-speech with voice conditioning)
AI voice generation: text-to-speech and voice cloning from any MCP client.
MCP server for Speech-to-Text
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceA Model Context Protocol server that integrates high-quality text-to-speech capabilities with Claude Desktop and other MCP-compatible clients, supporting multiple voice options and audio formats.171MIT
- AlicenseAqualityDmaintenanceA Model Context Protocol server that enables AI models to generate and play high-quality text-to-speech audio through your device's native audio system using Rime's voice synthesis API.18127-
ElevenLabs MCP Serverofficial
AlicenseAqualityFmaintenanceAn official Model Context Protocol (MCP) server that enables AI clients to interact with ElevenLabs' Text to Speech and audio processing APIs, allowing for speech generation, voice cloning, audio transcription, and other audio-related tasks.271,536MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/waeckerlinfederowicz66-sketch/mcp-flowspeech-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server