SMSTunnel
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SMSTUNNEL_API_KEY | Yes | The key from Apps → Add an app. | |
| SMSTUNNEL_DEVICE_ID | No | The phone that sends when the assistant doesn't name one. Without it, SMSTunnel picks one of your online phones. | |
| SMSTUNNEL_SERVER_URL | No | For testing only. Default https://smstunnel.io. | https://smstunnel.io |
| SMSTUNNEL_CONFIRM_EACH_TEXT | No | true (default): AI apps that support it ask you before every single text. Set false only for unattended runs. | true |
| SMSTUNNEL_DEFAULT_COUNTRY_CODE | No | For example +40 or 1: completes numbers written without + or 00. Without it, numbers must be in international format. |
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": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| send_smsA | Send one text message (SMS) to one phone number. The user's own Android phone, running the SMSTunnel app, sends it from the user's own number, so the recipient sees a number they know and can reply.
|
| send_sign_in_codeA | Send a sign-in or verification code by text (SMS) to one phone number, from the user's own Android phone and own number. Use it only for sign-in codes: it counts against the separate sign-in code allowance. For any other text, use send_sms.
|
| get_message_statusA | Look up where a text sent with send_sms or send_sign_in_code is now, by its messageId: pending (waiting for the phone), sent, delivered, failed, or unconfirmed (handed to the SIM, but the phone got no confirmation, so it may have gone out). Returns the status with its times and any error. Read-only. Never resend a failed or unconfirmed text on your own: ask the user. |
| list_phonesA | List the Android phones linked to the user's SMSTunnel account: ID, name, whether each is online, and when it was last seen. Use it to choose which phone sends (pass its ID as deviceId to send_sms or send_sign_in_code) or to check that a phone is online before sending. Read-only. |
| get_usageA | Show the SMSTunnel account's plan and today's usage: texts and sign-in codes sent today, the daily limits, and how many are left. Use it when the user asks about limits, or before sending several texts. Read-only. |
| list_received_textsA | Read texts (SMS) that the user's phones received, newest first: sender, words, time and the phone that got each one. Use it to see replies to texts the user sent (filter with phone) or what arrived since a time. Read-only.
|
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 6 tools
Each tool occupies a distinct action+resource slot: two send variants (regular SMS vs sign-in code, with explicit rules telling the agent which to pick), plus status lookup, device listing, usage, and inbox reading. The send_sms/send_sign_in_code boundary is the only potential overlap and the descriptions resolve it decisively (digits-only codes, separate allowance). No two tools could be reasonably confused.
All six names follow a strict verb_noun snake_case pattern (send_sms, send_sign_in_code, get_message_status, list_phones, get_usage, list_received_texts). Verbs are used semantically consistently: send_ for outbound actions, get_/list_ for read-only lookups, and read-only tools are labeled as such in their descriptions.
Six tools is tightly scoped to the SMS domain: two send paths, status, device selection, quota, and inbox. Nothing feels padded, and no obvious operation is crammed into an overloaded tool. Deliberately omitting a bulk-send tool in favor of one-recipient calls is a defensible design choice given the approval workflow.
The core lifecycle is covered: send, verify delivery, discover devices, check quota, read replies. Minor gaps remain: there is no way to cancel or list queued/sent messages (only per-messageId status), which matters since texts can sit pending while a phone is offline, and no contact/number validation helper beyond defaultCountryCode. Agents can work around these by asking the user, so it is not a blocking gap.