Skip to main content
Glama
enesjakozh
J-Gal02

ClickSend MCP Server

by J-Gal02
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

ClickSend MCP サーバー

ClickSend APIを介してSMSメッセージングと音声合成（TTS）通話機能を提供するモデルコンテキストプロトコル（MCP）サーバー。このサーバーにより、AIモデルはプログラムによってSMSメッセージを送信したり、音声通話を開始したりできるようになります。

特徴

  • SMSメッセージング：世界中のどの電話番号にもSMSメッセージを送信できます

  • 音声合成通話: カスタマイズ可能な音声合成メッセージで音声通話を行えます

  • レート制限: 1分あたり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. SMSを送信する

指定された電話番号に SMS メッセージを送信します。

パラメータ:

  • 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"
  }
}

レート制限

サーバーは不正使用を防ぐため、1分あたり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] SMS

  • [x] TTS

  • [ ] メールアドレス

  • [ ] メディアのアップロード

    • [ ] メールの添付ファイル

    • [ ] MMS

    • [ ] 文字

    • [ ] ポストカード

    • [ ] ファックス

  • [ ] コスト計算と確認

  • [ ] 統計

  • [ ] 歴史

  • [ ] 連絡先

  • [ ] 自動化

ライセンス

マサチューセッツ工科大学

貢献

貢献を歓迎します！お気軽にプルリクエストを送信してください。

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
Deploy Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

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.

Resources

Related MCP Connectors

Related MCP Servers

  • Slack MCP Server

    ubie-oss
    A
    license
    A
    quality
    B
    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

  • Omnisend MCP Server

    plutzilla
    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

  • Twilio WhatsApp FastMCP Server

    wubbyweb
    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
    -

Appeared in Searches