Provides tools for generating speech, cloning voices, transcribing audio, and manipulating audio using the ElevenLabs API.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@elevenlabs-mcp Turn this speech into text and identify speakers"
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.
Get your API key from ElevenLabs. There is a free tier with 10k credits per month.
Install uv (Python package manager), install with curl -LsSf https://astral.sh/uv/install.sh | sh or see the uv repo for additional install methods.
Go to Claude > Settings > Developer > Edit Config > claude_desktop_config.json to include the following:
{
"mcpServers": {
"ElevenLabs": {
"command": "uvx",
"args": ["elevenlabs-mcp"],
"env": {
"ELEVENLABS_API_KEY": "<insert-your-api-key-here>"
}
}
}
}
If you're using Windows, you will have to enable "Developer Mode" in Claude Desktop to use the MCP server. Click "Help" in the hamburger menu at the top left and select "Enable Developer Mode".
Related MCP server: ElevenLabs MCP Server
For other clients like Cursor and Windsurf, run:
pip install elevenlabs-mcp
python -m elevenlabs_mcp --api-key={{PUT_YOUR_API_KEY_HERE}} --print to get the configuration. Paste it into appropriate configuration directory specified by your MCP client.
That's it. Your MCP client can now interact with ElevenLabs through these tools:
⚠️ Warning: ElevenLabs credits are needed to use these tools.
Try asking Claude:
"Create an AI agent that speaks like a film noir detective and can answer questions about classic movies"
"Generate three voice variations for a wise, ancient dragon character, then I will choose my favorite voice to add to my voice library"
"Convert this recording of my voice to sound like a medieval knight"
"Create a soundscape of a thunderstorm in a dense jungle with animals reacting to the weather"
"Turn this speech into text, identify different speakers, then convert it back using unique voices for each person"
You can configure how the MCP server handles file outputs using these environment variables in your claude_desktop_config.json:
ELEVENLABS_MCP_BASE_PATH: Specify the base path for file operations with relative paths (default: ~/Desktop)
ELEVENLABS_MCP_OUTPUT_MODE: Control how generated files are returned (default: files)
The ELEVENLABS_MCP_OUTPUT_MODE environment variable supports three modes:
files (default): Save files to disk and return file paths
"env": {
"ELEVENLABS_API_KEY": "your-api-key",
"ELEVENLABS_MCP_OUTPUT_MODE": "files"
}resources: Return files as MCP resources; binary data is base64-encoded, text is returned as UTF-8 text
"env": {
"ELEVENLABS_API_KEY": "your-api-key",
"ELEVENLABS_MCP_OUTPUT_MODE": "resources"
}both: Save files to disk AND return as MCP resources
"env": {
"ELEVENLABS_API_KEY": "your-api-key",
"ELEVENLABS_MCP_OUTPUT_MODE": "both"
}Resource Mode Benefits:
Files are returned directly in the MCP response as base64-encoded data
No disk I/O required - useful for containerized or serverless environments
MCP clients can access file content immediately without file system access
In both mode, resources can be fetched later using the elevenlabs://filename URI pattern
Use Cases:
files: Traditional file-based workflows, local development
resources: Cloud environments, MCP clients without file system access
both: Maximum flexibility, caching, and resource sharing scenarios
You can specify the data residency region with the ELEVENLABS_API_RESIDENCY environment variable. Defaults to "us".
Note: Data residency is an enterprise only feature. See the docs for more details.
If you want to contribute or run from source:
Clone the repository:
git clone https://github.com/elevenlabs/elevenlabs-mcp
cd elevenlabs-mcpCreate a virtual environment and install dependencies using uv:
uv venv
source .venv/bin/activate
uv pip install -e ".[dev]"Copy .env.example to .env and add your ElevenLabs API key:
cp .env.example .env
# Edit .env and add your API keyRun the tests to make sure everything is working:
./scripts/test.sh
# Or with options
./scripts/test.sh --verbose --fail-fastInstall the server in Claude Desktop: mcp install elevenlabs_mcp/server.py
Debug and test locally with MCP Inspector: mcp dev elevenlabs_mcp/server.py
Logs when running with Claude Desktop can be found at:
Windows: %APPDATA%\Claude\logs\mcp-server-elevenlabs.log
macOS: ~/Library/Logs/Claude/mcp-server-elevenlabs.log
Certain ElevenLabs API operations, like voice design and audio isolation, can take a long time to resolve. When using the MCP inspector in dev mode, you might get timeout errors despite the tool completing its intended task.
This shouldn't occur when using a client like Claude.
If you encounter the error "MCP ElevenLabs: spawn uvx ENOENT", confirm its absolute path by running this command in your terminal:
which uvxOnce you obtain the absolute path (e.g., /usr/local/bin/uvx), update your configuration to use that path (e.g., "command": "/usr/local/bin/uvx"). This ensures that the correct executable is referenced.
Add a knowledge base to ElevenLabs workspace. Allowed types are epub, pdf, docx, txt, html.
⚠️ COST WARNING: This tool makes an API call to ElevenLabs which may incur costs. Only use when explicitly requested by the user.
Args:
agent_id: ID of the agent to add the knowledge base to.
knowledge_base_name: Name of the knowledge base.
url: URL of the knowledge base.
input_file_path: Path to the file to add to the knowledge base.
text: Text to add to the knowledge base.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes | ||
| knowledge_base_name | Yes | ||
| url | No | ||
| input_file_path | No | ||
| text | No |
| Name | Required | Description |
|---|---|---|
| type | Yes | |
| text | Yes | |
| annotations | No | |
| _meta | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint and destructiveHint, which are non-contradictory. Description adds cost warning and allowed types but lacks detail on authentication, rate limits, error behavior, or whether existing knowledge base is overwritten. Output schema exists but is not leveraged.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is short with three sections: main action, cost warning, args list. Front-loaded with purpose. Args list is somewhat redundant with schema but not excessive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters (3 optional, mutually exclusive), the description fails to explain that exactly one of url/input_file_path/text should be provided. Does not state what the knowledge base is used for or potential side effects. Output schema exists, so return values are not required, but the rest is under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage for parameters. Description lists parameters with one-liners (e.g., 'ID of the agent') that mostly restate property names, adding no substantive semantics. Does not clarify mutual exclusivity of url, input_file_path, text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Add a knowledge base to ElevenLabs workspace' with specific verb and resource. Lists allowed file types (epub, pdf, docx, txt, html), which distinguishes it from sibling tools like create_agent or text_to_speech.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Includes explicit COST WARNING and directive 'Only use when explicitly requested by the user,' providing clear guidance on when to invoke. No sibling tool adds knowledge bases, so no alternative guidance needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the current subscription status. Could be used to measure the usage of the API.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| type | Yes | |
| text | Yes | |
| annotations | No | |
| _meta | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds that it checks current status and hints at measuring usage, which complements annotations without contradiction. No additional behavioral traits beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary action ('Check the current subscription status'), no redundant information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, presence of an output schema, and annotations covering readOnly and openWorld, the description adequately explains the tool's purpose and potential use. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so the description is not required to explain them. Baseline 4 applies, and the description adds no confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool checks subscription status, a distinct function not overlapping with any sibling tools (e.g., speech, voice, agents). The verb 'check' and resource 'subscription' are specific and clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description suggests a use case ('measure the usage of the API'), providing context for when to invoke this tool. No explicit exclusions or alternatives are needed since no sibling tool addresses subscription.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert a prompt to music and save the output audio file to a given directory. Directory is optional, if not provided, the output file will be saved to $HOME/Desktop.
Args:
prompt: Prompt to convert to music. Must provide either prompt or composition_plan.
output_directory: Directory to save the output audio file
composition_plan: Composition plan to use for the music. Must provide either prompt or composition_plan.
music_length_ms: Length of the generated music in milliseconds. Cannot be used if composition_plan is provided.
⚠️ COST WARNING: This tool makes an API call to ElevenLabs which may incur costs. Only use when explicitly requested by the user.| Name | Required | Description | Default |
|---|---|---|---|
| prompt | No | ||
| output_directory | No | ||
| composition_plan | No | ||
| music_length_ms | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Contradicts annotations: description says 'save the output audio file' (write operation), but annotations have readOnlyHint=true. Also adds cost warning but does not compensate for the contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded purpose, uses bullet-like Args section and bold cost warning. Some redundancy in 'Must provide either...' phrase but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers basic usage and cost implications, but does not explain relationship with sibling 'create_composition_plan', output format, or return value despite output schema existing. Incomplete for a tool with multiple modes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds value beyond schema by explaining mutual exclusivity between prompt and composition_plan, default directory, and cost warning. However, does not explain the complex nested structure of composition_plan or music_length_ms constraint.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'convert' and resource 'prompt to music'/'save output audio file'. Distinguishes from siblings like text_to_speech by specifying music generation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Only use when explicitly requested by the user' due to cost. Lists required parameter combinations but does not explicitly compare with sibling 'create_composition_plan' or explain when to use prompt vs composition_plan.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a conversational AI agent with custom configuration.
⚠️ COST WARNING: This tool makes an API call to ElevenLabs which may incur costs. Only use when explicitly requested by the user.
Args:
name: Name of the agent
first_message: First message the agent will say i.e. "Hi, how can I help you today?"
system_prompt: System prompt for the agent
voice_id: ID of the voice to use for the agent
language: ISO 639-1 language code for the agent
llm: LLM to use for the agent
temperature: Temperature for the agent. The lower the temperature, the more deterministic the agent's responses will be. Range is 0 to 1.
max_tokens: Maximum number of tokens to generate.
asr_quality: Quality of the ASR. `high` or `low`.
model_id: ID of the ElevenLabs model to use for the agent.
optimize_streaming_latency: Optimize streaming latency. Range is 0 to 4.
stability: Stability for the agent. Range is 0 to 1.
similarity_boost: Similarity boost for the agent. Range is 0 to 1.
turn_timeout: Timeout for the agent to respond in seconds. Defaults to 7 seconds.
max_duration_seconds: Maximum duration of a conversation in seconds. Defaults to 600 seconds (10 minutes).
record_voice: Whether to record the agent's voice.
retention_days: Number of days to retain the agent's data.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| first_message | Yes | ||
| system_prompt | Yes | ||
| voice_id | No | cgSgspJ2msm6clMCkdW9 | |
| language | No | en | |
| llm | No | gemini-2.0-flash-001 | |
| temperature | No | ||
| max_tokens | No | ||
| asr_quality | No | high | |
| model_id | No | eleven_turbo_v2 | |
| optimize_streaming_latency | No | ||
| stability | No | ||
| similarity_boost | No | ||
| turn_timeout | No | ||
| max_duration_seconds | No | ||
| record_voice | No | ||
| retention_days | No |
| Name | Required | Description |
|---|---|---|
| type | Yes | |
| text | Yes | |
| annotations | No | |
| _meta | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that this tool incurs costs via an API call to ElevenLabs. Annotations are minimal (destructiveHint false, openWorldHint true) and not contradicted. The description could add more about side effects like data retention, but retention_days parameter covers that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and cost warning, but the parameter list is verbose, repeating defaults already in schema. Could be more concise without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (17 parameters, output schema present), the description covers parameter meanings, constraints, and costs. It does not explain return values, but output schema exists. Slightly incomplete on post-creation behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema coverage at 0%, the description compensates fully by explaining each of the 17 parameters in detail, including ranges and defaults, adding significant meaning beyond the JSON schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Create a conversational AI agent with custom configuration', which clearly states the verb and resource. This distinguishes it from sibling tools like get_agent or add_knowledge_base_to_agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Includes a cost warning that explicitly says 'Only use when explicitly requested by the user', providing strong usage guidance. However, it does not mention alternatives or when not to use this tool relative to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a composition plan for music generation. Usage of this endpoint does not cost any credits but is subject to rate limiting depending on your tier. Composition plans can be used when generating music with the compose_music tool.
Args:
prompt: Prompt to create a composition plan for
music_length_ms: The length of the composition plan to generate in milliseconds. Must be between 10000ms and 300000ms. Optional - if not provided, the model will choose a length based on the prompt.
source_composition_plan: An optional composition plan to use as a source for the new composition plan
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | ||
| music_length_ms | No | ||
| source_composition_plan | No |
| Name | Required | Description |
|---|---|---|
| positive_global_styles | Yes | |
| negative_global_styles | Yes | |
| sections | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation 'readOnlyHint: true' directly contradicts the description's claim of creating a new plan, which is a write operation. This is a major inconsistency, undermining transparency despite additional info on cost and rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear first sentence and organized Args section. The credit/rate limit sentence adds relevant context, though it could be slightly tighter. Still, it is well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, parameters, and relationship to sibling tools, but the annotation contradiction undermines completeness. With an output schema present, return values are not required. However, the contradiction leaves the agent uncertain about behavioral expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, the description adds meaningful details: prompt is explained, music_length_ms includes valid range and optionality, and source_composition_plan is described as an optional source. This compensates well for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a composition plan for music generation,' specifying the verb and resource. It also distinguishes from the sibling 'compose_music' tool by explaining that plans are used with that tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that no credits are used and rate limits apply, giving clear context for when to use. It also mentions the relationship to 'compose_music', but does not explicitly state when not to use or provide alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a generated voice to the voice library. Uses the voice ID from the text_to_voice tool.
⚠️ COST WARNING: This tool makes an API call to ElevenLabs which may incur costs. Only use when explicitly requested by the user.
| Name | Required | Description | Default |
|---|---|---|---|
| generated_voice_id | Yes | ||
| voice_name | Yes | ||
| voice_description | Yes |
| Name | Required | Description |
|---|---|---|
| type | Yes | |
| text | Yes | |
| annotations | No | |
| _meta | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool makes an API call to ElevenLabs and may incur costs, which is behavioral information beyond the annotations. It also mentions the dependency on `text_to_voice`, adding transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two brief sentences plus a warning. It is front-loaded with the purpose and has no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool adds a voice to a library, the description lacks details about the scope (e.g., user's library), side effects (e.g., overwriting), or confirmation of success. The output schema exists but the description could offer more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains that `generated_voice_id` comes from `text_to_voice`, adding context beyond the schema. However, it does not explain `voice_name` or `voice_description`, and the schema provides no descriptions, so only partial parameter semantics are covered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Add a generated voice to the voice library.' It also specifies the dependency on the `text_to_voice` tool, which distinguishes it from other 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a cost warning that advises using the tool only when explicitly requested by the user, providing a clear usage guideline. However, it does not compare with other tools like voice_clone or specify when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details about a specific conversational AI agent
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes |
| Name | Required | Description |
|---|---|---|
| type | Yes | |
| text | Yes | |
| annotations | No | |
| _meta | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and openWorldHint=true, so the description adds little behavioral context. It does not clarify what 'details' include, nor mention any rate limits, authentication requirements, or potential side effects. Given annotations cover most safety aspects, the description should add value beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but very brief. For a tool with zero parameter documentation, more detail would be warranted. It is not verbose but could be more informative without increasing length significantly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (not shown), the description might be sufficient for a basic get operation. However, the lack of parameter semantics and usage guidelines, combined with sibling tools, means the agent may need additional information to use it correctly. The openWorldHint annotation adds some context, but overall it is minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the input schema provides no description for the agent_id parameter. The description does not explain what agent_id refers to (e.g., format, where to find it). Since the parameter is required and the only input, this is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves details about a specific conversational AI agent. The verb 'Get' and resource 'details about a specific conversational AI agent' are precise, and it distinguishes from sibling tools like list_agents (which lists all agents) and create_agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use versus siblings. The name implies use when an agent_id is known, but it does not mention alternatives like list_agents for browsing or create_agent for new agents. Usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gets conversation with transcript. Returns: conversation details and full transcript. Use when: analyzing completed agent conversations.
Args:
conversation_id: The unique identifier of the conversation to retrieve, you can get the ids from the list_conversations tool.
| Name | Required | Description | Default |
|---|---|---|---|
| conversation_id | Yes |
| Name | Required | Description |
|---|---|---|
| type | Yes | |
| text | Yes | |
| annotations | No | |
| _meta | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds no behavioral traits beyond stating what is returned, which is consistent. With annotations present, the description provides minimal additional behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficient with two clear sections. It could be slightly more concise, but it remains well-structured and front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one param, output schema exists), the description adequately covers purpose and usage. It doesn't elaborate on return details, but the output schema presumably handles that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no description in schema). The description adds valuable meaning by explaining the parameter's purpose and sourcing from a sibling tool, going beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Gets conversation with transcript' with a clear verb and resource. It distinguishes from the sibling tool 'list_conversations' which only provides IDs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes 'Use when: analyzing completed agent conversations', providing explicit context for use. While it doesn't enumerate when not to use, it mentions sourcing IDs from a sibling tool, offering helpful guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a specific voice
| Name | Required | Description | Default |
|---|---|---|---|
| voice_id | Yes |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| name | Yes | |
| category | Yes | |
| fine_tuning_status | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, which signal safe read-only behavior and variable results. The description adds no further behavioral context (e.g., error handling, rate limits, or what happens if the voice does not exist). With annotations covering the core safety profile, the description provides adequate but minimal added transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no extraneous information. It is front-loaded with the verb and resource, making it immediately actionable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with one parameter and an output schema, the description captures the essential behavior. It does not mention edge cases (e.g., invalid voice_id), but the presence of an output schema and the tool's straightforward nature make it sufficiently complete. The score is slightly reduced because a note about existence or error handling would further enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description 'Get details of a specific voice' makes the single parameter voice_id clearly its identifier. The parameter name is self-explanatory, and the description reinforces the intended use, adding meaning beyond the schema's bare type definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get details of a specific voice' clearly states the verb (get) and resource (details of a specific voice). It distinguishes this retrieval tool from sibling tools like search_voices or voice_clone that perform different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. For example, it does not mention that this tool requires a known voice_id, while search_voices is used to find voices by criteria. The context signal of sibling tools highlights the absence of any comparative usage hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Isolate audio from a file. Saves output file to directory (default: $HOME/Desktop).
⚠️ COST WARNING: This tool makes an API call to ElevenLabs which may incur costs. Only use when explicitly requested by the user.
| Name | Required | Description | Default |
|---|---|---|---|
| input_file_path | Yes | ||
| output_directory | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description contradicts the readOnlyHint annotation (true) by stating it saves an output file, implying a mutation. According to guidelines, this contradiction warrants a score of 1.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences plus a cost warning, all of which are essential and free of filler. It is efficiently front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description lacks details on what 'isolate audio' means (e.g., vocal extraction), file format support, and parameter constraints. Important context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description adds minimal value by only noting the default output directory. It does not explain the input_file_path parameter requirements or the output format, leaving significant gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Isolate audio from a file' and specifies the output destination with a default. While it doesn't detail the exact nature of isolation (e.g., vocal extraction), it is sufficiently clear and distinct from sibling tools like speech_to_text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The cost warning explicitly states that the tool should only be used when the user explicitly requests it, providing clear usage guidance. However, it does not mention alternative tools or scenarios where this tool should be avoided beyond the cost.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available conversational AI agents
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| type | Yes | |
| text | Yes | |
| annotations | No | |
| _meta | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and openWorldHint, indicating safe read-only operation. The description adds 'available' but does not contradict annotations; no further behavioral detail needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with zero wasted words. Perfectly concise for the simplicity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, annotations covering safety, and likely an output schema for results, the description is complete. It covers the essential 'list all' behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100% and baseline is 4. The description does not need to add parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'all available conversational AI agents', distinguishing it from sibling tools like get_agent (single) or create_agent (creation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is for listing all agents, but does not explicitly state when to use alternatives like get_agent for a specific agent. However, given the tool's simplicity, the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists agent conversations. Returns: conversation list with metadata. Use when: asked about conversation history.
Args:
agent_id (str, optional): Filter conversations by specific agent ID
cursor (str, optional): Pagination cursor for retrieving next page of results
call_start_before_unix (int, optional): Filter conversations that started before this Unix timestamp
call_start_after_unix (int, optional): Filter conversations that started after this Unix timestamp
page_size (int, optional): Number of conversations to return per page (1-100, defaults to 30)
max_length (int, optional): Maximum character length of the response text (defaults to 10000)
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | No | ||
| cursor | No | ||
| call_start_before_unix | No | ||
| call_start_after_unix | No | ||
| page_size | No | ||
| max_length | No |
| Name | Required | Description |
|---|---|---|
| type | Yes | |
| text | Yes | |
| annotations | No | |
| _meta | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description's role in behavioral transparency is reduced. It adds some context by stating the return type (list with metadata) but does not disclose further behavioral traits like pagination behavior or time zone handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and usage, then lists parameters clearly. Minor redundancy in repeating 'optional' for each parameter, but overall efficient for the number of parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (as signaled by context), the description does not need to detail return values. It covers all key aspects: filtering, pagination, and defaults. No obvious gaps for a list endpoint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates. It explains each parameter's purpose (e.g., 'Filter conversations by specific agent ID'), specifies defaults and ranges (e.g., page_size 1-100, max_length default 10000), adding significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Lists agent conversations. Returns: conversation list with metadata.' The verb 'lists' and resource 'agent conversations' are specific and distinguish from sibling tools like 'get_conversation' (singular) and other list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says 'Use when: asked about conversation history,' providing clear context. However, it does not mention when not to use it or suggest alternatives like 'get_conversation' for a single conversation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available models
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds no additional behavioral context (e.g., rate limits, side effects). Since annotations cover the safety profile, the description neither adds nor contradicts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that is front-loaded and to the point. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and an output schema (present, not shown), the description is minimally sufficient. Could mention that it returns a list of model identifiers, but the output schema likely covers that. Adequate for a simple list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so schema_coverage is effectively 100%. The description does not need to add parameter details. Baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all available models' clearly states the action (List) and resource (models), distinguishing it from sibling tools like list_agents or list_conversations. However, it could be more specific about what constitutes a 'model' in this context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 alternatives. Implied from purpose that it is for listing models, but no exclusions or preconditions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all phone numbers associated with the ElevenLabs account
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| type | Yes | |
| text | Yes | |
| annotations | No | |
| _meta | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true and openWorldHint=true, covering safety and data volatility. The description adds no behavioral details beyond what annotations declare, providing minimal extra value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded verb 'List', no wasted words. Perfectly concise and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, rich annotations, and presence of output schema, the description is adequate. It does not mention the output explicitly, but output schema compensates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema coverage is 100%. Baseline score of 4 applies as description need not compensate for missing parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'list', resource 'phone numbers', and scope 'associated with the ElevenLabs account'. Distinguishes from sibling list tools (e.g., list_agents, list_conversations) by specifying a unique resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 alternatives. Usage is implied by the purpose but lacks context, such as linking to related tools like make_outbound_call that might rely on phone numbers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Make an outbound call using an ElevenLabs agent. Automatically detects provider type (Twilio or SIP trunk) and uses the appropriate API.
⚠️ COST WARNING: This tool makes an API call to ElevenLabs which may incur costs. Only use when explicitly requested by the user.
Args:
agent_id: The ID of the agent that will handle the call
agent_phone_number_id: The ID of the phone number to use for the call
to_number: The phone number to call (E.164 format: +1xxxxxxxxxx)
Returns:
TextContent containing information about the call
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes | ||
| agent_phone_number_id | Yes | ||
| to_number | Yes |
| Name | Required | Description |
|---|---|---|
| type | Yes | |
| text | Yes | |
| annotations | No | |
| _meta | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructive and open world hints. The description adds important context: it makes an API call to ElevenLabs (incurring costs), automatically detects provider type, and specifies the agent and phone number IDs. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is relatively concise with a clear warning front-loaded. It uses a structured list for arguments. A few sentences could be more streamlined, but overall it's efficient without unnecessary content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 required parameters and an output schema, the description covers purpose, parameters, cost warning, and provider detection. It lacks details on error handling or call state, but given the complexity and existing annotations, it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has zero description coverage (0%). The description compensates by explaining each parameter: agent_id (ID of agent), agent_phone_number_id (ID of phone number), to_number (phone number in E.164 format with example). This adds critical meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool makes an outbound call using an ElevenLabs agent. The verb 'Make' and resource 'outbound call' are specific. It distinguishes from sibling tools like text_to_speech by mentioning outbound calling and agent handling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Includes a cost warning and explicitly says 'Only use when explicitly requested by the user.' This provides clear when-to-use guidance. However, it does not mention alternative tools for related tasks (e.g., receiving calls), which would improve the score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Play an audio file. Supports WAV and MP3 formats.
| Name | Required | Description | Default |
|---|---|---|---|
| input_file_path | Yes |
| Name | Required | Description |
|---|---|---|
| type | Yes | |
| text | Yes | |
| annotations | No | |
| _meta | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true. Description adds format support info but does not disclose other behaviors (e.g., blocking, prerequisites). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no unnecessary detail. Information is front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description covers basic purpose and format support, but lacks context about output or when to use among siblings. Output schema exists but is not leveraged.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and description provides no additional meaning for the 'input_file_path' parameter beyond its name. The parameter is left underdocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool plays an audio file and specifies supported formats (WAV, MP3). It distinguishes from siblings like text_to_speech (generates) or speech_to_text (transcribes).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. Given many sibling tools, explicit recommendations or caveats would help but are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for a voice across the entire ElevenLabs voice library.
Args:
page: Page number to return (0-indexed)
page_size: Number of voices to return per page (1-100)
search: Search term to filter voices by
Returns:
TextContent containing information about the shared voices
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| page_size | No | ||
| search | No |
| Name | Required | Description |
|---|---|---|
| type | Yes | |
| text | Yes | |
| annotations | No | |
| _meta | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, indicating safe read-only operation and dynamic results. The description adds minimal behavioral context beyond that, such as 'entire voice library', which is consistent but not deeply informative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with a clear header line and a structured list of parameters and return type. Every sentence contributes value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with 3 parameters and an existing output schema, the description covers the purpose, parameter details, and return type. It is complete enough for a basic understanding, though it could clarify the difference from 'search_voices'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining each parameter's purpose: page is 0-indexed, page_size has a range (1-100), and search is a filter term. This adds meaningful context beyond the schema's type and default values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches for a voice across the entire ElevenLabs voice library with a specific verb and resource. However, it does not explicitly differentiate from the sibling tool 'search_voices', which likely has a different scope, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'search_voices'. The description lacks context on ideal use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for existing voices, a voice that has already been added to the user's ElevenLabs voice library.
Searches in name, description, labels and category.
Args:
search: Search term to filter voices by. Searches in name, description, labels and category.
sort: Which field to sort by. `created_at_unix` might not be available for older voices.
sort_direction: Sort order, either ascending or descending.
Returns:
List of voices that match the search criteria.
| Name | Required | Description | Default |
|---|---|---|---|
| search | No | ||
| sort | No | name | |
| sort_direction | No | desc |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a safe read operation (readOnlyHint) and variable results (openWorldHint). The description adds value by noting that sorting by 'created_at_unix' may not be available for older voices, a behavioral trait not covered by annotations. This is helpful for agent decision-making.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (3 sentences) and front-loaded with the core purpose. Every sentence provides necessary information without redundancy. No unnecessary words or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 parameters, list output) and the presence of an output schema, the description covers purpose, parameters, and a key behavioral detail. While it lacks mention of pagination or result limits, the openWorldHint annotation mitigates this. It is complete enough for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description fully compensates by explaining each parameter's purpose and behavior. For example, it notes that search filters name, description, labels, and category, and that sort direction orders results. This adds essential meaning beyond the schema's enum values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool searches for voices already in the user's ElevenLabs voice library, differentiating it from public library searches. It specifies searchable fields (name, description, labels, category), making the purpose precise and distinct from siblings like search_voice_library.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for the user's own voices but does not explicitly compare to alternatives or provide when-not-to-use guidance. The context is clear but lacks direct directives or exclusions, making it adequate but not exemplary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Transform audio from one voice to another using provided audio files. Saves output file to directory (default: $HOME/Desktop).
⚠️ COST WARNING: This tool makes an API call to ElevenLabs which may incur costs. Only use when explicitly requested by the user.
| Name | Required | Description | Default |
|---|---|---|---|
| input_file_path | Yes | ||
| voice_name | No | Adam | |
| output_directory | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description contradicts the readOnlyHint annotation by stating the tool makes an API call that incurs costs and saves an output file, indicating side effects. This is a severe inconsistency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using two sentences and a cost warning to convey purpose and a key constraint. Every sentence adds value, and the structure is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While an output schema exists, the description lacks details on input audio format, voice_name options, and output specifics. The annotation contradiction further undermines completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should compensate but only implicitly references input_file_path and output_directory. The voice_name parameter is not explained, leaving the agent unclear about valid values or usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool transforms audio from one voice to another using provided audio files and saves the output. This verb+resource combination effectively distinguishes it from siblings like text_to_speech.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a cost warning and explicitly advises only using the tool when requested by the user, providing clear usage guidance. It does not, however, mention alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Transcribe speech from an audio file. When save_transcript_to_file=True: Saves output file to directory (default: $HOME/Desktop). When return_transcript_to_client_directly=True, always returns text directly regardless of output mode.
⚠️ COST WARNING: This tool makes an API call to ElevenLabs which may incur costs. Only use when explicitly requested by the user.
Args:
file_path: Path to the audio file to transcribe
language_code: ISO 639-3 language code for transcription. If not provided, the language will be detected automatically.
diarize: Whether to diarize the audio file. If True, which speaker is currently speaking will be annotated in the transcription.
save_transcript_to_file: Whether to save the transcript to a file.
return_transcript_to_client_directly: Whether to return the transcript to the client directly.
output_directory: Directory where files should be saved (only used when saving files).
Defaults to $HOME/Desktop if not provided.
Returns:
TextContent containing the transcription or MCP resource with transcript data.
| Name | Required | Description | Default |
|---|---|---|---|
| input_file_path | Yes | ||
| language_code | No | ||
| diarize | No | ||
| save_transcript_to_file | No | ||
| return_transcript_to_client_directly | No | ||
| output_directory | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals that the tool saves files and makes API calls, contradicting the readOnlyHint annotation (which implies no modification). This is a clear annotation contradiction, earning the lowest score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured, starting with the main purpose, then flag behaviors, cost warning, and parameter definitions. Slightly verbose but clear and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and 6 parameters, the description covers basic usage but omits details like supported audio formats, file size limits, and language code constraints. The parameter mismatch also detracts from completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description explains each parameter's purpose. However, there is a parameter name mismatch (description uses 'file_path', schema uses 'input_file_path'), causing confusion and reducing reliability.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Transcribe speech from an audio file', providing a specific verb-resource pair. It distinguishes from sibling tools like speech_to_speech or text_to_speech by focusing on transcription.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a cost warning and advises only using when explicitly requested by the user, offering some guidance. However, it does not specify when to use this tool over alternatives (e.g., speech_to_speech) or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert text description of a sound effect to sound effect with a given duration. Saves output file to directory (default: $HOME/Desktop).
Duration must be between 0.5 and 5 seconds.
⚠️ COST WARNING: This tool makes an API call to ElevenLabs which may incur costs. Only use when explicitly requested by the user.
Args:
text: Text description of the sound effect
duration_seconds: Duration of the sound effect in seconds
output_directory: Directory where files should be saved (only used when saving files).
Defaults to $HOME/Desktop if not provided.
loop: Whether to loop the sound effect. Defaults to False.
output_format (str, optional): Output format of the generated audio. Formatted as codec_sample_rate_bitrate. So an mp3 with 22.05kHz sample rate at 32kbs is represented as mp3_22050_32. MP3 with 192kbps bitrate requires you to be subscribed to Creator tier or above. PCM with 44.1kHz sample rate requires you to be subscribed to Pro tier or above. Note that the μ-law format (sometimes written mu-law, often approximated as u-law) is commonly used for Twilio audio inputs.
Defaults to "mp3_44100_128". Must be one of:
mp3_22050_32
mp3_44100_32
mp3_44100_64
mp3_44100_96
mp3_44100_128
mp3_44100_192
pcm_8000
pcm_16000
pcm_22050
pcm_24000
pcm_44100
ulaw_8000
alaw_8000
opus_48000_32
opus_48000_64
opus_48000_96
opus_48000_128
opus_48000_192
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| duration_seconds | No | ||
| output_directory | No | ||
| output_format | No | mp3_44100_128 | |
| loop | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description contradicts annotations: annotations set readOnlyHint=true, but description reveals API calls and file saving, which are write operations. Per rubric, contradiction yields score 1.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections, but somewhat verbose. Front-loaded with purpose, though could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters with 0% schema coverage and an existing output schema, the description covers all parameters thoroughly, including constraints and defaults.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description provides detailed explanations for each parameter, including constraints, defaults, and format values, adding significant beyond-schema meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool converts text descriptions to sound effects and saves output files, using specific verbs and resources. It distinguishes from sibling tools like text_to_speech and speech_to_text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit cost warning and instruction to use only when explicitly requested by the user. Also mentions duration constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert text to speech with a given voice. Saves output file to directory (default: $HOME/Desktop).
Only one of voice_id or voice_name can be provided. If none are provided, the default voice will be used.
⚠️ COST WARNING: This tool makes an API call to ElevenLabs which may incur costs. Only use when explicitly requested by the user.
Args:
text (str): The text to convert to speech.
voice_name (str, optional): The name of the voice to use.
model_id (str, optional): The model ID to use for speech synthesis. Options include:
- eleven_multilingual_v2: High quality multilingual model (29 languages)
- eleven_flash_v2_5: Fastest model with ultra-low latency (32 languages)
- eleven_turbo_v2_5: Balanced quality and speed (32 languages)
- eleven_flash_v2: Fast English-only model
- eleven_turbo_v2: Balanced English-only model
- eleven_monolingual_v1: Legacy English model
Defaults to eleven_multilingual_v2 or environment variable ELEVENLABS_MODEL_ID.
stability (float, optional): Stability of the generated audio. Determines how stable the voice is and the randomness between each generation. Lower values introduce broader emotional range for the voice. Higher values can result in a monotonous voice with limited emotion. Range is 0 to 1.
similarity_boost (float, optional): Similarity boost of the generated audio. Determines how closely the AI should adhere to the original voice when attempting to replicate it. Range is 0 to 1.
style (float, optional): Style of the generated audio. Determines the style exaggeration of the voice. This setting attempts to amplify the style of the original speaker. It does consume additional computational resources and might increase latency if set to anything other than 0. Range is 0 to 1.
use_speaker_boost (bool, optional): Use speaker boost of the generated audio. This setting boosts the similarity to the original speaker. Using this setting requires a slightly higher computational load, which in turn increases latency.
speed (float, optional): Speed of the generated audio. Controls the speed of the generated speech. Values range from 0.7 to 1.2, with 1.0 being the default speed. Lower values create slower, more deliberate speech while higher values produce faster-paced speech. Extreme values can impact the quality of the generated speech. Range is 0.7 to 1.2.
output_directory (str, optional): Directory where files should be saved (only used when saving files).
Defaults to $HOME/Desktop if not provided.
language: ISO 639-1 language code for the voice.
output_format (str, optional): Output format of the generated audio. Formatted as codec_sample_rate_bitrate. So an mp3 with 22.05kHz sample rate at 32kbs is represented as mp3_22050_32. MP3 with 192kbps bitrate requires you to be subscribed to Creator tier or above. PCM with 44.1kHz sample rate requires you to be subscribed to Pro tier or above. Note that the μ-law format (sometimes written mu-law, often approximated as u-law) is commonly used for Twilio audio inputs.
Defaults to "mp3_44100_128". Must be one of:
mp3_22050_32
mp3_44100_32
mp3_44100_64
mp3_44100_96
mp3_44100_128
mp3_44100_192
pcm_8000
pcm_16000
pcm_22050
pcm_24000
pcm_44100
ulaw_8000
alaw_8000
opus_48000_32
opus_48000_64
opus_48000_96
opus_48000_128
opus_48000_192
Returns:
Text content with file path or MCP resource with audio data, depending on output mode.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| voice_name | No | ||
| output_directory | No | ||
| voice_id | No | ||
| stability | No | ||
| similarity_boost | No | ||
| style | No | ||
| use_speaker_boost | No | ||
| speed | No | ||
| language | No | en | |
| output_format | No | mp3_44100_128 | |
| model_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint: true contradicts the description, which states the tool makes API calls and saves files (write operations). Per scoring guidelines, description contradicts annotations, so score is 1. 'Annotation Contradiction' flag is true.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose and includes a full Python docstring format with Args and Returns sections. While well-structured and front-loaded with key constraints, it is longer than necessary and could be condensed by moving parameter details to the schema, which is empty.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (12 parameters) and the existence of an output schema, the description is quite complete. It covers purpose, usage constraints, parameter details, output variations, and a cost warning. However, it does not fully describe the return value format, lacking specifics about the MCP resource structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides extensive explanations for most parameters: ranges for stability, speed, etc.; default values for model_id, output_format; and lists of valid options for model_id and output_format. This adds significant meaning beyond the bare schema, justifying a score of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Convert text to speech with a given voice. Saves output file to directory.' It specifies the verb (convert), resource (text to speech), and side effect (file saving). This distinguishes it from sibling tools like speech_to_text or speech_to_speech.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a constraint 'Only one of voice_id or voice_name can be provided' and a cost warning 'Only use when explicitly requested by the user.' However, it does not explicitly contrast with sibling tools like text_to_voice or speech_to_speech, so usage guidelines are clear but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create voice previews from a text prompt. Creates three previews with slight variations. Saves output file to directory (default: $HOME/Desktop).
If no text is provided, the tool will auto-generate text.
Voice preview files are saved as: voice_design_(generated_voice_id)_(timestamp).mp3
Example file name: voice_design_Ya2J5uIa5Pq14DNPsbC1_20250403_164949.mp3
⚠️ COST WARNING: This tool makes an API call to ElevenLabs which may incur costs. Only use when explicitly requested by the user.
| Name | Required | Description | Default |
|---|---|---|---|
| voice_description | Yes | ||
| text | No | ||
| output_directory | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations set readOnlyHint=true but description describes creating files and making API calls, contradicting the annotation. Description adds useful behavioral details (auto-text, file naming, cost), but the contradiction severely undermines trust.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, includes file naming example and cost warning. Could be slightly tighter, but overall well-structured and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers key aspects: output files, default directory, auto-generation, cost. Missing description of voice_description parameter. Output schema exists but not referenced.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It explains text and output_directory behavior (auto-generation, default path) but fails to describe the required voice_description parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it creates voice previews from text, with three variations and file saving. Differentiates from siblings like text_to_speech by mentioning previews and variations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly warns about cost and instructs to use only when user explicitly requests, providing clear usage context. Lacks explicit mention of alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create an instant voice clone of a voice using provided audio files.
⚠️ COST WARNING: This tool makes an API call to ElevenLabs which may incur costs. Only use when explicitly requested by the user.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| files | Yes | ||
| description | No |
| Name | Required | Description |
|---|---|---|
| type | Yes | |
| text | Yes | |
| annotations | No | |
| _meta | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=false and openWorldHint=true. The description adds a cost warning for the external ElevenLabs API call, which is valuable behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences front-loaded with the core purpose and a critical warning. Every word adds value, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the cost warning is present, the description lacks details on what the clone can be used for, output schema, or how it differs from similar tools like create_voice_from_preview. Given an output schema exists, return value explanation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only hints that files are audio files, but provides no details on the name or description parameters. This is insufficient for a 3-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates an instant voice clone from provided audio files. It uses a specific verb (Create) and resource (voice clone), and distinguishes itself from siblings like create_voice_from_preview by emphasizing instant cloning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly warns about costs and instructs only to use when explicitly requested by the user. This provides clear when-to-use guidance, though it doesn't mention alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0add_knowledge_base_to_agentcheck_subscriptioncompose_musiccreate_agentcreate_composition_plancreate_voice_from_previewget_agentget_conversationget_voiceisolate_audiolist_agentslist_conversationslist_modelslist_phone_numbersmake_outbound_callplay_audiosearch_voice_librarysearch_voicesspeech_to_speechspeech_to_texttext_to_sound_effectstext_to_speechtext_to_voicevoice_cloneMost tools target distinct actions and resources, but `search_voice_library` and `search_voices` are similarly named and could cause confusion despite different scopes. Overall, tools are well-differentiated.
Tool names follow a verb_noun pattern consistently, with only minor variations like prepositions (e.g., 'add_knowledge_base_to_agent'). The pattern is predictable and readable.
24 tools cover a broad set of ElevenLabs features (TTS, STT, voice management, agents, calls, music, etc.). While on the higher side, it remains scoped to the service without excessive redundancy.
The tool set covers many core operations but lacks update and delete functionality for agents, voices, and other resources. Basic CRUD is incomplete, though major workflows are present.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Official MCP server for OmniDimension. Drive voice agents, dispatch calls, and run bulk campaigns.
Official MCP server for Lovable, the AI-powered full-stack app builder.
Official Microsoft Learn MCP Server – real-time, trusted docs & code samples for AI and LLMs.
AI voice generation: text-to-speech and voice cloning from any MCP client.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/brandon-fryslie/vibedungeon-voice'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
