模型上下文协议 (MCP) 是一种开放标准，使 AI 系统能够与各种数据源和工具无缝交互，促进安全的双向连接。
由 Anthropic 开发的模型上下文协议 (MCP) 使 Claude 等 AI 助手能够与 VOYP 的通话功能无缝集成。这种集成使 AI 模型能够拨打电话并监控通话进度。
Voyp MCP 服务器允许您：
构建强大的调用上下文以供调用时使用
在致电餐馆、牙医等时搜索商业信息...
致电预约、预订、咨询、询问等……
提供通话状态
挂断电话
在使用 Voyp 之前，您需要：
您还需要购买通话时使用的点数。您也可以在这里购买点数
Claude Desktop 、 Goose或其他兼容客户端
Node.js （v20 或更高版本）
您可以通过运行以下命令来验证您的 Node.js 安装：
node --version
已安装Git （仅在使用 Git 安装方法时才需要）
在 macOS 上： brew install git
在 Linux 上：
Debian/Ubuntu： sudo apt install git
RedHat/CentOS： sudo yum install git
在 Windows 上：下载适用于 Windows 的 Git
Related MCP server: bubblyphone-agents
要安装 voyp-mcp 服务器，您需要手动添加扩展。
Voyp + Goose演示：
要安装 voyp-mcp 服务器，您可以使用以下方法：
通过 Smithery 安装
使用 NPX 运行
Git 安装
要通过Smithery自动为 Claude Desktop 安装 Voyp 模型上下文协议服务器：
npx -y @smithery/cli install @paulotaylor/voyp-mcp --client claudenpx -y voyp-mcp@0.1.0 虽然您可以单独启动服务器，但单独使用并没有太大用处。您应该将其集成到 MCP 客户端中。以下是如何配置 Claude 桌面应用程序与 voyp-mcp 服务器配合使用的示例。
# Create the config file if it doesn't exist
touch "$HOME/Library/Application Support/Claude/claude_desktop_config.json"
# Opens the config file in TextEdit
open -e "$HOME/Library/Application Support/Claude/claude_desktop_config.json"
# Alternative method using Visual Studio Code (requires VS Code to be installed)
code "$HOME/Library/Application Support/Claude/claude_desktop_config.json"code %APPDATA%\Claude\claude_desktop_config.json将your-VOYP-api-key替换为您的实际VOYP API 密钥。
{
"mcpServers": {
"voyp-mcp": {
"command": "npx",
"args": ["-y", "voyp-mcp"],
"env": {
"VOYP_API_KEY": "your-VOYP-api-key"
}
}
}
}克隆存储库：
git clone https://github.com/paulotaylor/voyp-mcp.git
cd voyp-mcp安装依赖项：
npm install构建项目：
npm run build按照上面配置 Claude 桌面应用程序部分中概述的配置步骤，使用以下 JSON 配置。
将your-VOYP-api-key-here替换为您实际的VOYP API 密钥，将/path/to/voyp-mcp替换为您在系统上克隆存储库的实际路径。
{
"mcpServers": {
"voyp": {
"command": "npx",
"args": ["/path/to/voyp-mcp/build/index.js"],
"env": {
"VOYP_API_KEY": "your-VOYP-api-key"
}
}
}
}安装完成并配置好 Claude 桌面应用程序后，您必须完全关闭并重新打开 Claude 桌面应用程序才能查看 voyp-mcp 服务器。您应该会在应用程序左下方看到一个锤子图标，表示可用的 MCP 工具，您可以点击该锤子图标查看有关 start_call 和 hangup_call 工具的更多详细信息。
现在 claude 将可以完全访问 voyp-mcp 服务器，包括 start_call 和 hangup_call 工具。
Voyp + Claude 桌面演示：
未找到服务器
通过运行npm --verison来验证 npm 安装
通过运行code ~/Library/Application\ Support/Claude/claude_desktop_config.json检查 Claude Desktop 配置语法
通过运行node --version确保正确安装了 Node.js
NPX 相关问题
如果遇到与npx相关的错误，则可能需要使用 npx 可执行文件的完整路径。
您可以通过在终端中运行which npx来找到此路径，然后在配置中将"command": "npx"行替换为"command": "/full/path/to/npx" 。
API 密钥问题
确认您的 VOYP API 密钥有效
检查配置中的 API 密钥是否正确设置
验证 API 密钥周围没有空格或引号
Retrieve call details
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Call Id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Retrieve' implies a read operation, but the description doesn't specify whether this requires authentication, what happens if the call ID is invalid, or any rate limits. It lacks crucial behavioral context for a tool that presumably accesses sensitive call data.
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 at just two words, which is appropriate for a simple retrieval tool. However, it's arguably too brief given the lack of behavioral context and usage guidelines. It's front-loaded but under-specified rather than efficiently comprehensive.
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 that retrieves call details with no annotations and no output schema, the description is insufficient. It doesn't explain what 'details' include, the format of returned data, error conditions, or authentication requirements. Given the sensitivity of call data and the existence of related sibling tools, more context is needed.
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 100% description coverage with the 'id' parameter documented as 'Call Id'. The description adds no additional parameter information beyond what's already in the schema. With high schema coverage, the baseline score of 3 is appropriate as the schema does the heavy lifting.
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 'Retrieve call details' clearly states the action (retrieve) and resource (call details), but it's vague about what specific details are retrieved and doesn't distinguish this from potential sibling tools like 'get_user' or 'start_call'. It provides basic purpose but lacks specificity.
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. With sibling tools like 'hangup_call' and 'start_call' that also relate to calls, there's no indication of when retrieval is appropriate versus other call-related operations. No usage context or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve user profile
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Retrieve' implies a read operation, but it doesn't disclose behavioral traits such as authentication needs, rate limits, error handling, or what 'user profile' entails (e.g., fields returned). For a tool with zero annotation coverage, this is inadequate, leaving significant gaps in understanding how it behaves.
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, efficient sentence ('Retrieve user profile') with zero waste. It's front-loaded and appropriately sized for a simple tool, making it easy to parse quickly without unnecessary elaboration.
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 (simple retrieval tool), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what 'user profile' includes, potential return values, or any behavioral context. For a tool with no structured data to rely on, this minimal description fails to provide sufficient completeness for effective use.
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 parameters with 100% coverage, meaning no parameters are documented in the schema. The description doesn't add parameter details, but since there are no parameters, this is acceptable. Baseline is 4 for 0 parameters, as no additional semantics are needed beyond the schema's completeness.
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 'Retrieve user profile' clearly states the verb ('retrieve') and resource ('user profile'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'get_call' or 'search_place', which would require a 5. The description is specific but lacks sibling distinction.
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. With siblings like 'search_place' and 'search_places' that might involve user-related queries, there's no indication of context, prerequisites, or exclusions. It's a basic statement with no usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Hangup an existing call
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ID of the call |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the action without disclosing behavioral traits. It doesn't mention if this is destructive (likely yes for hanging up), requires specific permissions, has side effects, or what happens post-execution (e.g., call termination confirmation).
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, efficient sentence with zero waste, front-loading the core action. It's appropriately sized for a simple tool, earning its place without unnecessary elaboration.
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 destructive tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral impact (e.g., what 'hangup' entails), error conditions, or return values, leaving significant gaps in understanding the tool's full 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?
Schema description coverage is 100%, so the schema already documents the 'id' parameter fully. The description adds no additional meaning beyond implying the call must exist, which is minimal value. Baseline 3 is appropriate as the schema does the heavy lifting.
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 ('hangup') and target ('an existing call'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'start_call' or 'get_call' beyond the obvious action difference, missing explicit comparison.
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. The description doesn't mention prerequisites (e.g., needing an active call), exclusions, or comparisons to siblings like 'start_call' or 'get_call', leaving usage context implied at best.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search place details in a given location
| Name | Required | Description | Default |
|---|---|---|---|
| place | Yes | Name of place to search. Ex: The Lane Salon | |
| location | Yes | Place location. Ex: San Francisco, CA |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but provides minimal behavioral context. It doesn't disclose whether this is a read-only operation, what data sources are used, rate limits, authentication needs, or what 'details' include. The phrase 'search place details' implies a lookup but lacks specificity.
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, efficient sentence with zero waste. It's front-loaded with the core purpose and appropriately sized for a simple search 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?
For a search tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'details' are returned, potential limitations, or error conditions. Given the lack of structured data, more context is needed for effective use.
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 100%, so the schema fully documents both parameters. The description adds no additional meaning beyond implying that 'location' contextualizes the search, which is already clear from the schema. Baseline 3 is appropriate as the schema does the heavy lifting.
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 ('search') and resource ('place details'), specifying the scope ('in a given location'). It distinguishes from sibling 'search_places' by focusing on details rather than general search, but doesn't explicitly differentiate from 'search_place_by_number'.
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_places' or 'search_place_by_number'. The description implies usage for detailed place searches but offers no explicit comparison or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find place name and address by phone number
| Name | Required | Description | Default |
|---|---|---|---|
| number | Yes | Phone number in E.164 format. Ex: +1234567890 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'finds' information, implying a read-only operation, but doesn't clarify if it requires authentication, has rate limits, returns partial or full results, or handles errors. For a tool with no annotations, this leaves significant gaps in understanding its behavior beyond the basic purpose.
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, efficient sentence: 'Find place name and address by phone number.' It is front-loaded with the core purpose, uses clear language, and avoids unnecessary words. Every part of the sentence earns its place by conveying essential information without waste.
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 (simple lookup with one parameter) and the lack of annotations and output schema, the description is minimally complete. It states what the tool does but doesn't cover behavioral aspects like response format, error handling, or prerequisites. For a basic search tool, this is adequate but leaves room for improvement in providing a fuller 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 input schema has 100% description coverage, with the parameter 'number' documented as 'Phone number in E.164 format. Ex: +1234567890.' The description adds no additional meaning beyond this, as it only mentions 'phone number' without specifying format or constraints. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, indicating adequate but not enhanced parameter understanding.
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: 'Find place name and address by phone number.' It specifies the verb ('find') and the resources ('place name and address'), making it easy to understand what the tool does. However, it doesn't explicitly distinguish this tool from sibling tools like 'search_place' or 'search_places' (which might search by other criteria), so it doesn't reach the highest score.
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. It doesn't mention sibling tools like 'search_place' or 'search_places', nor does it specify scenarios where this tool is preferred (e.g., when you have a phone number but not other place details). Without any usage context or exclusions, it offers minimal help in tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search places in a given location
| Name | Required | Description | Default |
|---|---|---|---|
| search | Yes | Places to search. Ex: italian restaurants in New York City, US |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('Search') but doesn't cover critical aspects like whether this is a read-only operation, potential rate limits, authentication needs, or what the search results might include (e.g., format, pagination). This is a significant gap for a search tool with zero annotation coverage.
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, efficient sentence ('Search places in a given location') that is front-loaded and wastes no words. It directly communicates the core function without unnecessary elaboration, earning a perfect score for conciseness.
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 lack of annotations and output schema, the description is incomplete. It doesn't explain what the search returns (e.g., list of places, details), how results are structured, or any behavioral traits like error handling. For a search tool with no structured support, this leaves the agent under-informed.
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 100% description coverage, with the 'search' parameter documented as 'Places to search. Ex: italian restaurants in New York City, US.' The description adds no additional meaning beyond this, as it doesn't elaborate on syntax or constraints. With high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Search places in a given location,' which includes a specific verb ('Search') and resource ('places'). However, it doesn't explicitly differentiate from sibling tools like 'search_place' or 'search_place_by_number,' which appear to be similar search operations, preventing a perfect score.
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. With sibling tools like 'search_place' and 'search_place_by_number' available, there is no indication of context, prerequisites, or exclusions, leaving the agent to guess based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a new phone call via Voyp API. The API returns the call id and a URL where users can track the progress of the call
| Name | Required | Description | Default |
|---|---|---|---|
| number | Yes | Phone number to call in E.164 format | |
| language | No | Language of the call. Ex: en-US, pt-PT, fr-FR | |
| context | Yes | Context of the call. Ex: Order a pizza |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that the API returns a call id and tracking URL, which adds some context about outputs. However, it fails to disclose critical traits like whether this is a mutating operation (implied by 'Start'), potential side effects (e.g., initiating a real phone call), error handling, or rate limits. For a tool with zero annotation coverage, this leaves significant gaps.
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 appropriately sized with two sentences that are front-loaded: the first states the purpose, and the second explains the return values. There is no wasted text, making it efficient. However, it could be slightly more structured by explicitly separating purpose from behavioral details, keeping it at 4 rather than 5.
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 of initiating a phone call (a mutating operation with real-world effects), no annotations, and no output schema, the description is incomplete. It lacks details on permissions, error cases, what the tracking URL entails, or how to handle the call id. For a tool with 3 parameters and significant behavioral implications, this is inadequate.
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 100%, meaning the input schema fully documents parameters like 'number', 'language', and 'context'. The description adds no additional meaning beyond what the schema provides, such as examples or usage notes for parameters. Baseline is 3 when the schema does the heavy lifting, but no extra value is added.
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 ('Start a new phone call') and resource ('via Voyp API'), with the verb 'Start' being specific. It distinguishes from siblings like 'get_call' or 'hangup_call' by indicating creation rather than retrieval or termination. However, it doesn't explicitly differentiate from all siblings (e.g., 'search_place' tools), keeping it at 4 rather than 5.
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. It doesn't mention prerequisites, such as authentication or account setup, or compare to sibling tools like 'get_call' for retrieving call details. Usage is implied by the action but lacks explicit context or exclusions.
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.
v1.0.0get_callget_userhangup_callsearch_placesearch_place_by_numbersearch_placesstart_callScored across 7 tools
The tools have some clear distinctions, such as get_call vs. hangup_call vs. start_call for call operations, but there is significant overlap between search_place, search_places, and search_place_by_number, which could cause confusion about which to use for location-based searches. The descriptions help clarify, but the boundaries are not perfectly distinct.
Most tools follow a consistent verb_noun pattern (e.g., get_call, get_user, hangup_call, start_call), with clear and readable naming. However, the search tools have minor deviations (search_place, search_places, search_place_by_number), which slightly disrupts the pattern but remains mostly consistent.
With 7 tools, the count is well-scoped for a server focused on phone calls and place searches. Each tool appears to serve a specific purpose without unnecessary duplication, fitting within the typical 3-15 range for a coherent toolset.
For call operations, there is good coverage with get, start, and hangup, but missing update or list operations for calls or users could be a gap. For place searches, the tools cover various search methods, but without create or delete operations, the surface feels incomplete for a full lifecycle in the domain.
The Telnyx MCP server is an official implementation of the Model Context Protocol that enables AI clients (like Claude Desktop, Cursor, and OpenAI Agents) to interact with Telnyx's telephony, messaging, and AI assistant APIs. It provides comprehensive capabilities including making and managing phone calls, sending SMS/MMS messages, purchasing and configuring phone numbers, creating AI assistants with custom instructions, managing cloud storage buckets, scraping and embedding website content, and handling integration secrets. The server exists as both a local implementation and a remotely hosted version, allowing developers to integrate real-world communication infrastructure directly into AI applications.
Hosted MCP server connecting AI assistants to 9,000+ apps and 40,000+ actions via Zapier.
Give AI agents real phone numbers, messages, and voice calls via MCP.
Discover and call 10,000+ production APIs from one MCP server. Pay-per-call billing for AI agents.
