Skip to main content
Glama
J-Gal02

ClickSend MCP Server

by J-Gal02

ClickSend MCP 服务器

模型上下文协议 (MCP) 服务器,通过 ClickSend 的 API 提供短信和文本转语音 (TTS) 通话功能。该服务器使 AI 模型能够以编程方式发送短信和发起语音通话。

特征

  • 短信:向全球任何电话号码发送短信

  • 文本转语音通话:使用可自定义的文本转语音消息进行语音通话

  • 速率限制:内置保护,每分钟限制 5 次操作

  • 输入验证:对电话号码和消息内容进行全面验证

  • 错误处理:详细的错误消息和正确的错误传播

Related MCP server: Slack MCP Server

安装

先决条件

  • Node.js(v16 或更高版本)

  • 具有 API 凭证的 ClickSend 帐户

  • MCP 兼容客户端

设置

  1. 克隆存储库:

git clone https://github.com/J-Gal02/clicksend-mcp.git
cd clicksend-mcp
  1. 安装依赖项:

npm install
  1. 构建项目:

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 tools
make_tts_callC

Make Text-to-Speech calls via ClickSend

ParametersJSON Schema
NameRequiredDescriptionDefault
toYesPhone number in E.164 format
messageYesText content to convert to speech
voiceNoVoice type for TTSfemale

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden 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.

Conciseness5/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives 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

ParametersJSON Schema
NameRequiredDescriptionDefault
toYesPhone number in E.164 format (e.g. +61423456789)
messageYesMessage content to send

TDQS

C2.9/5.0
Behavior2/5

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.

Conciseness5/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. 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.

  1. 2 tool updatesv1.0.0
    • First observedmake_tts_call
    • First observedsend_sms

TDQS

B3.1/5.0

Scored across 2 tools

Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count2/5

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.

Completeness2/5

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

Related MCP Servers

  • A
    license
    Not graded
    quality
    D
    maintenance
    A Model Context Protocol server that enables Claude and other AI assistants to send SMS and MMS messages using Twilio.
    22 npm
    15
    MIT
  • A
    license
    A
    quality
    C
    maintenance
    A 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.
    11
    110
    Apache 2.0
  • A
    license
    A
    quality
    D
    maintenance
    A server that enables AI assistants to interact with the Omnisend marketing platform, supporting contact management, product management, and event tracking operations through natural language.
    17
    1
    Apache 2.0
  • F
    license
    Not graded
    quality
    D
    maintenance
    A 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
    -