Which integrations are available for this server?

Provides tools to interact with ElevenLabs voice AI, including text-to-speech, speech-to-text, voice management, and history retrieval.

How do I use ElevenLabs Voice-to-Voice Agent?

1. Click on "Install 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., "@ElevenLabs Voice-to-Voice Agent start a voice session about artificial intelligence" 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.

ElevenLabs Voice-to-Voice Agent

by Begwen

Overview Schema Related Servers Score Discussions

JavaScript

Local

ElevenLabs Voice-to-Voice Agent — MCP Server

A full voice-to-voice AI agent built on the Model Context Protocol. Speak into your microphone, the agent thinks, and ElevenLabs speaks back — all orchestrated through MCP tools, prompts, and resources.

Works with Anthropic Claude or OpenAI GPT — no Claude Desktop required.

MCP Primitives Implemented

Tools (7)

Tool	Description
`list_voices`	List all available ElevenLabs voices
`get_voice`	Get detailed info about a specific voice
`list_models`	List available TTS/STT models
`text_to_speech`	Convert text → MP3, save to disk
`speech_to_text`	Transcribe an audio file → text
`get_user_info`	Account and character usage info
`get_history`	Retrieve generation history

Prompts (4) — prompt-centric MCP

Prompt	Args	What it does
`voice_agent_persona`	`name`, `personality`, `[voice_style]`	Creates a named agent persona; picks the best matching voice and speaks every reply aloud
`start_voice_session`	`[topic]`, `[language]`, `[voice_id]`	Initialises a live voice loop — agent listens and responds in spoken audio
`find_voice_for_role`	`role`	Lists voices, picks top 3 for the role, generates audio samples for each
`voice_showcase`	`phrase`, `[count]`	Renders the same phrase across N diverse voices for side-by-side comparison

Resources (2)

URI	Description
`elevenlabs://voices`	Live voice list — IDs, categories, labels
`elevenlabs://models`	Available TTS/STT models and capabilities

Related MCP server: ElevenLabs MCP Server

Prerequisites

Node.js ≥ 18

sox (for microphone recording in /voice mode)

brew install sox        # macOS
sudo apt install sox    # Ubuntu/Debian

An ElevenLabs API key
An LLM key: Anthropic or OpenAI

Setup

npm install
npm run build

Environment Variables

Variable	Required	Description
`ELEVENLABS_API_KEY`	Yes	ElevenLabs API key
`LLM_PROVIDER`	No	`"anthropic"` (default) or `"openai"`
`ANTHROPIC_API_KEY`	If using Anthropic	Claude API key
`OPENAI_API_KEY`	If using OpenAI	GPT API key
`ELEVENLABS_OUTPUT_DIR`	No	Where MP3 files are saved (defaults to cwd)

Export before running (the server reads from process.env directly — .env is not auto-loaded):

export ELEVENLABS_API_KEY="your-key"
export LLM_PROVIDER="anthropic"
export ANTHROPIC_API_KEY="your-key"

Usage

Start the client

npm run client

ElevenLabs Voice Agent — MCP Client (provider: anthropic)

Connected! 7 tools: list_voices, get_voice, list_models, text_to_speech, speech_to_text, get_user_info, get_history
Commands: /prompts  /prompt <name> [args]  /voice  exit

Text chat

You: List all available voices
  [tool: list_voices]
Assistant: Here are the available voices...

You: Convert "Welcome to my demo" to speech using a deep male voice
  [tool: list_voices]
  [tool: text_to_speech]
Assistant: Audio saved to: ./output_1234.mp3

List and invoke prompts

You: /prompts

Available prompts:
  voice_agent_persona — Create a voice AI agent with a specific persona...
    args: name, personality, [voice_style]
  start_voice_session — Initialize a live voice conversation...
    args: [topic], [language], [voice_id]
  find_voice_for_role — Analyze and recommend voices for a use case...
    args: role
  voice_showcase — Render a phrase in multiple voices...
    args: phrase, [count]

You: /prompt voice_agent_persona name="Aria" personality="warm and professional"
  [tool: list_voices]
  [tool: text_to_speech]
Assistant: Hi, I'm Aria! How can I help you today?
  [Audio plays automatically]

Voice conversation mode

You: /voice

[Voice Mode] The agent will listen and speak back.
[Voice Mode] Type 'exit' at any prompt to return to text mode.

Press ENTER to speak (or type 'exit'):
  Recording... Press ENTER to stop:
  Transcribing...

You: "What voices does ElevenLabs have?"
  [tool: list_voices]
  [tool: text_to_speech]
Assistant: ElevenLabs has over 30 voices...
  [Audio plays automatically]

Press ENTER to speak (or type 'exit'): exit

[Returned to text mode]

ElevenLabs API Key Permissions

When creating your API key, enable:

Permission	Setting
Text to Speech	Access
Speech to Text	Access
Voices	Read
Models	Access
History	Read
User	Read

Everything else can stay at No Access.

With Claude Desktop

Add to claude_desktop_config.json:

{
  "mcpServers": {
    "elevenlabs": {
      "command": "node",
      "args": ["/absolute/path/to/build/index.js"],
      "env": { "ELEVENLABS_API_KEY": "your-key" }
    }
  }
}

With Claude Code

claude mcp add elevenlabs node /absolute/path/to/build/index.js

Architecture

src/
  elevenlabs-client.ts  — ElevenLabs REST API wrapper (TTS + STT + voices + models)
  index.ts              — MCP server: 7 tools, 4 prompts, 2 resources
  client.ts             — CLI client: text REPL + /voice loop + /prompt commands

You (mic/keyboard)
    │
    ▼
client.ts ──────────────────────────────► LLM API (Claude / GPT)
    │  MCP stdio transport                       │
    ▼                                            │ tool calls
index.ts (MCP Server)  ◄────────────────────────┘
    │
    ▼
elevenlabs-client.ts ──► ElevenLabs REST API
                              (TTS + STT + voices + models)

Voice loop flow:

Mic → sox → WAV file
speech_to_text tool → transcript text
LLM (with VOICE_SYSTEM prompt) → text response + text_to_speech call
text_to_speech tool → MP3 file
afplay / mpg123 → audio plays from speakers
Loop back to step 1

License

MIT

Available Tools

7 tools

get_historyB

Retrieve the history of TTS generations from ElevenLabs.

ParametersJSON Schema

Name	Required	Description	Default
`page_size`	No	Number of history items to retrieve (default: 20)

TDQS

B3.3/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 of behavioral disclosure. While 'Retrieve' implies a safe read operation, the description omits important details such as the return format, pagination behavior, or whether any rate limits apply. This leaves the agent uncertain about the tool's full 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?

The description is a single, concise sentence that front-loads the main action and resource. Every word earns its place, and there is no redundancy or unnecessary detail.

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 with one optional parameter and no output schema, but the description does not explain what the history items contain or how results are structured. This creates a gap for agents that need to interpret the return value, despite the tool's low 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 input schema fully documents the single 'page_size' parameter with a description, minimum, maximum, and default. The tool description adds no additional parameter semantics beyond what the schema already provides, so the 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 uses a clear verb ('Retrieve') and a specific resource ('history of TTS generations from ElevenLabs'), making the tool's function immediately obvious. It also distinguishes itself from sibling tools like list_voices or text_to_speech by focusing on historical generation records.

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?

The description provides no guidance on when to use this tool versus alternatives. It simply states what it does without mentioning any exclusions, prerequisites, or context that would help an agent decide between this and other tools.

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

get_user_infoA

Get the current ElevenLabs user/subscription info including character usage and limits.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior4/5

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

No annotations are provided, so the description bears full responsibility. It clearly frames the operation as a read-only 'Get' and specifies the data returned, which is sufficient for a simple query. No side effects or additional behaviors are disclosed, but 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 focused sentence that begins with the action verb and includes the key output details. No unnecessary 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 zero-parameter read tool, the description provides enough context: what is retrieved (user/subscription info) and specific elements (character usage, limits). Without an output schema, this adequately sets expectations for the return payload.

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 accepts zero parameters, so there is no parameter semantics to clarify. The description correctly omits parameter details, matching the baseline for parameterless tools.

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 retrieves current ElevenLabs user/subscription information, specifying character usage and limits. This distinguishes it from sibling tools focused on voices, models, and audio operations.

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 the tool is for account-level information rather than content operations, making its use case obvious. However, it doesn't explicitly mention when to use it over sibling tools or provide exclusions. This is clear context but not explicit guidelines.

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

get_voiceA

Get detailed information about a specific ElevenLabs voice by its ID.

ParametersJSON Schema

Name	Required	Description	Default
`voice_id`	Yes	The ID of the voice to retrieve

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 full burden. It states the action but does not disclose return format, possible errors (e.g., 404), authentication requirements, or rate limits. 'Detailed information' is vague and adds no substantive behavioral detail.

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?

A single, focused sentence that conveys the purpose without wasted words. It is front-loaded and immediately understandable.

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 simple with one parameter and no output schema. The description gives the essential purpose but does not elaborate on what 'detailed information' includes, leaving some ambiguity about the return value. For a minimal viable get-by-id tool, it is adequate but not comprehensive.

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 a single parameter 'voice_id' already clearly described. The description's 'by its ID' adds no extra semantics beyond what the schema provides, thus 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 uses a specific verb ('Get') and identifies the resource ('detailed information about a specific ElevenLabs voice by its ID'), clearly distinguishing it from sibling tools like list_voices which retrieves multiple voices.

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 clearly implies when to use the tool (when you need details on a single voice by its ID) and implicitly contrasts with list_voices, though it does not explicitly mention alternatives or exclusions.

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

list_modelsA

List all available ElevenLabs TTS models with their capabilities and supported languages.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden for behavioral disclosure. It states the action (list all available models) and the return content (capabilities and languages), but it does not mention pagination, authentication, or any other behavioral traits. This is a minimal but sufficient disclosure for a simple read operation.

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 starts with the action ('List all available...') and delivers complete information without any waste. Every word contributes to the purpose.

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 there is no output schema, the description partially explains return values by mentioning 'capabilities and supported languages.' However, it does not detail response structure or potential edge cases, but for a simple list operation this is adequate.

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 zero parameters, so the baseline is 4. The description doesn't need to add parameter context; the empty schema already signals no inputs are required.

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 the specific verb 'List' with the resource 'ElevenLabs TTS models' and specifies scope ('all available') and content ('capabilities and supported languages'). It clearly distinguishes from sibling tools like list_voices, which target voices.

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 when you need to enumerate all models, but it does not explicitly state when to use this tool versus alternatives or provide exclusion criteria. Sibling tools like list_voices suggest a need for differentiation, but the description alone doesn't provide it.

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 voices available in ElevenLabs. Returns voice IDs, names, and labels.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior3/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 the tool returns voice IDs, names, and labels, which gives useful output expectations, but it does not mention authentication, pagination, or any side effects. For a simple read-only list, this 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 sentence that front-loads the verb and outcome, with no redundant words or filler. It is appropriately brief for such a simple tool.

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?

The description covers the tool's core function and return fields, making it sufficient for a parameterless list operation. The lack of an output schema is mitigated by explicitly stating the returned data types.

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 zero parameters, so there is nothing for the description to explain. The schema is trivially 100% covered, and the baseline for zero-parameter tools is 4, which applies here.

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 the specific verb 'List' and identifies the resource as 'voices available in ElevenLabs', making it clear this is a listing operation. This distinguishes it from 'get_voice' (retrieving a single voice) and 'list_models' (listing models).

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 this tool is for fetching all voices, but it does not explicitly mention alternatives or when not to use it. Sibling tool names like 'get_voice' suggest a contrast, but the description does not articulate this; guidance is only implied.

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

speech_to_textA

Transcribe an audio file to text using ElevenLabs Speech-to-Text (scribe_v1). Supports WAV, MP3, and other common formats.

ParametersJSON Schema

Name	Required	Description
`model_id`	No	STT model ID (default: scribe_v1)
`file_path`	Yes	Absolute path to the audio file to transcribe
`language_code`	No	BCP-47 language code to force recognition language (e.g. 'en', 'hi', 'es'). Leave unset for auto-detect.

TDQS

A3.7/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 for behavioral disclosure. It mentions the model and supported formats but omits return structure, error behavior, or any processing side effects, leaving significant gaps for the agent.

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 leads with the core action, includes the model name, and adds only the relevant mention of supported formats. No redundant or filler content, so it is 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?

The tool is simple with fully documented parameters, but the absence of an output schema means the description could clarify what the transcription returns. It does not address error cases or language auto-detection behavior, leaving some contextual gaps despite its clarity.

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 three parameters have detailed descriptions in the schema (100% coverage), so the baseline score applies. The tool description adds no additional parameter-specific meaning beyond the schema, making the schema the primary source of semantic information.

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 'Transcribe' and the resource 'audio file to text', naming the specific model (scribe_v1). It distinguishes from sibling tools like text_to_speech by indicating directionality, and adds format support (WAV, MP3) for concrete scope.

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 clearly implies when to use this tool: when you have an audio file and need text transcription. It provides clear context but does not explicitly mention alternatives or exclusions, so it stops short of a 5.

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 to speech using ElevenLabs. Saves the audio as an MP3 file and returns the file path.

ParametersJSON Schema

Name	Required	Description
`text`	Yes	The text to convert to speech
`model_id`	No	Model ID (default: eleven_multilingual_v2)
`voice_id`	No	Voice ID to use (default: Rachel — 21m00Tcm4TlvDq8ikWAM)
`stability`	No	Voice stability 0-1 (default: 0.5)
`output_filename`	No	Output filename (default: output_<timestamp>.mp3)
`similarity_boost`	No	Voice similarity boost 0-1 (default: 0.75)

TDQS

A3.8/5.0

Behavior3/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 it saves an MP3 file and returns the file path, but does not mention authentication, rate limits, or file overwrite 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?

Two concise sentences with no filler. The main verb 'Convert' is front-loaded, and the second sentence adds the key side effect and return value without wasted 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 no output schema, the description states the return value (file path) and the primary side effect (saves MP3). Schema covers all parameters. Missing context includes external service usage implications, file location, and any limitations.

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 every parameter described in the schema. The description adds no parameter-specific context beyond what the schema already provides, placing it at the baseline.

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 'Convert text to speech using ElevenLabs' and specifies the outcome (saves MP3, returns file path). This distinguishes it from sibling tools like speech_to_text and voice management tools.

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 does not explicitly state when to use this tool over alternatives or mention exclusions. The purpose is straightforward, so usage can be inferred, but no direct guidance is provided.

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.

7 tool updatesv1.0.0Aug 2, 2026
- First observedget_history
- First observedget_user_info
- First observedget_voice
- First observedlist_models
- First observedlist_voices
- First observedspeech_to_text
- First observedtext_to_speech

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0

Disambiguation5/5

Each tool targets a distinct operation: listing vs fetching voices, listing models, text-to-speech, speech-to-text, user info, and history. There is no overlap or ambiguity between them.

Naming Consistency4/5

Most tools follow a clear verb_noun pattern like list_voices, get_voice, get_user_info, and get_history. However, text_to_speech and speech_to_text deviate from this pattern as noun-to-noun phrases, though they are internally consistent and readable.

Tool Count5/5

Seven tools is a well-scoped number for a voice/audio agent, covering core operations without bloat. The count is appropriate for the apparent purpose.

Completeness3/5

The set covers TTS, STT, voice listing, model listing, user info, and history, but notably lacks a voice-to-voice conversion tool despite the server name. Voice editing/deletion and history item management are also missing, leaving some workflows incomplete.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

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
mcp-aichatOAuth
io.github.AceDataCloud
MCP server for AI dialogue using various LLM models via AceDataCloud
AI & Machine Learning
2
Texttospeech Mcp C
io.github.varvararatta
MCP server for Text-to-Speech
Text-to-Speech Speech Processing Audio Processing
2
mcp-fishOAuth
io.github.AceDataCloud
MCP server exposing the AceDataCloud Fish Audio API (text-to-speech with voice conditioning)
Text-to-Speech Speech Processing
21

Related MCP Servers

Blabber-MCP
Text-to-Speech Speech Processing App Automation
pinkpixel-dev
A
license
A
quality
D
maintenance
An MCP server that enables LLMs to generate spoken audio from text using OpenAI's Text-to-Speech API, supporting various voices, models, and audio formats.
Updated 3 months ago (2026-06-21 02:16 UTC)
1
13
1
MIT
ElevenLabs MCP Serverofficial
Speech Processing Audio Processing
elevenlabs
A
license
A
quality
F
maintenance
An 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.
Updated 17 days ago (2026-08-20 17:12 UTC)
27
1,536
MIT
ElevenLabs MCP Server
Speech Processing Text-to-Speech
iceener
F
license
Not graded
quality
C
maintenance
An MCP server that provides text-to-speech, speech-to-text, and voice management via ElevenLabs API.
Updated a month ago (2026-07-27 13:22 UTC)
1
-
ElevenLabs MCP Server
Text-to-Speech Audio Processing Speech Processing
Discret-Digital
A
license
Not graded
quality
C
maintenance
Official MCP server that enables interaction with ElevenLabs Text to Speech and audio processing APIs. It allows generating speech, cloning voices, transcribing audio, and creating sound effects through natural language.
Updated 3 months ago (2026-06-20 09:45 UTC)
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/Begwen/Agentic-Voice-AI-System---MCP-Native-'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

ElevenLabs Voice-to-Voice Agent — MCP Server

MCP Primitives Implemented

Tools (7)

Prompts (4) — prompt-centric MCP

Resources (2)

Prerequisites

Setup

Environment Variables

Usage

Start the client

Text chat

List and invoke prompts

Voice conversation mode

ElevenLabs API Key Permissions

With Claude Desktop

With Claude Code

Architecture

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

ElevenLabs MCP Serverofficial

Latest Blog Posts

MCP directory API