Skip to main content
Glama
krystiangw

elevenlabs-voice-mcp

by krystiangw
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

elevenlabs-voice-mcp

A tiny Model Context Protocol server that gives Claude a voice through the ElevenLabs text-to-speech API.

It exposes two tools over stdio so any MCP client (Claude Code, Claude Desktop) can speak its responses out loud or discover voices — operated in plain English:

Tool

What it does

list_voices

List the voices available on your ElevenLabs account (id + name + labels).

text_to_speech

Turn text into an MP3 with a chosen voice/model, save it, and play it.

Multilingual by default (eleven_multilingual_v2), so Polish reads correctly too.

Why

I build agentic systems with Claude and MCP. This wires ElevenLabs into that world as a first-class tool: instead of a one-off API script, Claude itself can decide to speak, pick a voice, and read something back — the same MCP pattern I use elsewhere, pointed at ElevenLabs' audio models.

Related MCP server: ElevenLabs MCP Server

Setup

npm install
npm run build              # or: npm run dev   (runs from source via tsx)
export ELEVENLABS_API_KEY=sk_...   # free key: elevenlabs.io → Profile → API Keys
npm start

Use it from Claude Code

claude mcp add elevenlabs-voice -- node /absolute/path/to/dist/index.js
# (set ELEVENLABS_API_KEY in your environment first)

Or add it to your Claude Desktop config:

{
  "mcpServers": {
    "elevenlabs-voice": {
      "command": "node",
      "args": ["/absolute/path/to/elevenlabs-voice-mcp/dist/index.js"],
      "env": { "ELEVENLABS_API_KEY": "sk_..." }
    }
  }
}

Then just ask Claude: "list the ElevenLabs voices" or "say 'cześć, świecie' out loud."

Notes

  • A free ElevenLabs account includes enough monthly characters to try this out.

  • Playback uses the OS default (afplay on macOS, aplay on Linux, PowerShell on Windows); generation still works headless if no player is present.

  • Override the default voice/model with ELEVENLABS_VOICE_ID / ELEVENLABS_MODEL_ID, or per call via the tool arguments.

License

MIT

Available Tools

2 tools
list_voicesA

List the ElevenLabs voices available on the configured account (id + name + labels).

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.3/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 burden of behavioral disclosure. It transparently states that the tool lists voices and returns specific fields, and it clarifies the account scope. No side effects are mentioned, but as a simple list operation, none are expected.

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 that efficiently conveys the tool's purpose and return value without any wasted words. It achieves maximum clarity in minimal space.

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 low complexity (no parameters, no output schema), the description is fully sufficient. It states what the tool lists, the account scope, and the returned fields, providing all necessary information for a straightforward list operation.

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 no parameters, so the baseline of 4 applies. The description adds contextual meaning by mentioning 'configured account', which clarifies the implicit scope of the list operation, but there are no parameter semantics to elaborate further.

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 ('List'), the resource ('ElevenLabs voices'), and the scope ('on the configured account'). It also specifies the return data ('id + name + labels'), making it distinct from the sibling tool 'text_to_speech' which is for 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?

Usage context is implied by the verb 'List' and the absence of parameters, indicating this is a read-only listing tool. However, there is no explicit guidance on when to use it versus 'text_to_speech', leaving the decision to inference.

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 with ElevenLabs, save it as an MP3, and (optionally) play it.

ParametersJSON Schema
NameRequiredDescriptionDefault
playNoPlay the audio after generating it. Defaults to true.
textYesThe text to speak.
model_idNoModel id, e.g. eleven_multilingual_v2 or eleven_turbo_v2_5.
voice_idNoElevenLabs voice id. Defaults to the configured voice.
output_pathNoWhere to write the MP3. Defaults to the OS temp dir.

TDQS

B3.3/5.0
Behavior2/5

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

With no annotations, the description must carry the full burden of behavioral disclosure. It mentions saving as MP3 and optional playback, but fails to disclose network dependency, API key requirements, or side effects like file creation location. This is insufficient for a tool interacting with 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 a single sentence that front-loads the core action and includes only necessary information. It is efficient and free of filler.

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?

The tool is relatively simple, but the absence of annotations and output schema means the description should provide more context. It covers the core function well but omits prerequisites like API key setup and potential side effects, leaving gaps for an agent evaluating whether this tool fits the situation.

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 provides 100% coverage for all five parameters, so the description adds little beyond the schema. It mentions 'save it as an MP3' and 'optionally play' which are already represented in the schema descriptions for output_path and play. Baseline 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 'Convert' with resource 'text to speech', and specifies the output as MP3 with optional playback. This strongly distinguishes it from sibling list_voices, which is about listing voices, not generating speech.

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

Usage Guidelines2/5

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

No explicit guidance on when to use this tool versus list_voices or any alternatives. The description implies usage for converting text to speech, but does not mention prerequisites, exclusions, or when it might be inappropriate to use.

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.

  1. 2 tool updatesv0.1.0
    • First observedlist_voices
    • 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

A3.7/5.0

Scored across 2 tools

Disambiguation5/5

The two tools have completely distinct purposes: one lists available voices, the other converts text to speech. There is no overlap or ambiguity in their functions.

Naming Consistency4/5

Both tools use snake_case, but the pattern differs: 'list_voices' is a clear verb_noun construction, while 'text_to_speech' is a noun phrase describing the action. This is a minor inconsistency, but both names are intuitive and readable.

Tool Count3/5

With only two tools, the server feels minimal. While both tools are essential for the primary TTS workflow, the scope is narrow and might be insufficient for users expecting voice management capabilities.

Completeness4/5

The core workflow of listing voices and generating speech is covered. However, missing operations like fetching individual voice details or managing voices create minor gaps that agents could work around by using the list result.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers