ClickSend MCP Server
ClickSend MCP 服务器
模型上下文协议 (MCP) 服务器,通过 ClickSend 的 API 提供短信和文本转语音 (TTS) 通话功能。该服务器使 AI 模型能够以编程方式发送短信和发起语音通话。
特征
短信:向全球任何电话号码发送短信
文本转语音通话:使用可自定义的文本转语音消息进行语音通话
速率限制:内置保护,每分钟限制 5 次操作
输入验证:对电话号码和消息内容进行全面验证
错误处理:详细的错误消息和正确的错误传播
Related MCP server: Slack MCP Server
安装
先决条件
Node.js(v16 或更高版本)
具有 API 凭证的 ClickSend 帐户
MCP 兼容客户端
设置
克隆存储库:
git clone https://github.com/J-Gal02/clicksend-mcp.git
cd clicksend-mcp安装依赖项:
npm install构建项目:
npm run build设置 MCP 客户端
将以下部分添加到您的cline_mcp_settings.json文件或claude_desktop_config.json文件中。
确保将目录替换为构建文件夹的正确路径,如下例所示,并将用户名和 API 密钥替换为您自己的。
{
"mcpServers": {
"clicksend": {
"command": "node",
"args": ["/directory/to/build/folder/clicksend-mcp/build/index.js"],
"env": {
"CLICKSEND_USERNAME": "example@droove.net",
"CLICKSEND_API_KEY": "ZZZZZZZZ-YYYY-YYYY-YYYY-XXXXXXXXXXXX"
}
}
}
}用法
可用工具
1. 发送短信
向指定电话号码发送短信。
参数:
to:E.164 格式的电话号码(例如 +61423456789)message:要发送的文本内容
例子:
{
"name": "send_sms",
"arguments": {
"to": "+61423456789",
"message": "Hello from ClickSend MCP!"
}
}2. make_tts_call
发起文本转语音呼叫。
参数:
to:E.164 格式的电话号码message:要转换为语音的文本内容voice:语音类型(“女声”或“男声”,默认为“女声”)
例子:
{
"name": "make_tts_call",
"arguments": {
"to": "+61423456789",
"message": "This is a Text-to-Speech call from ClickSend MCP",
"voice": "female"
}
}速率限制
为防止滥用,服务器实施了每分钟 5 次操作的速率限制。超过此限制的请求将收到错误响应,并附带重试延迟建议。
发展
可用脚本
npm run build:编译 TypeScript 并使输出可执行npm run start:启动 MCP 服务器npm run dev:在监视模式下运行 TypeScript 编译器
项目结构
clicksend-mcp/
├── src/
│ ├── index.ts # Main server implementation
│ ├── client.ts # ClickSend API client
│ └── utils/
│ └── validation.ts # Input validation utilities
├── build/ # Compiled JavaScript output
└── package.json # Project configuration错误处理
服务器针对各种场景提供了详细的错误消息:
无效的电话号码
消息内容验证失败
超出速率限制
API 身份验证错误
网络连接问题
错误响应包括适当的错误代码和描述性消息,以帮助诊断问题。
待办事项
[ ] 多个收件人
[ ] 配置发件人 ID
[x] 短信
[x] 语音合成
[ ] 电子邮件
[ ] 媒体上传
[ ] 电子邮件附件
[ ] 彩信
[ ] 字母
[ ] 明信片
[ ] 传真
[ ] 成本计算与确认
[ ] 统计数据
[ ] 历史
[ ] 联系方式
[ ] 自动化
执照
贡献
欢迎贡献代码!欢迎提交 Pull 请求。
Available Tools
2 toolsmake_tts_callC
Make Text-to-Speech calls via ClickSend
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Phone number in E.164 format | |
| message | Yes | Text content to convert to speech | |
| voice | No | Voice type for TTS | female |
TDQS
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. While 'Make...calls' implies an action that likely incurs costs and has external effects, the description doesn't mention authentication requirements, rate limits, cost implications, or what happens after the call is made. This leaves significant behavioral 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 extremely concise at just 5 words, front-loading the essential purpose without any wasted words. Every element earns its place, making it highly efficient for agent comprehension.
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 makes external API calls (likely with cost implications) with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after the call, what success/failure looks like, or any system constraints. The context signals indicate this is a non-trivial operation that needs more complete documentation.
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 provides no parameter information beyond what's already in the schema. However, with 100% schema description coverage, all parameters are well-documented in the structured fields, establishing a baseline score of 3. The description doesn't add any additional context about parameter usage or relationships.
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 ('Make Text-to-Speech calls') and the resource/service ('via ClickSend'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from the sibling tool 'send_sms', which would be needed for 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 like 'send_sms'. There's no mention of use cases, prerequisites, or contextual factors that would help an agent choose between TTS and SMS options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
send_smsC
Send SMS messages via ClickSend
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Phone number in E.164 format (e.g. +61423456789) | |
| message | Yes | Message content to send |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Send SMS messages' implies a write/mutation operation, it doesn't disclose important behavioral traits like authentication requirements, rate limits, cost implications, delivery confirmation, or error handling. The description is minimal and lacks operational 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 extremely concise at just 4 words, front-loading the essential information with zero wasted words. Every word earns its place in communicating the core functionality.
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 mutation tool with no annotations and no output schema, the description is insufficiently complete. It doesn't address what happens after sending (success/failure responses), doesn't mention the sibling tool relationship, and provides minimal operational context for a tool that presumably has costs, authentication needs, and delivery considerations.
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%, with both parameters ('to' and 'message') well-documented in the schema itself. The description adds no additional parameter information beyond what's already in the structured schema, so it meets the baseline for high schema coverage without adding extra value.
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 ('Send SMS messages') and the target resource ('via ClickSend'), providing a specific verb+resource combination. However, it doesn't differentiate from the sibling tool 'make_tts_call' which appears to be a different communication method (text-to-speech call).
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. There's no mention of the sibling tool 'make_tts_call' or any contextual factors that would help an agent choose between SMS and TTS communication methods.
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.
2 tool updates
v1.0.0- First observed
make_tts_call - First observed
send_sms
TDQS
Scored across 2 tools
The two tools have clearly distinct purposes: one handles text-to-speech calls and the other handles SMS messaging. There is no overlap in functionality, and an agent can easily differentiate between them based on their names and descriptions.
Both tools follow a consistent verb_noun pattern (make_tts_call and send_sms), using clear action verbs ('make' and 'send') followed by specific nouns. The naming is predictable and readable throughout the set.
With only two tools, the server feels thin for a communications platform like ClickSend, which might be expected to support more operations such as checking SMS status, managing contacts, or handling voice calls. The scope appears limited, potentially causing gaps in agent workflows.
For a ClickSend server, there are significant gaps in coverage: it lacks tools for checking delivery status of SMS or TTS calls, managing contacts, viewing message history, or handling other communication types like email or fax. This incomplete surface will likely lead to agent failures in broader communication tasks.
Related MCP Connectors
The Mobile Text Alerts SMS MCP server enables your AI to send SMS messages & manage contacts
Business texting for AI agents: send texts, read threads, manage contacts and run campaigns.
Canadian SMS and email API for AI agents: send SMS and email, verify phones, handle CASL consent.
Send and schedule SMS and WhatsApp messages, manage contacts and templates, and track delivery.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceA Model Context Protocol server that enables Claude and other AI assistants to send SMS and MMS messages using Twilio.22 npm15MIT
- AlicenseAqualityCmaintenanceA server implementing Model Context Protocol that enables AI assistants to interact with Slack API through a standardized interface, providing tools for messaging, channel management, user information retrieval, and more.11110Apache 2.0
- AlicenseAqualityDmaintenanceA server that enables AI assistants to interact with the Omnisend marketing platform, supporting contact management, product management, and event tracking operations through natural language.171Apache 2.0
- FlicenseNot gradedqualityDmaintenanceA simple server that enables AI models to send WhatsApp messages via the Twilio API by exposing a send\_whatsapp tool through the FastMCP framework.1-
Appeared in Searches
- A tool for connecting to fish.audio and generating AI voice
- Automated Solutions for Tax Client Services, Chatbots, VOIP, and Task Routing
- A motion capture platform (MCP) for real-time text-to-speech (TTS) integration
- Creating a phone application similar to Webtrit named Webcaller
- A tool for searching company info, monitoring social media, conducting online research, connecting to Gmail, and sending SMS