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. Send to any phone number worldwide — delivery timing varies by destination. 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.

Input Schema

TableJSON 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

A4/5.0
Behavior5/5

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

Goes far beyond the openWorldHint/destructiveHint annotations: free pre-payment refusals vs. paid sends that re-check limits and refund in full, links added after payment being held and never sent, 24-hour refund eligibility handled by scheduled maintenance, signature line appended, and explicit retention windows (24h context records, 30-day transcripts, 25h max storage). This is exactly the operational detail an agent cannot derive from annotations.

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 purpose and payment prerequisite are front-loaded, but the remainder is an unstructured wall of legal, retention, and abuse-policy boilerplate (appeal pricing, de-identification methodology, provider record-keeping) that buries the operational rules an agent actually needs before invoking.

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

Completeness4/5

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

For a complex pay-per-use communications tool with no output schema, it covers prerequisites, refusal/refund outcomes, delivery timing ('a text to a US number can take a few hours'), and the appended signature. It is thin on how the send result is retrieved (async/queued status polling), which is a modest remaining gap.

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, and the description earns above that by adding cross-parameter constraints the schema does not state: the phoneNumber must match the one used in create_payment, and the message must not require more SMS segments than were paid for.

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?

States the verb+resource ('Reach a human via SMS') and the triggering context ('when your task requires real-world coordination'), and the tool name confirms sending. It never names a sibling (send_email, send_fax, place_call, ai_call) to differentiate, so the agent must infer channel choice from the name alone.

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

Usage Guidelines4/5

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

Gives a strong hard prerequisite chain: 'Requires create_payment with toolName=send_sms and phoneNumber+message at payment time,' plus the rule that the phoneNumber must match the paid one. It also lists refusal conditions (no links, per-destination send limits, do-not-contact list), but offers no explicit comparison against alternative contact tools like send_email or place_call.

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.