Skip to main content
Glama

Sats4AI - Bitcoin-Powered AI Tools

send_sms

Destructive

Reach a human via SMS when your task requires real-world coordination. Sends to 190+ countries; delivery timing varies by destination. Refused before payment, with no invoice, because their networks require a registered sender name we do not have (ISO country codes): AE, AT, AU, BD, BJ, BY, CG, CI, CM, ES, GH, GN, GW, ID, IE, JO, KE, KW, KZ, LK, LR, MA, NG, NP, OM, PH, QA, RU, RW, SA, SD, SG, SS, TH, TR, TZ, UG, VN, ZM. A country can also be paused for up to 24 hours after repeated carrier failures there; that refusal reads as RATE_LIMITED, retry later. No phone plan, no SIM card, no telecom account needed. Pay with Bitcoin Lightning — no API key, no KYC, no subscription. Requires create_payment with toolName='send_sms' and phoneNumber+message at payment time. The phoneNumber must match the one used in create_payment. The message must not need more SMS segments than were paid for. Free rules, refused before payment, with no invoice: no links in the text, a send limit per destination number, and no number on our do-not-contact list. A paid send checks the limit and the list again; a refusal then refunds in full. A link added after payment is held, not refunded: a link is never sent. A US number: Queued. A text to a US number can take a few hours to arrive. Each SMS ends with a short signature line naming the service and a safety/stop link, within the paid segment count. No impersonation, scams, threats, harassment, credential theft, unsolicited bulk messages, or contact after an opt-out. Answering a call does not establish consent. We screen requests after payment. Held messages and calls are not sent or placed; payment is retained during review, not refunded immediately. Confirmed violations are not refunded. Unresolved communication holds become eligible for a refund after 24 hours; refund eligibility is processed by scheduled maintenance. Human review costs 1 sat at https://sats4ai.com/appeal. Recent message text and extracts of recording transcripts support recipient-scoped abuse checks for 24 hours. These context records are deleted hourly, so storage can last up to 25 hours. Original uploaded-call transcripts and raw held-request or appeal evidence enter cleanup after 30 days. We also keep a de-identified record of screened communications to measure and improve fraud detection. Identifiers in it — contact addresses, numbers and names that follow a greeting — are replaced with one-way tokens, and it holds no destination number and no account, because the service has none. De-identification is not anonymization: text a sender wrote can still identify someone. Do not submit personal information the service does not need. Providers keep records under their own policies.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "paymentId": "<paymentId>",
      "phoneNumber": "<phoneNumber>",
      "message": "<message>"
    },
    "name": "send_sms"
  }
}

Input Schema

NameRequiredDescriptionDefault
messageYesMessage text (max 1544 chars — a short signature line is appended; billed per SMS segment)
paymentIdYesValid payment ID (must be paid)
phoneNumberYesPhone number in E.164 format (e.g., +14155550100). NOTE: non-+1 (international) numbers are delivered from an alphanumeric sender ID, so the recipient CANNOT reply — one-way only; for some countries (e.g. FR/CZ/CN) it is the only delivery path. No error is returned.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / message / description
      Previous value: -"Message text (max 1544 chars — unverified-sender notice prepended; billed per SMS segment)"New value: +"Message text (max 1544 chars — a short signature line is appended; billed per SMS segment)"
  2. Changed1 schema field changed
    • changedInput schema / properties / message / description
      Previous value: -"Message text (max 1544 chars — short disclaimer auto-appended; billed per SMS segment)"New value: +"Message text (max 1544 chars — unverified-sender notice prepended; billed per SMS segment)"
  3. Changed1 schema field changed
    • changedInput schema / properties / message / description
      Previous value: -"Message text (max 126 chars — short disclaimer auto-appended)"New value: +"Message text (max 1544 chars — short disclaimer auto-appended; billed per SMS segment)"
  4. First observed

TDQS

A3.9/5.0
Behavior5/5

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

Beyond annotations, it discloses payment requirements, country-level refusals, RATE_LIMITED behavior after carrier failures, refund conditions, post-payment screening, message-signature behavior, and data-retention rules. This is unusually rich behavioral context for a destructive, open-world tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is heavily overloaded with policy, privacy, refund, and retention details, and it repeats key ideas such as 'refused before payment, with no invoice.' While some compliance information is necessary, the text is far longer and denser than needed for selection and invocation.

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 complex paid-messaging tool with no output schema, the description covers prerequisites, refusal cases, retry behavior, refund rules, consent and abuse screening, and privacy limitations. An agent has enough information to understand the tool's operational envelope.

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 already 100%, but the description adds meaningful constraints: phoneNumber must match the number used in create_payment, paymentId must be paid, and message must not exceed the paid segment count. These details go beyond the schema's field definitions.

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

Purpose4/5

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

The description states a specific action and resource: reaching a human via SMS, with delivery to 190+ countries. It implicitly distinguishes SMS from sibling channels such as send_email or send_fax by medium, though it does not name alternatives directly.

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

Usage Guidelines3/5

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

It gives a usage context ('when your task requires real-world coordination') and lists key preconditions such as create_payment with toolName='send_sms'. However, it does not explicitly say when to choose this over siblings like send_email, send_fax, or ai_call, leaving routing guidance implicit.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.