Fonoster MCP Serverofficial
A
licenseNot graded
qualityB
maintenanceMCP server that lists applications and phone numbers, and initiates outbound calls via Fonoster.
22 npm
8,097
MIT
elevenlabs-agents-mcp-server
Allows placing outbound telephone calls via ElevenLabs Conversational AI agents, retrieving call reports (status, success evaluation, summary, transcript), and managing agents and phone numbers.
Enables outbound calls over a Vonage SIP trunk by integrating with ElevenLabs agents for telephony.
Click on "Deploy 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-agents-mcp-serverCall +15551234567 with agent 'Support' on number 'Office'"
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-agents-mcp-server
MCP server that lets Claude place outbound telephone calls via ElevenLabs Agents (Conversational AI) over a SIP trunk (e.g. Vonage) and report the outcome — status, success evaluation, summary, extracted data, and full transcript.
Tools
Tool | Purpose |
| Discover agent IDs |
| Discover SIP trunk phone number IDs |
| Place a call (returns |
| Poll until the call ends, then return the outcome report |
| Compact outcome report (status, |
| Turn-by-turn transcript with pagination |
| Recent calls with filters (agent, outcome, time window) |
Typical flow: list_agents → list_phone_numbers → make_outbound_call → wait_for_call_completion → (optionally) get_call_transcript.
Related MCP server: leximo-ai-call-assistant-mcp-server
Setup
npm install
npm run buildClaude Desktop / Claude Code config
{
"mcpServers": {
"elevenlabs-agents": {
"command": "node",
"args": ["/absolute/path/to/elevenlabs-agents-mcp-server/dist/index.js"],
"env": {
"ELEVENLABS_API_KEY": "sk_..."
}
}
}
}Claude Code: claude mcp add elevenlabs-agents -e ELEVENLABS_API_KEY=sk_... -- node /path/to/dist/index.js
Vonage SIP trunk prerequisites (one-time, in dashboards — not via this server)
Vonage: create a SIP trunk / programmable SIP domain. For outbound-from-ElevenLabs you need a termination endpoint (hostname) that accepts SIP INVITEs from ElevenLabs, with digest auth credentials. Allow signaling from
sip.rtc.elevenlabs.io(or your region's static SIP endpoint).ElevenLabs → Phone Numbers → Import from SIP trunk: enter your Vonage number (E.164), outbound address (Vonage termination hostname), transport (TLS recommended), and SIP credentials.
Assign or note the agent; the imported number's
phone_number_idis whatelevenlabs_make_outbound_calluses asagent_phone_number_id.Analysis fields (
call_successful, summary, data collection) require evaluation criteria / data collection configured on the agent.
Environment variables
ELEVENLABS_API_KEY(required)ELEVENLABS_API_BASE_URL(optional, defaulthttps://api.elevenlabs.io; use residency endpoints if applicable)
Notes
make_outbound_callis asynchronous — the API returns as soon as the call is initiated. Post-call analysis is only available once status isdone(there is a shortprocessingwindow after hang-up).wait_for_call_completioncaps at 900 s per invocation and tells you if it timed out so you can call it again.Dynamic variables passed to
make_outbound_callare available in the agent's prompt as{{variable_name}}.
Available Tools
7 toolselevenlabs_get_call_reportGet Call Outcome ReportARead-onlyIdempotent
Get a compact outcome report for a call/conversation: status, success evaluation, summary, duration, termination reason, extracted data-collection results, and evaluation criteria results. Does NOT include the transcript (use elevenlabs_get_call_transcript).
Note: analysis fields (call_successful, summary, data collection) are only populated after the call ends and post-call processing completes (status 'done'). If status is 'initiated'/'in-progress'/'processing', poll again or use elevenlabs_wait_for_call_completion.
Args:
conversation_id (string)
Returns JSON: { conversation_id, status, call_successful, summary, duration_secs, termination_reason, error, cost_credits, evaluation_criteria_results, data_collection_results, transcript_turns, has_audio }
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| conversation_id | Yes | Conversation ID returned by elevenlabs_make_outbound_call |
TDQS
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, idempotentHint, and non-destructive behavior. The description adds crucial context that analysis fields are only populated after call completion and post-processing (status 'done'), which aligns with and enhances the annotations. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement, a note about limitations, and separate Args/Returns sections. While slightly lengthy, every sentence adds value and nothing is wasted.
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?
With one parameter and no output schema, the description fully covers the return fields and polling behavior. It provides enough detail for an agent to understand when to use the tool and how to interpret results.
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?
Schema coverage is 100%, and the description explicitly lists the parameter 'conversation_id (string)' in the Args section, adding context that it is the ID returned by elevenlabs_make_outbound_call. This adds meaning beyond the schema's description.
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 returns a compact outcome report including status, success evaluation, summary, and other specific fields. It distinguishes itself from the sibling tool elevenlabs_get_call_transcript by explicitly stating it does not include the transcript.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit guidance on when to use this tool (to get call outcome) and when not to (use elevenlabs_get_call_transcript for transcript). It also advises on polling behavior if the call is not yet complete, directing to use elevenlabs_wait_for_call_completion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
elevenlabs_get_call_transcriptGet Call TranscriptARead-onlyIdempotent
Get the turn-by-turn transcript of a call.
Args:
conversation_id (string)
offset / limit: pagination over turns (default 0 / 200)
include_tool_calls (boolean): default false
Returns JSON: { conversation_id, status, total_turns, has_more, turns: [{ index, role, time_in_call_secs, message }] }
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max turns to return (default 200) | |
| offset | No | Turn index to start from (pagination) | |
| conversation_id | Yes | Conversation ID | |
| include_tool_calls | No | Include agent tool call details in each turn |
TDQS
A4.5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent behavior. The description adds valuable context: pagination via offset/limit (max 500), a boolean to include tool calls, and the return structure including 'has_more' for pagination. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a clear purpose sentence, a bulleted argument list, and the return format. Every sentence is necessary and adds value without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich annotations and 100% schema coverage, the description is complete enough. It covers pagination, optional parameters, and return structure, leaving no critical gaps for an agent to invoke the tool correctly.
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?
Schema coverage is 100% with each parameter described. The description groups offset/limit as pagination and documents the return JSON structure, which adds meaningful context beyond the schema's individual parameter descriptions.
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 'Get the turn-by-turn transcript of a call,' which is a specific verb and resource. It differentiates from the sibling tool 'elevenlabs_get_call_report' by focusing on turn-by-turn details rather than a summary report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving call transcripts, but it does not provide explicit guidance on when to use this tool versus alternatives like 'elevenlabs_get_call_report' or specify conditions for not using it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
elevenlabs_list_agentsList ElevenLabs AgentsARead-onlyIdempotent
List conversational AI agents in the ElevenLabs workspace.
Use this first to discover the agent_id needed by elevenlabs_make_outbound_call.
Args:
search (string, optional): filter by agent name
page_size (number): 1-100, default 30
cursor (string, optional): pagination cursor
Returns JSON: { agents: [{ agent_id, name, created_at_unix_secs }], has_more, next_cursor }
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| cursor | No | Pagination cursor from a previous response's next_cursor | |
| search | No | Optional name filter, e.g. 'Jack' | |
| page_size | No | Max agents to return (1-100, default 30) |
TDQS
A4.1/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds pagination behavior and return format, which is helpful but not critical beyond annotations. No contradictions.
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 three concise blocks: purpose/usage, parameter list, return format. Every sentence adds value with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity, full schema coverage, and no output schema, the description explains the return format, pagination, and relationship to outbound calls completely. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains all parameters. The description summarizes them concisely but adds no new semantic meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the verb 'list', the resource 'conversational AI agents in the ElevenLabs workspace', and connects to the sibling tool by noting it discovers agent_id for elevenlabs_make_outbound_call. This distinguishes it clearly from other listed tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a direct usage guideline: 'Use this first to discover the agent_id needed by elevenlabs_make_outbound_call.' While it doesn't explicitly state when not to use it, the context is clear and the sibling list provides alternative tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
elevenlabs_list_callsList Recent CallsARead-onlyIdempotent
List recent conversations/calls, newest first, with optional filters.
Args:
agent_id (string, optional)
call_successful ('success' | 'failure' | 'unknown', optional)
call_start_after_unix / call_start_before_unix (number, optional)
page_size (1-100, default 30), cursor (string, optional)
Returns JSON: { calls: [{ conversation_id, agent_id, agent_name, status, call_successful, start_time_unix_secs, call_duration_secs, direction }], has_more, next_cursor }
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| cursor | No | Pagination cursor | |
| agent_id | No | Filter by agent | |
| page_size | No | ||
| call_successful | No | Filter by evaluated call outcome | |
| call_start_after_unix | No | Only calls starting after this unix timestamp (seconds) | |
| call_start_before_unix | No | Only calls starting before this unix timestamp (seconds) |
TDQS
A4.1/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly and idempotent; description adds pagination details (has_more, next_cursor, ordering newest first) and return format, providing valuable context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with clear Args and Returns sections, front-loaded with purpose, and no unnecessary content.
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?
With no output schema, the description fully explains the return structure, including call object fields, pagination. Annotations are rich, making the tool well-documented.
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 83%, so baseline is 3. Description provides concise summaries (e.g., default page_size) but does not add significant meaning beyond schema.
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 lists recent conversations/calls, newest first, with optional filters. It distinguishes from siblings by specifying the resource and ordering.
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 when to use (listing calls) but does not explicitly mention when not to use or alternatives like get_call_report for details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
elevenlabs_list_phone_numbersList ElevenLabs Phone NumbersARead-onlyIdempotent
List phone numbers imported into ElevenLabs (including SIP trunk numbers, e.g. a Vonage SIP trunk DID).
Use this to discover the agent_phone_number_id required by elevenlabs_make_outbound_call. SIP trunk numbers have provider 'sip_trunk'.
Args: none
Returns JSON: { phone_numbers: [{ phone_number_id, phone_number, label, provider, assigned_agent }] }
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A4.3/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds that SIP trunk numbers have provider 'sip_trunk' and return format, but this is modest 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise with two sentences plus return schema. No fluff, well-structured and front-loaded. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and rich annotations, the description provides the return format and context about SIP trunk numbers. It is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters and schema coverage is 100%. Baseline for 0 parameters is 4; the description does not add parameter info but is not 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?
Description clearly states it lists phone numbers imported into ElevenLabs, including SIP trunk numbers. It also specifies the purpose of discovering agent_phone_number_id for outbound calls, distinguishing it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use this to find agent_phone_number_id for elevenlabs_make_outbound_call. Provides context about SIP trunk numbers. Lacks explicit when-not guidance, but is otherwise clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
elevenlabs_make_outbound_callPlace Outbound Call (SIP Trunk)A
Place an outbound telephone call via an ElevenLabs agent over a SIP trunk (e.g. Vonage).
This starts the call and returns immediately — it does NOT wait for the call to finish. To get the outcome, follow up with elevenlabs_wait_for_call_completion using the returned conversation_id.
Args:
agent_id (string): agent that will speak on the call
agent_phone_number_id (string): SIP trunk number ID to originate from
to_number (string): destination in E.164 format, e.g. +61355551234
dynamic_variables (object, optional): variables for the agent's prompt
first_message_override (string, optional)
prompt_override (string, optional; agent must allow overrides)
Returns JSON: { success, message, conversation_id, sip_call_id } Save conversation_id — it is needed to retrieve the outcome and transcript.
Error handling: 422 usually means a bad to_number format or invalid IDs.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes | Agent to place the call (from elevenlabs_list_agents) | |
| to_number | Yes | Destination number in E.164 format, e.g. +61355551234 | |
| prompt_override | No | Override the agent's system prompt for this call (requires overrides enabled in the agent's security settings) | |
| dynamic_variables | No | Key/value variables injected into the agent's prompt/first message, e.g. { customer_name: 'Dave', order_id: '123' } | |
| agent_phone_number_id | Yes | SIP trunk phone number ID to call from (from elevenlabs_list_phone_numbers) | |
| first_message_override | No | Override the agent's configured first message for this call |
TDQS
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the async behavior (returns immediately, does not wait for call to finish), the return JSON structure, and error handling. Annotations already indicate it is a mutation (readOnlyHint=false), and the description adds more context without contradiction.
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?
Well-structured with a clear purpose, then args and returns sections. Every sentence adds value, no fluff. Front-loaded with the critical async behavior.
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 tool with no output schema, the description explains the return format and necessary follow-up. It covers prerequisites (agent must allow overrides) and references sibling tools appropriately. Comprehensive for an async initiation tool.
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?
Schema coverage is 100% with parameter descriptions, but the description adds extra context for parameters like dynamic_variables (variables for agent's prompt) and prompt_override (requires agent to allow overrides). This goes beyond the schema, though the schema already does well.
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 'Place an outbound telephone call via an ElevenLabs agent over a SIP trunk' with specific verbs and resources. It distinguishes from siblings by noting it initiates the call and returns immediately, whereas other tools retrieve reports or wait for completion.
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?
Explicitly states the call starts and returns immediately, with a clear instruction to follow up with elevenlabs_wait_for_call_completion using the returned conversation_id. Also provides error handling guidance. Does not explicitly mention when not to use, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
elevenlabs_wait_for_call_completionWait for Call Completion and Report OutcomeARead-only
Block until a call reaches a terminal status ('done' or 'failed') or the timeout elapses, then return the outcome report (same shape as elevenlabs_get_call_report).
This is the recommended follow-up after elevenlabs_make_outbound_call: place the call, then call this to get the result in one step.
Args:
conversation_id (string)
timeout_secs (number): default 300
poll_interval_secs (number): default 5
Returns JSON: { timed_out, waited_secs, ...outcome report } If timed_out is true, the call is still in progress — call this tool again to keep waiting.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| timeout_secs | No | Max seconds to wait (10-900, default 300) | |
| conversation_id | Yes | Conversation ID returned by elevenlabs_make_outbound_call | |
| poll_interval_secs | No | Seconds between polls (2-60, default 5) |
TDQS
A4.4/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses blocking behavior, terminal statuses, timeout handling, and that the tool can be called again if timed_out. Annotations (readOnlyHint=true, etc.) align with description; no contradictions.
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?
Extremely concise: main paragraph followed by Args and Returns sections. Front-loaded with key behavior, no waste.
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?
No output schema, so description correctly explains return JSON shape and timeout behavior. Could mention idempotency, but annotations handle that. Minor gap: no mention of error cases.
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?
Input schema has 100% description coverage, so baseline is 3. Description adds default values and context (e.g., 'seconds between polls') but does not significantly extend schema info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool blocks until a call reaches terminal status or timeout, then returns outcome report. It distinguishes itself from siblings like elevenlabs_get_call_report by emphasizing it waits for completion.
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?
Explicitly recommends use as follow-up to elevenlabs_make_outbound_call, providing workflow clarity. Does not mention when not to use, but context is clear.
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.
7 tool updates
v1.0.0- First observed
elevenlabs_get_call_report - First observed
elevenlabs_get_call_transcript - First observed
elevenlabs_list_agents - First observed
elevenlabs_list_calls - First observed
elevenlabs_list_phone_numbers - First observed
elevenlabs_make_outbound_call - First observed
elevenlabs_wait_for_call_completion
TDQS
A4.4/5.0
Scored across 7 tools
Disambiguation5/5
Each tool has a unique, well-defined purpose: call reports, transcripts, agent listing, call listing, phone number listing, making calls, and waiting for completion. No overlap in functionality.
Naming Consistency5/5
All tools follow the 'elevenlabs_verb_noun' pattern with snake_case, e.g., elevenlabs_get_call_report, elevenlabs_list_agents. Perfectly consistent.
Tool Count5/5
Seven tools is a tight set covering listing, call initiation, and post-call retrieval. No redundant tools, and scope is well-defined for an outbound call management server.
Completeness4/5
The workflow is complete: discover agents/numbers, place call, wait, get results. Minor gaps like no tool to create or update agents/numbers, but those may be out of scope.
Maintenance
ActivityStale
ResponsivenessNo issues
Related MCP Connectors
Official MCP server for OmniDimension. Drive voice agents, dispatch calls, and run bulk campaigns.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
MCP server that lets AI assistants use all OneSchema features exposed via the public API.
Related MCP Servers
- AlicenseAqualityFmaintenanceAn MCP server that lets you schedule AI phone calls and manage Leximo assignments directly from Claude Desktop or Claude Code.1325 npm2MIT
- AlicenseAqualityCmaintenanceAn MCP server that connects Claude to a 3CX Phone System (V20+), enabling user management, call monitoring, contact search, and forwarding configuration.22MIT
- FlicenseNot gradedqualityCmaintenanceMCP server giving Claude full control over ElevenLabs Conversational AI agents, conversations, knowledge base, tools, tests, telephony, and workspace settings.-
