Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@telesign-mcp Send an OTP to +15551234567 via SMS"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that provides seamless integration with TeleSign APIs for AI assistants like Anthropic's Claude, OpenAI's ChatGPT, or Google's Gemini. Enable your AI to send SMS messages, verify phone numbers, assess fraud risk, and more.
The Model Context Protocol is an open standard that allows AI assistants to securely connect to external data sources and tools. This server implements MCP to give AI assistants direct access to TeleSign's communication and verification APIs.
Related MCP server: SMS Masivos MCP Server
Tool | Description |
| Send a one-time passcode via SMS, voice, WhatsApp, Viber, RCS, or email with automatic fallback support |
| Verify an OTP code entered by the user |
| Check the status of an ongoing verification |
| Get phone number details including type (mobile/landline/VoIP), carrier, and location |
| Get fraud risk score (0-1000) with allow/flag/block recommendation |
| Send SMS messages (OTP, alerts, or marketing) |
| Search TeleSign documentation |
| Retrieve full documentation for a topic |
Multi-Channel OTP Verification - Send verification codes via SMS, voice, WhatsApp, Viber, RCS, or email with automatic fallback between channels
Phone Intelligence - Identify phone number type, carrier, and geographic location
Fraud Prevention - Real-time risk scoring to detect fraudulent phone numbers
SMS Messaging - Send transactional or marketing messages
Built-in Documentation - Access TeleSign API docs directly through the AI assistant
Node.js 18+
Cursor, Claude Code, VSCode, Windsurf or another MCP Client
A TeleSign account with API credentials (Sign up here)
Clone the repository:
git clone https://github.com/mdp18/telesign-mcp.git
cd telesign-mcpInstall dependencies:
npm installBuild the project:
npm run buildSet your TeleSign API credentials:
export TELESIGN_CUSTOMER_ID="your-customer-id"
export TELESIGN_API_KEY="your-api-key"Add this to your Claude Desktop config file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"telesign": {
"command": "node",
"args": ["/path/to/telesign-mcp/build/index.js"],
"env": {
"TELESIGN_CUSTOMER_ID": "your-customer-id",
"TELESIGN_API_KEY": "your-api-key"
}
}
}
}Once configured, you can ask Claude to:
"Send an OTP to +15551234567 via SMS with voice fallback after 30 seconds"
"Verify the code 123456 for reference ID abc-123"
"Get information about the phone number +15551234567"
"Check the fraud risk score for +15551234567"
"Send an SMS to +15551234567 saying 'Your order has shipped'"
The server includes built-in documentation accessible via the docs_search and docs_get tools. Available topics:
verify-api - OTP verification endpoints and flows
phone-id - Phone number lookup details
intelligence - Risk scoring and fraud detection
messaging-sms - SMS messaging guide
status-codes - API response codes reference
Verify API - Multi-channel OTP verification (SMS, voice, WhatsApp, Viber, RCS, email) with fallback support
Phone ID API - Phone number intelligence with identity attribute add-ons (SIM swap, number deactivation, contact info, porting history, etc.)
Intelligence API - Fraud risk scoring and recommendations
Messaging API - Basic SMS sending (/v1/messaging)
Bulk SMS API
Messaging API (full-featured)
SMS Verify API (standalone)
Silent Verify API
Templates API
Voice V2 API
Accounts API
App Verify API
Flow Builder API
# Watch mode for development
npm run dev
# Build for production
npm run build
# Run the server directly
npm startApache 2.0 - See LICENSE for details.
This is a community-driven, open source project and is not officially affiliated with, endorsed by, or supported by TeleSign. The author(s) do not own or claim any rights to the TeleSign trademark, name, or branding. "TeleSign" and any associated logos are trademarks of TeleSign Corporation.
This project is provided "as is" without warranty of any kind. Use at your own risk. For official TeleSign support not related to this MCP server, please contact TeleSign directly.
Get complete documentation for a TeleSign topic.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | Documentation topic to retrieve |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It indicates a read operation ('Get'), which is appropriate. However, it does not disclose authentication needs, rate limits, or error handling beyond what the schema implies, leaving minor 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 a single sentence with no redundant words. It efficiently conveys the core functionality, earning a top score for conciseness.
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?
Given the simplicity of the tool (one enum parameter, no output schema), the description is largely complete. It could be improved by mentioning the output format or that it returns full documentation content, but it is sufficient for a basic retrieval tool.
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 input schema fully covers the only parameter 'topic' with a description and enum, so the tool description adds no extra semantic value. Baseline score of 3 is appropriate as schema coverage is 100%.
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 verb 'Get' and the resource 'complete documentation for a TeleSign topic', making the tool's purpose apparent. However, it does not differentiate from the sibling tool 'docs_search', which could be used for searching documentation, lacking explicit uniqueness.
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?
No guidance on when to use this tool versus alternatives like 'docs_search'. The description does not specify contexts where fetching complete documentation is preferred over searching or other methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search TeleSign documentation. Use for error codes, API details, best practices, etc.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query (e.g., 'error 503', 'risk score', 'phone types') | |
| topic | No | Specific topic to search, or 'all' | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It states the tool searches documentation, implying a read-only operation, but offers no details on authentication, rate limits, side effects, or result format. This is insufficient for a search tool with no other structured behavioral hints.
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 a single sentence with no wasted words. It is front-loaded with the tool's purpose and usage context, maintaining high readability and efficiency.
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?
The description lacks details about the return value, pagination, or any special behavior. Given the absence of an output schema and annotations, it fails to provide sufficient completeness for agents to understand what the tool returns or any constraints.
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%, so the schema already documents both parameters with examples. The description adds minimal extra meaning beyond restating examples from the schema, meeting the baseline but not exceeding it.
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 verb 'search' and the resource 'TeleSign documentation', with examples like error codes and API details. It effectively distinguishes from sibling tools like docs_get (which likely retrieves a specific document) and other tool categories.
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 explicit use cases ('Use for error codes, API details, best practices, etc.'), giving agents clear context. However, it lacks explicit guidance on when not to use this tool or how it compares to alternatives like docs_get, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get fraud risk score (0-1000) for a phone number. Returns recommendation: allow/flag/block. See docs://telesign/intelligence for score interpretation.
| Name | Required | Description | Default |
|---|---|---|---|
| phone_number | Yes | E.164 format phone number (e.g., 15551234567) | |
| originating_ip | No | User's IP address for additional context | |
| account_lifecycle_event | No | Type of event being evaluated | create |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose all behavioral traits. It mentions the output (score and recommendation) but lacks details on error handling, rate limits, prerequisite authentication, or what happens with invalid input.
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?
Two sentences, front-loaded with purpose. No extraneous information. Every sentence earns its place.
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 simple risk assessment tool with no output schema, the description explains the return values (score and recommendation) and points to docs for interpretation. It could mention error handling or rate limits but is reasonably complete.
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 coverage is 100%, so baseline is 3. The description does not add meaning beyond the schema; it only references the phone number without additional context on the other parameters.
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 it gets a fraud risk score for a phone number with a specific range (0-1000) and returns a recommendation (allow/flag/block). This is distinct from sibling tools like phoneid, verifyapi, messaging, and docs.
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?
No explicit guidance on when to use this tool vs alternatives, though it's the only risk assessment tool among siblings. A pointer to external documentation is provided but no when/why context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send an SMS message to a phone number. See docs://telesign/messaging-sms for message types and delivery codes.
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | Message content (max 1600 characters) | |
| message_type | No | OTP=verification codes, ARN=alerts/notifications, MKT=marketing | ARN |
| phone_number | Yes | E.164 format phone number |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It does not disclose any behavioral traits such as side effects, authentication, rate limits, or error conditions. Merely states the action.
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?
Very concise two-line description with front-loaded primary action. Efficient, but could benefit from more detail without becoming verbose.
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?
Given no annotations or output schema, the description is insufficient. It omits critical details like prerequisites, return values, error scenarios, or any behavioral constraints, making it incomplete for safe tool use.
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?
Input schema already provides full descriptions for all parameters (100% coverage). The description adds no extra semantic meaning beyond referencing external docs for message types, which is not directly about parameters.
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?
Clearly states it sends an SMS message to a phone number. Does not explicitly differentiate from sibling tools like verifyapi_send_otp, but the verb and resource are specific enough.
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?
No guidance on when to use this tool versus alternatives (e.g., verifyapi_send_otp). The only additional info is a reference to external documentation for message types, not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a phone number including type (mobile/landline/VoIP), carrier, and location. See docs://telesign/phone-id for details.
| Name | Required | Description | Default |
|---|---|---|---|
| addons | No | Identity attributes to include. Each enabled addon returns additional data about the phone number. | |
| external_id | No | Customer-generated ID for this transaction (echoed in response) | |
| phone_number | Yes | Complete phone number with country code, no spaces or special characters (e.g., 15551234567) | |
| originating_ip | No | End user's IP address (IPv4 or IPv6) for additional context | |
| account_lifecycle_event | No | Type of account event: create, sign-in, transact, update, or delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose behavioral traits like rate limits, authentication needs, cost implications, or whether the operation is read-only. The description only states what it does, not how it behaves.
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 one sentence plus a documentation reference, which is concise. It could be slightly more structured, but there is no waste.
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?
Given the complexity (nested object with many addons, no output schema), the description is too brief. It does not explain addons, response format, error conditions, or any caveats, leaving significant gaps for an agent.
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 coverage is 100% with descriptions for all parameters. The description adds contextual value by summarizing return types but does not enhance parameter meaning beyond the schema. Baseline 3 is appropriate.
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 tool retrieves detailed information about a phone number, listing specific data types (type, carrier, location). It uses a specific verb 'Get' and resource 'phone number'. The siblings are all different (docs, messaging, verification), so no confusion.
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 vs alternatives. It does not mention prerequisites, limitations, or when not to use. The reference to docs is for details, not usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify an OTP code that was sent to a user. Requires the reference_id from verifyapi_send_otp.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | OTP code entered by user | |
| reference_id | Yes | Reference ID from verifyapi_send_otp |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the action (verify) and requirement but does not disclose behavioral details such as whether the OTP is consumed, error handling, or idempotency. This is insufficient given no annotations.
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 two sentences with no extraneous information. It front-loads the core purpose and immediately follows with critical context. Every sentence earns its place.
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 simple two-parameter tool with no output schema or annotations, the description covers the action and prerequisite. However, it lacks details on return values, error conditions, or state changes, which would make it more complete.
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 documented. The description adds minimal value beyond reinforcing the prerequisite. Per guidelines, high coverage yields baseline 3, and the description does not significantly improve parameter understanding.
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 tool verifies an OTP code sent to a user, using a specific verb and resource. It also mentions the prerequisite reference_id from verifyapi_send_otp, which distinguishes it from sibling tools like verifyapi_send_otp and verifyapi_get_status.
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 specifies a prerequisite (reference_id from verifyapi_send_otp) but does not explicitly state when to use this tool versus alternatives or provide exclusions. It implies usage after sending an OTP but lacks direct comparison with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve details about a verification process in progress. Use this to check the current status of a verification including channel-by-channel delivery status.
| Name | Required | Description | Default |
|---|---|---|---|
| reference_id | Yes | Reference ID from verifyapi_send_otp |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It indicates the tool retrieves details and mentions 'in progress' status, suggesting a read-only operation. However, it does not explicitly confirm non-destructiveness, authentication needs, or behavior with invalid reference IDs, which is a moderate gap.
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 consists of two concise sentences with no wasted words. It efficiently conveys the tool's purpose and key 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?
Given the tool has no output schema, the description mentions 'channel-by-channel delivery status' but lacks specifics on the exact response fields or format. For a simple status retrieval with one parameter, this is mostly complete but could be more detailed about return values.
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 input schema has 100% coverage with a single required parameter 'reference_id' described as 'Reference ID from verifyapi_send_otp'. The tool description adds no additional semantic meaning beyond the schema, so a baseline score of 3 is appropriate.
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 verb 'Retrieve' and the resource 'details about a verification process'. It specifies the action of checking current status including channel-by-channel delivery, effectively distinguishing it from sibling tools like verifyapi_send_otp and verifyapi_check_code.
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 explicitly says 'Use this to check the current status of a verification', providing clear context for when to use the tool. However, it does not state when not to use it or mention alternatives, though sibling tools are implicitly differentiated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a one-time passcode (OTP) to a phone number. Returns reference_id needed for verifyapi_check_code. Supports multiple fallback channels with fallback_time. See docs://telesign/verify-api.
| Name | Required | Description | Default |
|---|---|---|---|
| recipient | Yes | Recipient contact info | |
| verification_policy | Yes | Array of verification methods in order. Each can have fallback_time (seconds) except the last one. Example: [{method:'sms',fallback_time:30},{method:'voice'}] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the core action and return value but omits behavioral traits such as error handling, idempotency, permission requirements, or what happens on failure. The 'See docs' reference partially mitigates this, but the description itself is minimal.
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 two sentences, front-loading the core purpose and return value, then adding key detail about fallback channels and a documentation link. No redundant or unnecessary words.
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?
Given the nested object schema and no output schema, the description covers the essential return value (reference_id) and the fallback mechanism. However, it lacks completeness on error responses, edge cases, and response structure, making it adequate but not thorough.
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%, so the description adds only marginal value by explaining the purpose of fallback_time and the array order. The baseline for high coverage is 3, and the description does not contradict or substantially enhance the schema.
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 verb 'send' and the resource 'one-time passcode (OTP) to a phone number', and it indicates the return value (reference_id) and its relation to verifyapi_check_code, distinguishing it from siblings like verifyapi_check_code and messaging_send_sms.
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 implies that verifyapi_check_code is the next step but does not explicitly say when not to use this tool or compare it to alternatives like messaging_send_sms. It gives context but lacks explicit exclusions or usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
All tools have clearly distinct purposes: documentation retrieval/search, fraud risk assessment, SMS sending, phone number info, and OTP verification lifecycle. No overlap.
All tool names follow a consistent resource_action pattern in snake_case (e.g., docs_get, intelligence_assess_risk, verifyapi_send_otp). Perfectly predictable.
With 8 tools covering documentation, intelligence, messaging, phone ID, and verification, the set is well-scoped and not overwhelming. Each tool serves a clear need.
Covers core TeleSign services well, including OTP lifecycle and fraud risk. Missing voice verification or account management, but the core workflows are supported.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Give AI agents secure access to RevDesk calling, SMS, phone numbers, caller IDs, and usage.
Communication stack for AI agents: SMS, AI voice calls, phone numbers, and account events.
The Mobile Text Alerts SMS MCP server enables your AI to send SMS messages & manage contacts
Give AI agents a phone number. Voice calls, SMS, and phone number management for MCP clients.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/mdp18/telesign-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
