ClickSend MCP Server
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
종속성 설치:
npm install프로젝트를 빌드하세요:
npm run buildMCP 클라이언트 설정
다음 섹션을 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
[ ] 이메일
[ ] 미디어 업로드
[ ] 이메일 첨부 파일
[ ] 엠에스엠에스
[ ] 편지
[ ] 엽서
[ ] 팩스
[ ] 비용 계산 및 확인
[ ] 통계
[ ] 역사
[ ] 연락처
[ ] 자동화
특허
기여하다
기여를 환영합니다! 풀 리퀘스트를 제출해 주세요.
Available Tools
2 toolsmake_tts_callC
Make Text-to-Speech calls via ClickSend
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Phone number in E.164 format | |
| message | Yes | Text content to convert to speech | |
| voice | No | Voice type for TTS | female |
TDQS
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.
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.
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.
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.
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.
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
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Phone number in E.164 format (e.g. +61423456789) | |
| message | Yes | Message content to send |
TDQS
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.
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.
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.
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.
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.
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.
2 tool updates
v1.0.0- First observed
make_tts_call - First observed
send_sms
TDQS
Scored across 2 tools
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.
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.
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.
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
The Mobile Text Alerts SMS MCP server enables your AI to send SMS messages & manage contacts
Send and schedule SMS and WhatsApp messages, manage contacts and templates, and track delivery.
Canadian SMS API for AI agents: send SMS, verify phones, buy numbers and handle CASL consent.
Give your AI a real phone: place calls, send SMS, fetch recordings and transcripts. Local or hosted.
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceA Model Context Protocol server that enables Claude and other AI assistants to send SMS and MMS messages using Twilio.2515MIT
- AlicenseAqualityBmaintenanceA 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.11110Apache 2.0
- AlicenseAqualityDmaintenanceA server that enables AI assistants to interact with the Omnisend marketing platform, supporting contact management, product management, and event tracking operations through natural language.171Apache 2.0
- FlicenseNot gradedqualityDmaintenanceA 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
- A tool for connecting to fish.audio and generating AI voice
- Automated Solutions for Tax Client Services, Chatbots, VOIP, and Task Routing
- A motion capture platform (MCP) for real-time text-to-speech (TTS) integration
- Creating a phone application similar to Webtrit named Webcaller
- A tool for searching company info, monitoring social media, conducting online research, connecting to Gmail, and sending SMS