Promotexter MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PROMOTEXTER_API_KEY | Yes | API Key from your Promotexter dashboard. | |
| PROMOTEXTER_SENDER_ID | Yes | Sender ID that must be whitelisted in your Promotexter account. | |
| PROMOTEXTER_API_SECRET | Yes | API Secret from your Promotexter dashboard. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_balanceB | Get the current account balance from Promotexter. Returns: Account balance information |
| send_smsA | Send a single SMS message via Promotexter. Args: to: Recipient mobile number (must be valid mobile number format) text: Message content (maximum 1000 characters) reference_id: Optional reference ID for tracking Returns: SMS send response with transaction details |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 2 tools
The two tools have completely distinct purposes: get_balance retrieves account information, while send_sms sends messages. There is no overlap in functionality, and an agent would never confuse one for the other.
Both tools follow a consistent verb_noun pattern (get_balance, send_sms) with clear, descriptive names. The naming convention is uniform throughout the toolset.
With only two tools, the server feels severely underpowered for an SMS service domain. There are obvious missing operations like checking SMS status, viewing message history, managing contacts, or handling bulk sends that would be expected in a complete SMS API surface.
The toolset is severely incomplete for an SMS service. While it covers basic balance checking and message sending, it lacks essential operations like viewing sent messages, checking delivery status, managing templates, or handling errors. This will cause significant agent failures when trying to perform common SMS workflows.