Skip to main content
Glama
J-Gal02

ClickSend MCP Server

by J-Gal02

ClickSend MCP 서버

ClickSend API를 통해 SMS 메시지 전송 및 텍스트 음성 변환(TTS) 통화 기능을 제공하는 모델 컨텍스트 프로토콜(MCP) 서버입니다. 이 서버를 통해 AI 모델은 SMS 메시지를 전송하고 프로그래밍 방식으로 음성 통화를 시작할 수 있습니다.

특징

  • SMS 메시징 : 전 세계 모든 전화번호로 SMS 메시지를 보냅니다.

  • 텍스트 음성 변환 통화 : 사용자 정의 가능한 텍스트 음성 변환 메시지로 음성 통화를 하세요

  • 속도 제한 : 분당 5개의 작업 제한을 갖춘 내장형 보호 기능

  • 입력 검증 : 전화번호 및 메시지 내용에 대한 포괄적인 검증

  • 오류 처리 : 자세한 오류 메시지 및 적절한 오류 전파

Related MCP server: Slack MCP Server

설치

필수 조건

  • Node.js(v16 이상)

  • API 자격 증명을 사용한 ClickSend 계정

  • MCP 호환 클라이언트

설정

  1. 저장소를 복제합니다.

지엑스피1

  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 메시지를 보냅니다.

매개변수:

  • 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] TTS

  • [ ] 이메일

  • [ ] 미디어 업로드

    • [ ] 이메일 첨부 파일

    • [ ] 엠에스엠에스

    • [ ] 편지

    • [ ] 엽서

    • [ ] 팩스

  • [ ] 비용 계산 및 확인

  • [ ] 통계

  • [ ] 역사

  • [ ] 연락처

  • [ ] 자동화

특허

MIT

기여하다

기여를 환영합니다! 풀 리퀘스트를 제출해 주세요.

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