Skip to main content
Glama
enesjakozh
J-Gal02

ClickSend MCP Server

by J-Gal02
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Remote

ClickSend MCP Server

A Model Context Protocol (MCP) server that provides SMS messaging and Text-to-Speech (TTS) call capabilities through ClickSend's API. This server enables AI models to send SMS messages and initiate voice calls programmatically.

Features

  • SMS Messaging: Send SMS messages to any phone number worldwide

  • Text-to-Speech Calls: Make voice calls with customizable text-to-speech messages

  • Rate Limiting: Built-in protection with 5 actions per minute limit

  • Input Validation: Comprehensive validation for phone numbers and message content

  • Error Handling: Detailed error messages and proper error propagation

Related MCP server: Slack MCP Server

Installation

Prerequisites

  • Node.js (v16 or higher)

  • ClickSend account with API credentials

  • MCP-compatible Client

Setup

  1. Clone the repository:

git clone https://github.com/J-Gal02/clicksend-mcp.git
cd clicksend-mcp

  1. Install dependencies:

npm install

  1. Build the project:

npm run build

Setting up the MCP Client

Add the following sections into your cline_mcp_settings.json file or claude_desktop_config.json file.

Be sure to replace the directory with the correct path to the build folder, as shown in the example below, as well as the username and API key with your own.

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

Usage

Available Tools

1. send_sms

Send SMS messages to specified phone numbers.

Parameters:

  • to: Phone number in E.164 format (e.g., +61423456789)

  • message: Text content to send

Example:

{
  "name": "send_sms",
  "arguments": {
    "to": "+61423456789",
    "message": "Hello from ClickSend MCP!"
  }
}

2. make_tts_call

Initiate Text-to-Speech calls.

Parameters:

  • to: Phone number in E.164 format

  • message: Text content to convert to speech

  • voice: Voice type ('female' or 'male', defaults to 'female')

Example:

{
  "name": "make_tts_call",
  "arguments": {
    "to": "+61423456789",
    "message": "This is a Text-to-Speech call from ClickSend MCP",
    "voice": "female"
  }
}

Rate Limiting

The server implements a rate limit of 5 actions per minute to prevent abuse. Requests exceeding this limit will receive an error response with a retry delay suggestion.

Development

Available Scripts

  • npm run build: Compile TypeScript and make the output executable

  • npm run start: Start the MCP server

  • npm run dev: Run TypeScript compiler in watch mode

Project Structure

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

Error Handling

The server provides detailed error messages for various scenarios:

  • Invalid phone numbers

  • Message content validation failures

  • Rate limit exceeded

  • API authentication errors

  • Network connectivity issues

Error responses include appropriate error codes and descriptive messages to help diagnose issues.

TODO

  • Multiple Recepients

  • Configure Sender IDs

  • SMS

  • TTS

  • Email

  • Media Uploading

    • Email Attachments

    • MMS

    • Letters

    • Postcards

    • Fax

  • Cost Calculation and Confirmation

  • Statistics

  • History

  • Contacts

  • Automations

License

MIT

Contributing

Contributions are welcome! Please feel free to submit a Pull Request.

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. Dates show when Glama detected each change.

  1. 2 tool updatesv1.0.0
    • First observedmake_tts_call
    • First observedsend_sms
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.1/5.0
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

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

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

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/J-Gal02/clicksend-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server