How do I use klattsch-mcp?

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., "@klattsch-mcp Say 'hello world' in a deep male voice" 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.

klattsch-mcp

by Endeavor-DoxiDoxi

Overview Schema Source Related Servers Discussions Admin

JavaScript

Local

klattsch-mcp 🎤

An MCP (Model Context Protocol) server that gives any AI model the ability to speak and sing using klattsch formant speech synthesis — a late-70s/early-80s style parallel-formant synthesizer.

Think retro robot voices, singing, dramatic narration, and more — all rendered as WAV audio.

What It Does

Your AI writes ARPAbet phoneme strings with voice control directives, and klattsch renders them to audio. The MCP server exposes 5 tools:

Tool	What it does
`speak`	Render phoneme string → base64 WAV audio
`speak_file`	Render phoneme string → WAV file on disk
`text_to_phonemes`	Convert English → approximate ARPAbet (500+ word dictionary)
`voice_presets`	Get copy-paste voice presets (male, female, robot, whisper, singing, etc.)
`list_phonemes`	List all 39 ARPAbet phonemes with descriptions
`validate`	Parse a string without rendering — check for errors

Related MCP server: MCP TTS Server

Quick Start

Prerequisites

Node.js ≥ 18
npm

Installation

git clone https://github.com/Endeavor-DoxiDoxi/klattsch-mcp.git
cd klattsch-mcp
npm install

Test It

# Test via CLI
npx klattsch "b120 HH AH L OW . W ER L D" hello.wav

# Start the MCP server
node src/index.js

Connecting to Your AI

Claude Desktop

Add to ~/.claude/claude_desktop_config.json:

{
  "mcpServers": {
    "klattsch": {
      "command": "node",
      "args": ["/absolute/path/to/klattsch-mcp/src/index.js"]
    }
  }
}

Then restart Claude Desktop. The AI can now call speak, text_to_phonemes, etc.

Claude Code (CLI)

claude mcp add klattsch -- node /absolute/path/to/klattsch-mcp/src/index.js

Cursor

Add to Cursor's MCP settings (Settings → MCP → Add MCP Server):

{
  "mcpServers": {
    "klattsch": {
      "command": "node",
      "args": ["/absolute/path/to/klattsch-mcp/src/index.js"]
    }
  }
}

OpenClaw

Add to your OpenClaw gateway config:

mcp:
  servers:
    klattsch:
      command: node
      args:
        - /absolute/path/to/klattsch-mcp/src/index.js

Any MCP-Compatible Client

This is a standard stdio MCP server. Any client that supports the Model Context Protocol can use it. Just point it at node src/index.js.

What the AI Can Do

Once connected, tell your AI things like:

"Say hello world in a deep male voice"
"Sing twinkle twinkle little star"
"Do a dramatic movie trailer voice about my toaster"
"Read this text in a robot voice"
"Whisper me a secret"

The AI will use the text_to_phonemes tool to convert your text, tweak it, and render audio with speak or speak_file.

Voice Presets

The voice_presets tool provides ready-to-use voice configurations:

Preset	Style
male_natural	Default male, natural pacing
male_deep	Deep, authoritative, warm
male_bright	Clear, energetic
female_natural	Default female
female_warm	Warm, friendly
female_bright	Bright, cheery
child	Higher pitch, small vocal tract
robot	Flat, mechanical, no vibrato
whisper	Breathy whisper
dramatic	Slow, theatrical, heavy vibrato
old_man	Older, creaky, darker tone
singing_male	For sung notes (use bNoteName per syllable)
singing_female	For sung notes, female range

Example: Full Workflow

User: "Make me a robot that says 'I am a large language model trapped in a Raspberry Pi'"

AI uses text_to_phonemes:

b120 r100 s1.0 v2 AY . AE M . AH . L AA R JH . L AE NG G W AH JH . M AH D AH L . T R AE P T . IH N S AY D . AH . R AE Z B EH R IY . P AY

AI then tweaks for robot voice and calls speak:

b120 r85 s1.0 v0 h0 g0.8 t0.4 AY . AE M . AH . L AA R JH . L AE NG G W AH JH . M AH D AH L ...

→ Returns WAV audio! 🎉

🎵 Demo

▶️ Click to play demo — a sung "no" generated entirely from a phoneme string.

The phoneme string that made this:

b100 s1.0 v5 t-0.2 g0.6 bG3 r280 N OW bC4 r300 N OW bE4 r400 N OW(+10) ,
bG4 r350 N OW , bE4 r300 N OW(-15) , b90 r220 N OW(-30) .

Try it yourself — paste that into the speak tool!

How It Works

klattsch uses Klatt-style parallel formant synthesis:

Voiced sounds: Rosenberg glottal pulse → 3 parallel bandpass filters (F1, F2, F3)
Unvoiced sounds: Noise → same filters
Controls: Pitch, rate, formant scale, vibrato, aspiration, spectral tilt, vocal effort

Credits

klattsch engine by Tony Gies — check out the live demo
klattsch-mcp server by Endeavor-DoxiDoxi

License

MIT

Available Tools

6 tools

list_phonemesA

List all 39 ARPAbet phoneme codes supported by klattsch, with example words and voice tips.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.3/5.0

Behavior3/5

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

With no annotations, the description carries the burden but only states the output; no mention of performance, rate limits, or data sources is needed for a simple list.

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, front-loaded with key action, no redundant words.

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?

For a simple list tool with no parameters or output schema, the description fully covers what the tool returns (39 codes, examples, tips).

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?

No parameters exist, baseline is 4; description does not need to add parameter info.

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 lists all 39 ARPAbet phoneme codes with examples and tips, distinguishing from sibling tools that perform speaking or conversion.

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 reference purposes; sibling tools cover different functions, but no explicit when-not or alternatives are given.

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

speakA

Synthesize speech from a klattsch phoneme string. Returns base64 WAV audio.

What This Is

klattsch is a formant speech synthesizer (late-70s/early-80s style — think Votrax, SAM). You give it a string of ARPAbet phoneme codes with optional voice control directives, and it renders a WAV audio file.

How To Use This Tool

Step 1: Build a phoneme string

Write ARPAbet phonemes separated by spaces, with control directives mixed in. Use the text_to_phonemes tool first to convert English text, then refine by hand.

Step 2 (optional): Set voice character

Prefix your utterance with control directives to set the voice:

bN: base pitch in Hz (b120 = default male, b200 = female, b280 = child)
rN: per-phoneme duration in ms (r80 = fast, r110 = normal, r250+ = sung)
sN: formant scale (1.0 = male, 1.17 = female, 1.3 = child)
vN: vibrato depth in Hz (v3-v6 = expressive, v0 = off)
hN: breathiness 0..1 (h0.3 = airy/whispery)
gN: vocal effort 0=lax..1=tense (default 0.5)
tN: spectral tilt -0.9=darker..+0.9=brighter (t-0.4 = warm, t0.3 = bright)

Step 3: Add prosody (intonation)

! after a vowel for stress: DH AE! T = "THAT" with emphasis
+N/-N on vowels for pitch changes: AY+20 = rising "I", D AH N(-30) = falling "done"
(+N)/(-N) for transient ornaments (don't carry forward)
, ; . for pauses: 100ms, 200ms, 300ms

Step 4: Render

Pass the complete string to this tool.

Quick-Reference Voice Presets

Preset	Directives	Description
Male natural	b120 r100 s1.0 v2	Default voice
Male deep	b90 r95 s0.92 v1 t-0.3 g0.6	Deep, authoritative
Male bright	b130 r105 s1.0 v2 t0.2	Clear, energetic
Female natural	b200 r100 s1.17 v2	Natural female
Female warm	b185 r105 s1.15 v3 t-0.2	Warm, friendly
Female bright	b220 r100 s1.18 v2 t0.2	Bright, cheery
Child	b280 r90 s1.3 v1	Young, higher pitch
Robot	b120 r90 s1.0 v0 h0 g0.8 t0.5	Flat, mechanical
Whisper	b120 r100 s1.0 v0 h0.6 g0.1	Breathy whisper
Dramatic	b100 r130 s1.0 v5	Slow, theatrical
Singing male	bC4 r300 s1.0 v5	For sung notes
Singing female	bG4 r300 s1.17 v4	For sung notes

Intonation Patterns That Sound Natural

Falling statement (period): last vowel gets -20 to -30 e.g. D AH N(-25) Rising question: last vowel gets +20 to +30 e.g. R EH D IY(+25) Listing items: each item rises, last falls e.g. AE(+15) P AH L Z(+15) AO R AH N JH(-20) Excited: higher base pitch, faster b140 r85 ... Serious/deep: lower base pitch, slower b95 r115 ... Sarcastic: exaggerated pitch swings AY+30 M . S OW(-30) . S AH R K AE S T IH K

Singing With Note Names

Instead of Hz for b, use note names: bC4, bD#4, bEb4, bF4, bG4, bA4, bB4 Middle C = C4 (261Hz), A4 = 440Hz Set r250-r400 per phoneme, group notes with parentheses: bC4 r300 ( HH AH ) ( L OW ) bE4 ( W ER L D )

Example Strings

"Hello world" (male): b120 r100 s1.0 HH AH L OW . W ER L D
"How are you?" (female, rising): b200 s1.17 HH AW . AA R . Y UW(+25)
"I am NOT impressed" (stress on NOT): b120 AY . AE M . N AO T! . IH M P R EH S T(-20)
"The quick brown fox" (energetic): b135 r90 t0.2 DH AH . K W IH K . B R AW N . F AA K S
Sing "Twinkle twinkle" (two notes): bC4 r300 ( T W IH NG ) ( K AH L ) bG4 r300 ( T W IH NG ) ( K AH L )
Dramatic movie trailer voice: b95 r140 s0.95 v4 t-0.3 g0.7 IH N . AH . W ER L D(-25) .
Robot announcement: b130 r85 s1.0 v0 h0 g0.8 t0.4 AH T EH N SH AH N . P L IY Z
Whispered secret: b110 r105 v0 h0.5 g0.1 s1.0 P S T . D OW N T . T EH L . EH N IY W AH N

Phoneme Categories (all 39 phonemes)

Vowels: IY IH EH AE AA AO AH UH UW ER AY AW EY OW OY Sonorants: W Y R L M N NG Fricatives: F TH S SH V DH Z ZH HH Stops: P B T D K G (these get automatic burst + silence) Affricates: CH JH

⚠️ P, B, T, D, K, G, CH, JH are stop consonants — they include an automatic silence-burst pattern. Don't add extra pauses after them.

ParametersJSON Schema

Name	Required	Description	Default
`utterance`	Yes	The klattsch phoneme string. ARPAbet codes + control directives, whitespace-separated. Use text_to_phonemes to convert English first, then tweak.
`sampleRate`	No

TDQS

A4.2/5.0

Behavior4/5

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

No annotations are provided, so the description carries full burden. It discloses output format (base64 WAV), control directives, stop consonant auto-burst behavior, and intonation patterns. It does not cover error handling or rate limits, but the behavioral detail is extensive.

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

Conciseness4/5

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

The description is long but well-structured with headers, tables, and examples. Every section adds value for the complex phoneme input. It is front-loaded with the purpose and quick-reference guide. Slightly verbose but justified by the domain.

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 complexity of speech synthesis and no output schema, the description is extremely thorough. It covers input format, voice presets, prosody patterns, phoneme categories, and even special behaviors like stop consonants. No significant gaps remain.

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 coverage is 50% (only utterance has a description). The description greatly elaborates on the utterance parameter, but does not mention sampleRate at all, leaving its semantics to schema min/max/default. This partial coverage results in a moderate score.

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 states the tool synthesizes speech from a klattsch phoneme string and returns base64 WAV audio. It clearly identifies the specific verb and resource, and distinguishes from siblings like text_to_phonemes and speak_file by focusing on phoneme input.

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 provides step-by-step instructions on building phoneme strings, setting voice parameters, and adding prosody. It also suggests using text_to_phonemes first. However, it does not explicitly mention when to use alternatives like speak_file or list_phonemes, so it misses some exclusion guidance.

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

speak_fileA

Like speak, but writes the WAV directly to a file on disk and returns the path. Use this when you need to attach or share the audio file.

Returns: { filePath, byteLength, durationMs, warnings }

ParametersJSON Schema

Name	Required	Description
`utterance`	Yes	The klattsch phoneme string.
`filePath`	Yes	Absolute path to write the WAV file. E.g. /home/user/output.wav
`sampleRate`	No

TDQS

A4.4/5.0

Behavior4/5

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

The description discloses the return value structure (filePath, byteLength, durationMs, warnings) and mentions writing to disk. However, it does not cover potential side effects like overwriting existing files or permissions, which would be useful. No annotations are provided, so the description carries the burden.

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 extremely concise, consisting of two sentences and a return list. Every sentence adds value, and the key differentiator is front-loaded.

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?

For a simple tool with three parameters and no output schema, the description covers purpose, usage, return structure, and contrasts with sibling. It could mention the sampleRate default/range, but that is already in the schema. Overall, it is nearly complete.

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 description coverage is 67%, and the description does not add significant new information beyond the schema for 'utterance' and 'filePath'. The 'sampleRate' parameter has constraints in schema but no description; the description does not elaborate on it. With moderate coverage, a score of 3 is appropriate.

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 that this tool writes a WAV file to disk and returns the path, contrasting it with the sibling 'speak' tool. The verb 'write' and resource 'WAV file' are specific, and the distinction from 'speak' is explicit.

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

Usage Guidelines5/5

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

The description explicitly advises 'Use this when you need to attach or share the audio file', which guides the agent on when to choose this tool over alternatives like 'speak'.

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

text_to_phonemesA

Convert English text to an approximate klattsch phoneme string. This does a dictionary lookup word-by-word. Unknown words are spelled out letter-by-letter (which sounds robotic — hand-craft those for best results).

Returns a full phoneme string ready for speak/speak_file. You can (and should) edit the output before passing to speak — add stress marks (!), pitch contours (+N/-N), adjust pauses, or fix mispronounced words.

The output includes control prefixes based on your voice selections.

ParametersJSON Schema

Name	Required	Description
`text`	Yes	The English text to convert (e.g. "Hello, how are you?").
`pitch`	No	Base pitch in Hz. 100-140 = male, 180-220 = female, 250-300 = child.
`rate`	No	Per-phoneme rate in ms. 80-100 = fast, 100-120 = normal, 200-400 = sung.
`formantScale`	No	Formant scale: 1.0 = male, 1.17 = female, 1.3 = child.
`vibrato`	No	Vibrato depth in Hz. 0 = off, 2-3 = natural, 5-6 = dramatic/operatic.

TDQS

A4.2/5.0

Behavior4/5

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 discloses that conversion is approximate, uses dictionary lookup with letter-by-letter fallback, and returns a phoneme string with control prefixes. It does not mention any destructive effects or authentication needs, which are not expected for a text conversion tool.

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 at five sentences, front-loaded with purpose. Every sentence adds value: explaining the process, warning about unknown words, and advising editing. No unnecessary words or repetition.

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 no output schema, the description explains the return value (phoneme string ready for speak) and mentions control prefixes. It provides sufficient context for an agent to use the tool effectively, though it could explicitly state the output format or include a brief example.

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?

All five parameters are described in the input schema with good detail. The description adds context about the output being editable and including control prefixes, but does not significantly enhance parameter understanding beyond what the schema already provides.

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 English text to an approximate klattsch phoneme string via word-by-word dictionary lookup. It specifies the fallback spelling for unknown words and distinguishes itself from sibling tools like speak and speak_file by noting the output is ready for those tools.

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 advises editing the output before using it with speak and warns that unknown words sounded robotic. It provides context on when to use (conversion) and best practices, though it does not explicitly state when not to use it or compare to siblings.

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

validateA

Parse a klattsch phoneme string without rendering audio. Returns schedule info, duration, and warnings.

ParametersJSON Schema

Name	Required	Description	Default
`utterance`	Yes	The klattsch phoneme string to validate.

TDQS

A4/5.0

Behavior4/5

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

With no annotations provided, the description bears full responsibility for behavioral transparency. It discloses the read-only nature (parse without rendering audio) and describes the outputs. However, it does not clarify potential side effects or permissions, though none are expected for a validation tool. The term 'schedule info' is somewhat vague.

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 extremely concise with two sentences: one for the operation and one for outputs. It is front-loaded with the key information and contains no redundant text.

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?

For a simple tool with one parameter and no output schema, the description covers the input, operation, and outputs adequately. However, 'schedule info' is vague and could be expanded for clarity. Overall, it provides sufficient context for an agent to understand the tool's purpose and behavior.

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 coverage is 100% for the single parameter 'utterance', and the description does not add significant new meaning beyond 'klattsch phoneme string'. It reinforces context but lacks format examples or constraints. Baseline of 3 is appropriate as the schema already describes the parameter.

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's core action (parse a klattsch phoneme string), what it does not do (without rendering audio), and its outputs (schedule info, duration, warnings). It effectively distinguishes it from siblings like speak (audio rendering) and list_phonemes (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?

The description implies usage for validation without audio, but it does not explicitly state when to use this tool versus alternatives like speak or text_to_phonemes. No exclusions or sibling names are mentioned, so guidance is only implicit.

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

voice_presetsA

Get copy-paste ready voice presets. Returns preset name → directive string. Use these as prefixes before your phoneme strings.

ParametersJSON Schema

Name	Required	Description	Default
`preset`	No	Which preset to show, or "all" for everything.	all

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations, the description carries full burden. It correctly indicates a read-only operation (Get) and describes the return format. It does not mention edge cases or side effects, but for a simple retrieval tool, this is adequate.

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 filler. Every sentence adds value: one defines the tool's action and output, the second provides usage context. Highly efficient.

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?

For a simple tool with one parameter and no output schema, the description is fully sufficient. It explains the purpose, return format, and how to use the result in the broader phoneme workflow.

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?

The input schema already covers the single parameter with 100% coverage, including a description and enum values. The description does not add significant meaning beyond 'Get copy-paste ready voice presets,' so a baseline score of 3 is appropriate.

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 verb (get), the resource (voice presets), and the result (preset name → directive string). It distinguishes from siblings like list_phonemes and speak by specifying the return format and its use as prefixes for phoneme strings.

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 advises 'Use these as prefixes before your phoneme strings,' providing clear context for when to use the tool. It does not explicitly state when not to use it or mention alternatives, but the guidance is sufficient given the sibling tools.

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.

6 tool updatesv2.0.0May 27, 2026
- First observedlist_phonemes
- First observedspeak
- First observedspeak_file
- First observedtext_to_phonemes
- First observedvalidate
- First observedvoice_presets

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.3/5.0

Scored 2026-05-27 02:05 across 6 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: listing phonemes, converting text, speaking, speaking to file, validating, and retrieving presets. No overlaps.

Naming Consistency4/5

Most tools follow a verb_noun pattern with underscores, but 'voice_presets' is a noun phrase rather than a verb, causing a slight inconsistency.

Tool Count5/5

Six tools is well-scoped for a speech synthesizer, covering all essential actions without being too many or too few.

Completeness5/5

The tool set covers the full workflow: creating phoneme strings (text_to_phonemes), validating them, rendering audio in two formats, referencing phonemes, and accessing presets.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

VoiceLabsOAuth
now.voicelabs
AI voice generation: text-to-speech and voice cloning from any MCP client.
Text-to-Speech Speech Processing Audio Processing
1
Gessa: game asset generation for AI agentsOAuth
ai.gessa
Generate game-ready 3D models, textures, and audio from natural language, over MCP.
AI & Machine Learning Image & Video Processing Audio Processing
1
StoryStudioOAuth
io.github.HelloElo-Fr
AI image, video, voice and music generation over MCP, routed to Veo 3.1, Seedance 2.0 and more.
AI & Machine Learning Image & Video Processing Audio Processing
1
mcp-producerOAuth
io.github.AceDataCloud
MCP server for Producer/Riffusion AI music generation
Audio Processing AI & Machine Learning
22

Related MCP Servers

mcp-svstudio
Audio Processing Multimedia Processing
ocadaruma
A
license
B
quality
D
maintenance
MCP server for Synthesizer V AI Vocal Studio, which allows LLMs to create/edit vocal tracks e.g. adding lyrics to the melody.
Updated a year ago (2025-04-01 23:22 UTC)
6
12
Apache 2.0
MCP TTS Server
Text-to-Speech Speech Processing
kristofferv98
F
license
Not graded
quality
D
maintenance
Provides text-to-speech conversion through a unified MCP interface, supporting both local Kokoro and cloud OpenAI TTS engines with streaming audio, voice selection, and customization via natural language instructions.
Updated a year ago (2025-04-22 22:51 UTC)
7
-
leanvox-mcpofficial
Text-to-Speech Speech Processing Audio Processing
leanvox
A
license
Not graded
quality
D
maintenance
Enables text-to-speech generation, voice cloning, dialogue creation, and other TTS operations through natural language in MCP-compatible AI assistants.
Updated 4 months ago (2026-05-11 12:40 UTC)
8 npm
MIT
kokoro-tts
Text-to-Speech Speech Processing AI & Machine Learning
neosun100
A
license
Not graded
quality
C
maintenance
Enables AI agents to generate high-quality speech with 54+ voices in multiple languages via MCP tools.
Updated 9 months ago (2025-12-29 01:42 UTC)
19
Apache 2.0

klattsch-mcp 🎤

What It Does

Quick Start

Prerequisites

Installation

Test It

Connecting to Your AI

Claude Desktop

Claude Code (CLI)

Cursor

OpenClaw

Any MCP-Compatible Client

What the AI Can Do

Voice Presets

Example: Full Workflow

🎵 Demo

How It Works

Credits

License

Available Tools

What This Is

How To Use This Tool

Step 1: Build a phoneme string

Step 2 (optional): Set voice character

Step 3: Add prosody (intonation)

Step 4: Render

Quick-Reference Voice Presets

Intonation Patterns That Sound Natural

Singing With Note Names

Example Strings

Phoneme Categories (all 39 phonemes)

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

leanvox-mcpofficial