SMSTunnel

Send a text

send_sms

Send a single SMS to one phone number from your own Android phone and number; the recipient sees a familiar number and can reply. Use for one-to-one texts, not sign-in codes.

Instructions

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.

One text per person: each call has exactly one recipient. To text several people (for example a reminder to each client with an appointment tomorrow), call this tool once per person, about 30 texts a minute at most.
Before texting several people, show the user the whole list (each person's number and the exact words) and wait for their OK. For a single text, unless the user already approved this exact text, show the number and the words and wait for their OK.
Only send texts the user asked for and the recipient expects.
Number in international format (+ and the country code). A number without it needs defaultCountryCode; ask the user when unsure.
Up to 1600 characters; long texts go out as several SMS parts.
If the phone is offline, the text waits and goes out when the phone is back online.
Never resend a text automatically: after an error, a timeout, or a failed or unconfirmed status, tell the user and let them decide.
For sign-in or verification codes, use send_sign_in_code instead. Returns the message ID; check delivery with get_message_status.

Input Schema

Name	Required	Description
`to`	Yes	ONE phone number, in international format: + and the country code, e.g. +14155550123.
`message`	Yes	The words of the text, up to 1600 characters.
`deviceId`	No	ID of the phone that should send it, from list_phones. Leave it out to use SMSTUNNEL_DEVICE_ID or, when that is not set, a phone SMSTunnel picks.
`defaultCountryCode`	No	Country calling code for a number written without + or 00, e.g. "+1" or "44". Defaults to SMSTUNNEL_DEFAULT_COUNTRY_CODE. Leave it out for numbers that already start with +.

Output Schema

Name	Required	Description
`to`	Yes	The number as it was given.
`queued`	Yes	true when the phone was offline: the text waits and goes out when the phone is back online.
`branded`	Yes	true when the Free plan's texts for the day were used up and this one goes out with a short SMSTunnel line at the end.
`messageId`	Yes	ID of the text; pass it to get_message_status.
`remainingToday`	No	Texts left today on the plan (without that line).

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 3, 2026

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds substantial behavior beyond the annotations: offline messages queue and send when the phone reconnects, long messages split into multiple SMS parts, and the agent must never auto-resend after an error or unconfirmed status. It also names the sending device and points to get_message_status for delivery confirmation, none of which is derivable from readOnlyHint/openWorldHint/idempotentHint.

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?

Front-loads the core action and mechanism in the first sentence, then uses tight bullets each carrying one operative rule. The approval and batching bullets are long but every clause changes agent behavior; nothing reads as filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a non-idempotent, open-world mutation tool this covers the risks an agent needs: consent gating, recipient scoping, rate limits, offline behavior, no-retry policy, and where to check delivery. An output schema exists, and the description correctly refrains from enumerating the return payload beyond naming the message ID.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description adds only modest value, chiefly the instruction to ask the user for a country code when unsure and the format expectation for 'to'. Most other parameter detail (deviceId resolution order, defaultCountryCode fallback) is already fully documented in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Send one text message (SMS) to one phone number') and immediately explains the unusual mechanism — the user's own Android phone sends it from their own number — which distinguishes it from any gateway-based sender. Scope is unambiguous at one recipient per call.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use rules (only texts the user asked for and the recipient expects), an exclusion routing to a named sibling ('For sign-in or verification codes, use send_sign_in_code instead'), a batching strategy with a throughput bound (~30/minute), and a concrete approval workflow before sending.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server