Which integrations are available for this server?

Provides tools for converting text to speech using ElevenLabs voices, batch processing multiple texts, listing available voices, and looking up voice IDs by name.

How do I use Drizz Voice Generator?

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., "@Drizz Voice Generator List available ElevenLabs voices" 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.

Drizz Voice Generator

by parthadrizz

Overview Schema Source Related Servers Discussions Admin

JavaScript

Local

Drizz Voice Generator

ElevenLabs text-to-speech MCP server for Claude Desktop and Claude Code. Generate voice audio directly from Claude conversations.

Quick Start

git clone <repo-url>
cd drizz-voice-generator
node setup.js

The setup wizard will:

Install dependencies automatically
Ask for your ElevenLabs API key (validated live)
Ask where to save MP3 files
Configure Claude Desktop automatically

Then restart Claude Desktop — done.

Related MCP server: ElevenLabs MCP Server

Tools

Tool	Description
`text_to_speech`	Convert text to an MP3 file
`batch_text_to_speech`	Convert multiple texts to MP3s in parallel
`list_voices`	List all available ElevenLabs voices
`get_voice_id`	Look up a voice ID by name

Example Prompts

"Generate speech saying 'Hello world' with Rachel's voice, save as hello"
"List available ElevenLabs voices"
"Generate the Fathom intro using George's voice saved as fathom_intro, and the outro using Rachel saved as fathom_outro"

Manual Setup

If you prefer to configure manually:

npm install

Add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS):

{
  "mcpServers": {
    "drizz-voice-generator": {
      "command": "node",
      "args": ["/absolute/path/to/index.js"],
      "env": {
        "ELEVENLABS_API_KEY": "your_key_here",
        "ELEVENLABS_OUTPUT_DIR": "/Users/you/Desktop"
      }
    }
  }
}

Config paths by OS:

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

Environment Variables

Variable	Required	Default	Description
`ELEVENLABS_API_KEY`	Yes	—	Your ElevenLabs API key
`ELEVENLABS_OUTPUT_DIR`	No	`~/Desktop`	Where MP3 files are saved

Troubleshooting

Server not showing in Claude Desktop

Make sure you restarted Claude Desktop completely (quit + reopen)
Check that the path to index.js in the config is absolute and correct

API key invalid

Get a key at elevenlabs.io → Profile → API Keys

Rate limit errors on batch requests

ElevenLabs free tier has tight rate limits. Try fewer items per batch or upgrade your plan.

License

MIT

Available Tools

5 tools

batch_text_to_speechA

Convert multiple texts to speech in parallel. Each item can have a different voice and filename. Supports presets and auto text enhancement.

ParametersJSON Schema

Name	Required	Description	Default
`items`	Yes	Array of text-to-speech items to process in parallel

TDQS

A3.6/5.0

Behavior2/5

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

No annotations are provided, so the description must carry the full burden. It discloses parallel processing and per-item configuration, but omits crucial behavior such as return format, error handling, rate limits, or where output files are stored. For a batch operation, this is a significant transparency gap.

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 concise sentences with no redundancy. The first sentence front-loads the core action and parallelism; the second highlights key per-item features. Every word adds value.

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?

Despite a rich schema, the description is too brief for a batch tool with no annotations and no output schema. It lacks essential context about what the tool returns (e.g., file paths, IDs), how partial failures are handled, or any resource limitations. This makes it incomplete for reliable agent use.

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%, with all nested properties described. The description adds a summary of some parameters (voice, filename, presets, auto enhancement) but does not provide deeper meaning beyond the schema. It confirms per-item variability, which the schema already conveys.

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 multiple texts to speech in parallel, with per-item voice and filename customization. This distinguishes it from the sibling text_to_speech tool, which presumably handles a single text.

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 phrase 'in parallel' and 'multiple texts' clearly indicates when to use this tool, but it does not explicitly name alternatives or state when not to use it. The sibling list provides context, but the description itself lacks direct when-not guidance.

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

get_voice_idA

Look up an ElevenLabs voice ID by name

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	The voice name to look up (e.g. Rachel, Drew, George)

TDQS

A3.5/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. It only states the lookup operation without disclosing failure behavior (e.g., if name not found), authentication requirements, or the exact return format. This is a significant transparency gap for a tool with no annotations.

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 front-loads the purpose. No wasted words or redundant information.

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

Completeness3/5

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

Given the tool's simplicity, the description covers the basic functionality, but it lacks details about the return value and error cases. Without an output schema, the description should compensate by explaining what the response looks like (e.g., a plain string ID), which it does not.

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 schema coverage is 100% and already describes the 'name' parameter with examples. The description simply says 'by name', which adds no new meaning beyond the schema, so the baseline of 3 applies.

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 action ('Look up'), the target ('voice ID'), and the criterion ('by name'). This distinguishes it from siblings like list_voices, which lists voices, and text_to_speech, which synthesizes audio.

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?

Usage is implied: use this tool when you have a voice name and need its corresponding ID. However, there is no explicit mention of when not to use it or how it compares to list_voices for browsing available voices.

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

list_voicesA

List all available ElevenLabs voices

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.7/5.0

Behavior2/5

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

With no annotations, the description carries the full burden. It only states 'List all available ElevenLabs voices' with no mention of return format, pagination, authentication, or rate limits. This provides minimal behavioral transparency beyond what the tool name already suggests.

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 front-loaded sentence with no wasted words. It directly states the action and resource, making it highly concise and well-structured.

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

Completeness3/5

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

For a simple list operation, the description adequately covers the action, but it lacks information about the output structure (e.g., does it return an array of voice IDs and names?). Since there is no output schema, the description is adequate but has clear gaps.

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?

The tool has 0 parameters, which is the baseline for a score of 4. The description accurately omits parameter details because there are none, and the schema is completely covered.

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 uses a specific verb ('List') and a specific resource ('all available ElevenLabs voices'), clearly distinguishing it from sibling tools like text_to_speech which generate audio. It precisely conveys what the tool does.

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 that this tool should be used to retrieve the full set of voices, but it does not explicitly mention when to use it versus alternatives or any prerequisites. Since there are no direct alternatives that list voices, the guidance is implicit, not stated.

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

preview_text_enhancementA

Preview how text will be enhanced with SSML pauses and number expansion before sending to ElevenLabs. Use this to check and tweak scripts without burning API credits.

ParametersJSON Schema

Name	Required	Description	Default
`text`	Yes	The text to preview enhancement for

TDQS

A4.5/5.0

Behavior4/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 disclosure. It reveals key behavioral traits: the tool performs SSML pauses and number expansion, and it does not consume API credits. It does not explicitly describe the return format, but 'preview' strongly implies the enhanced text is returned, and the simple nature of the tool mitigates this gap.

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 two concise sentences with front-loaded purpose and practical usage advice. Every word provides value, with no redundant or irrelevant information.

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 simplicity (one parameter, no output schema), the description fully covers what an agent needs to know: what it does, when to use it, and why (cost savings). The context is complete for its complexity.

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 schema already provides a clear description for the single parameter 'text', covering 100% of the parameter semantics. The tool description adds only minimal additional context ('scripts') beyond what the schema states, so it meets the baseline without significantly enhancing understanding.

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 purpose: it previews how text will be enhanced with SSML pauses and number expansion. This specific verb ('preview') and resource ('text enhancement') distinguish it from sibling tools like text_to_speech, which actually synthesize audio.

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 says 'Use this to check and tweak scripts without burning API credits,' providing a clear when-to-use and implying a cost-saving alternative to actual TTS. This makes the usage context and distinction from sibling tools evident.

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

text_to_speechB

Convert text to speech using ElevenLabs and save as MP3. Automatically enhances text with natural pauses and breathing room. Use presets for quick voice tuning: natural (default), conversational (YouTube/demos), narration (tutorials), dramatic (trailers).

ParametersJSON Schema

Name	Required	Description
`text`	Yes	The text to convert to speech
`voice`	No	Voice name (e.g. Rachel, Drew, George) or ElevenLabs voice ID. Defaults to Rachel
`preset`	No	Voice preset: natural (default), conversational (YouTube/demos), narration (tutorials), dramatic (trailers)
`filename`	No	Output filename (e.g. intro.mp3). Saved to the configured output directory
`model_id`	No	ElevenLabs model ID. Defaults to eleven_multilingual_v2
`stability`	No	Voice stability (0-1). Overrides preset value
`enhance_text`	No	Auto-enhance text with natural pauses and number expansion. Defaults to true
`similarity_boost`	No	Voice similarity boost (0-1). Overrides preset value

TDQS

B3.4/5.0

Behavior3/5

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

With no annotations, the description carries the transparency burden. It discloses auto-enhancement of text with pauses and breathing, which is valuable. However, it does not mention output location, return values, error behavior, or any side effects, leaving some gaps for an agent.

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 concise and front-loaded with the core function, followed by auto-enhancement and preset guidance. Each sentence contributes, though the preset list partially repeats the schema's enum description.

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

Completeness3/5

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

For a tool with no annotations and no output schema, the description covers the core purpose and auto-enhancement behavior. However, it lacks guidance on when to use this versus sibling batch/preview tools and does not clarify the return value or output file handling, making it adequate but not exhaustive.

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 documents all 8 parameters with 100% description coverage, so the description adds minimal new parameter semantics. The preset examples are duplicated in the schema, making the baseline score of 3 appropriate since the schema does the heavy lifting.

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 it converts text to speech using ElevenLabs and saves as MP3, giving a specific verb and resource. However, it does not explicitly distinguish from sibling batch_text_to_speech or preview_text_enhancement, so it misses some differentiation.

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?

It provides preset usage guidance (natural for default, conversational for YouTube/demos, narration for tutorials, dramatic for trailers), which helps with parameter selection. However, it does not explain when to use this tool versus batch_text_to_speech or preview_text_enhancement, leaving the tool-selection context implicit.

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.

5 tool updatesv1.0.0Aug 9, 2026
- First observedbatch_text_to_speech
- First observedget_voice_id
- First observedlist_voices
- First observedpreview_text_enhancement
- 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/5.0

Scored 2026-08-09 23:00 across 5 tools

Disambiguation5/5

Each tool has a distinct purpose: single text-to-speech conversion, listing voices, looking up voice IDs, batch conversion, and previewing text enhancement. No overlap or ambiguity.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun pattern (e.g., text_to_speech, list_voices, get_voice_id, batch_text_to_speech, preview_text_enhancement). The naming is uniform and predictable.

Tool Count5/5

Five tools is well-scoped for a voice generator server, covering single and batch conversion, voice management, and a preview utility without unnecessary bloat.

Completeness5/5

The tool surface covers the full generation workflow: text enhancement preview, single/batch generation, and voice lookup. No obvious missing operations for the stated purpose.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

ElevenLabsOAuth
io.elevenlabs
Manage ElevenLabs voice agents and generate speech, music, sound effects, images, and video.
Text-to-Speech Speech Processing Audio Processing
11
ElevenLabs C
io.github.mcp-dir
ElevenLabs in natural language: generate speech in any language, create and manage voices, compose m
Text-to-Speech Speech Processing Audio Processing
1551
Carbon VoiceOAuth
app.carbonvoice.mcp
Carbon Voice MCP serves as a bridge that connects AI assistants like ChatGPT, Claude, and Cursor to a user's Carbon Voice account, turning voice messages and conversations into a private, on-demand knowledge base. It provides 28 specialized tools for comprehensive voice messaging management, including creating and sending messages, accessing conversation history with instant transcription, running AI actions (summarization, TLDR generation, meeting notes), and managing workspace collaboration through folders, contacts, and team communications.
Communication Knowledge & Memory Text Summarization
2
Fathom MCP ServerOAuth
io.github.agencyenterprise
Connect Claude to Fathom meeting recordings, transcripts, and summaries
Communication App Automation Search
216

Related MCP Servers

ElevenLabs MCP Server
Text-to-Speech Audio Processing Speech Processing
projectservan8n
A
license
A
quality
Not graded
maintenance
Enables interaction with ElevenLabs Text-to-Speech and audio processing APIs. Supports speech generation, voice cloning, audio transcription, and sound effect creation through natural language.
Updated a year ago (2025-09-12 02:27 UTC)
24
MIT
ElevenLabs MCP Server
Text-to-Speech Audio Processing Multimedia Processing
afarhadi99
A
license
Not graded
quality
D
maintenance
Provides comprehensive access to ElevenLabs AI audio features including text-to-speech, voice cloning, sound generation, and audio isolation. Enables users to generate high-quality speech, manage voices, transform audio, and access ElevenLabs services through natural language interactions.
Updated a year ago (2025-10-18 04:15 UTC)
103 npm
MIT
ElevenLabs MCP Server
Text-to-Speech Speech Processing
mafzaal
A
license
A
quality
F
maintenance
Enables text-to-speech conversion using ElevenLabs API with voice management, streaming support, and multiple models.
Updated a year ago (2025-09-26 00:53 UTC)
5
1
MIT
elevenlabs-voice-mcp
Text-to-Speech Speech Processing
krystiangw
F
license
A
quality
D
maintenance
Enables Claude to speak responses out loud using ElevenLabs text-to-speech API, with tools to list voices and convert text to speech.
Updated 3 months ago (2026-06-19 09:02 UTC)
2
-