Skip to content

Send SMS

Download SKILL.md

Skill ID: send-sms Server: RingEX Phone

Sends a single SMS on behalf of the authenticated user — resolving the recipient, asking which number to send from when more than one is available, and confirming the exact sender, recipient, and text before calling the write tool. The full skill source below is pulled directly from its SKILL.md file, so it always reflects the current version.

Send SMS

Goal

Send one personal SMS from a number the authenticated user owns, with the exact sender, recipient, and message text confirmed before anything is sent. send_sms is a write tool and is customer-facing and irreversible once delivered — this skill exists to make the required guardrails automatic rather than optional.

Trigger examples

  • "Text John and tell him I'm running late."
  • "Send an SMS to +1 415 555 1234 saying the meeting moved to 3pm."
  • "Reply to that text from Sarah with 'sounds good, see you then.'"
  • "Message +14085559876 on RingEX."

Scope boundary

  • This skill is for one-off, person-to-person texting only — never bulk, campaign, marketing, or A2P messaging. If the request mentions "campaign," "bulk," "opt-out," "consent," "template," or "brand," this is the wrong tool; tell the user this skill doesn't cover business/A2P messaging rather than attempting a workaround.
  • One recipient, one message, per invocation.

Workflow

  1. Resolve the recipient's phone number.
    • If the user gave a raw phone number, use it directly in E.164 format.
    • If the user named a person, resolve them first: try search_my_contacts (personal address book), then resolve_directory_person (company directory) if not found there. Never fabricate a phone number — if resolution is ambiguous or comes up empty, ask the user to clarify or provide the number directly.
  2. Determine the sending number.
    • Call get_my_phone to see which of the authenticated user's numbers are SMS-capable.
    • If there is exactly one SMS-capable number, use it without asking.
    • If there are 2–4 SMS-capable numbers, ask which one to use with a structured multiple-choice prompt (the AskUserQuestion tool, where available) — one question ("Which number should this text be sent from?"), one option per number, each labeled with the phone number and any friendly name/type (e.g. "Personal line," "Business number"). If one number is clearly the user's primary/default, list it first and mark it "(Recommended)."
    • If there are more than 4 SMS-capable numbers, a structured multiple-choice prompt can't list them all (max 4 options) — instead list the numbers as plain text and ask the user to state which one to use.
    • On a platform without a structured multiple-choice/button tool, fall back to listing the numbered options as plain text and asking the user to pick one.
  3. Draft the exact message text. Preserve the user's intended meaning and tone — don't editorialize, expand, or add signatures/disclaimers they didn't ask for.
  4. Preview and confirm before sending — never send silently.
    • Echo back, verbatim: the sender number, the recipient number, and the exact message text.
    • Wait for an explicit yes/confirm. A vague continuation of the conversation is not confirmation.
  5. Send.
    • Generate a fresh UUID for requestId.
    • Call send_sms with senderPhoneNumber, recipientPhoneNumber, text, and requestId.
  6. Handle the result.
    • On success, confirm briefly: who it was sent to, from which number, and the text.
    • On failure, report it plainly. If the error suggests the number isn't SMS-capable, note that this is usually a number-type or carrier registration (TCR/10DLC) issue on that number, not something to retry blindly.
    • On an unknown/ambiguous result (timeout, unclear response), tell the user the delivery status is unconfirmed. Do not retry the same intended send with the same or a new requestId — surface the uncertainty and let the user decide whether to try again.

Guidance

  • Never send an SMS without an explicit, informed confirmation of sender, recipient, and text.
  • Never guess a recipient's phone number from a name — resolve it or ask.
  • Never guess which number to send from when more than one is available — ask, using a structured multiple-choice prompt when 4 or fewer options exist.
  • Treat requestId reuse as unsafe after an ambiguous result — a duplicate send to a real person is a worse outcome than one unconfirmed send.
  • Stay out of bulk/A2P/business messaging entirely; redirect the user if that's what they're asking for.

← Back to Skill Library