Skip to main content
Glama
enesjakozh
J-Gal02

ClickSend MCP Server

by J-Gal02
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Servidor MCP de ClickSend

Un servidor de Protocolo de Contexto de Modelo (MCP) que proporciona mensajería SMS y funciones de llamada de texto a voz (TTS) a través de la API de ClickSend. Este servidor permite a los modelos de IA enviar SMS e iniciar llamadas de voz mediante programación.

Características

  • Mensajería SMS : envía mensajes SMS a cualquier número de teléfono en todo el mundo

  • Llamadas de texto a voz : realice llamadas de voz con mensajes de texto a voz personalizables

  • Limitación de velocidad : protección integrada con límite de 5 acciones por minuto

  • Validación de entrada : validación integral de números de teléfono y contenido de mensajes

  • Manejo de errores : mensajes de error detallados y propagación adecuada de errores

Related MCP server: Slack MCP Server

Instalación

Prerrequisitos

  • Node.js (v16 o superior)

  • Cuenta de ClickSend con credenciales de API

  • Cliente compatible con MCP

Configuración

  1. Clonar el repositorio:

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

  1. Instalar dependencias:

npm install

  1. Construir el proyecto:

npm run build

Configuración del cliente MCP

Agregue las siguientes secciones en su archivo cline_mcp_settings.json o claude_desktop_config.json .

Asegúrese de reemplazar el directorio con la ruta correcta a la carpeta de compilación, como se muestra en el siguiente ejemplo, así como el nombre de usuario y la clave API con los suyos.

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

Uso

Herramientas disponibles

1. enviar_sms

Envía mensajes SMS a números de teléfono especificados.

Parámetros:

  • to : Número de teléfono en formato E.164 (por ejemplo, +61423456789)

  • message : Contenido del texto a enviar

Ejemplo:

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

2. hacer_llamada_tts

Iniciar llamadas de texto a voz.

Parámetros:

  • to : Número de teléfono en formato E.164

  • message : Contenido de texto para convertir a voz

  • voice : tipo de voz ('femenino' o 'masculino', predeterminado 'femenino')

Ejemplo:

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

Limitación de velocidad

El servidor implementa un límite de 5 acciones por minuto para evitar abusos. Las solicitudes que superen este límite recibirán una respuesta de error con una sugerencia de retraso de reintento.

Desarrollo

Scripts disponibles

  • npm run build : compila TypeScript y hace que la salida sea ejecutable

  • npm run start : Inicia el servidor MCP

  • npm run dev : ejecuta el compilador de TypeScript en modo de observación

Estructura del proyecto

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

Manejo de errores

El servidor proporciona mensajes de error detallados para varios escenarios:

  • Números de teléfono no válidos

  • Errores de validación del contenido del mensaje

  • Límite de velocidad excedido

  • Errores de autenticación de API

  • Problemas de conectividad de red

Las respuestas de error incluyen códigos de error apropiados y mensajes descriptivos para ayudar a diagnosticar problemas.

HACER

  • [ ] Múltiples destinatarios

  • [ ] Configurar los ID del remitente

  • [x] SMS

  • [x] TTS

  • [ ] Correo electrónico

  • [ ] Carga de medios

    • [ ] Archivos adjuntos de correo electrónico

    • [ ] MMS

    • [ ] Cartas

    • [ ] Postales

    • [ ] Fax

  • [ ] Cálculo y confirmación de costos

  • [ ] Estadísticas

  • [ ] Historia

  • [ ] Contactos

  • [ ] Automatizaciones

Licencia

Instituto Tecnológico de Massachusetts (MIT)

Contribuyendo

¡Agradecemos sus contribuciones! No dude en enviar una solicitud de incorporación de cambios.

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