Skip to main content
Glama
UltraStarz
by UltraStarz

x402-sms-mcp

A paid MCP server that lets AI agents send SMS messages to US phone numbers.

Each send_sms tool call:

  1. Sends a transactional SMS via a verified toll-free number

  2. Auto-appends Reply STOP to opt out if the body doesn't include opt-out language

  3. Costs $0.03 USDC per message, paid automatically from the configured wallet via x402

No API keys. No Twilio account. The agent pays the toll, the message goes out.

Status (2026-05-22): Public beta on Base Sepolia (testnet). The seller's toll-free number is undergoing Twilio TFV approval (submitted 2026-05-14, still in queue). During this window /send calls short-circuit to a 503 delivery_pending_tfv_approval response before the buyer wallet signs anything, so no USDC is moved. The day Twilio approves the number, delivery flips on; pricing flips to Base mainnet shortly after.

Install in Claude Desktop / Cursor / Windsurf

Add this to your MCP config (~/Library/Application Support/Claude/claude_desktop_config.json on macOS):

{
  "mcpServers": {
    "x402-sms": {
      "command": "npx",
      "args": ["-y", "x402-sms-mcp"],
      "env": {
        "BUYER_PRIVATE_KEY": "0xYOUR_PRIVATE_KEY"
      }
    }
  }
}

Restart your MCP client. A send_sms tool will appear.

Related MCP server: opendexter

What you need

A wallet on Base Sepolia (testnet) funded with:

Generate a throwaway key:

node -e "const {generatePrivateKey,privateKeyToAccount}=require('viem/accounts');const k=generatePrivateKey();console.log('PRIVATE_KEY=',k);console.log('ADDRESS=',privateKeyToAccount(k).address)"

Use the printed address to claim from faucets, then put the printed key into your MCP config.

Try it

In Claude Desktop, ask:

Text my cell at +15551234567 when this long-running task finishes. The recipient (me) consents to receive this message.

Claude will call send_sms with opt_in_attestation: true. You'll get back a Twilio SID + the on-chain settlement hash. The transfer is visible at https://sepolia.basescan.org.

Compliance — please read

This MCP wraps a regulated SMS gateway. The operator (you) is responsible for ensuring every recipient has consented to receive messages before invoking send_sms. The opt_in_attestation: true argument is your legal attestation under TCPA and CTIA short-code/long-code rules.

Do NOT use this MCP to:

  • Send marketing or promotional content

  • Text strangers, scraped lists, or anyone who hasn't opted in

  • Send to non-US numbers (the seller currently rejects non-+1 E.164)

  • Send anything related to S.H.A.F.T.-C (Sex, Hate, Alcohol, Firearms, Tobacco, Cannabis)

The seller-side automatically:

  • Appends Reply STOP to opt out to every message

  • Honors carrier-level STOP/HELP keyword handling

  • Logs each send for audit purposes

If you have any doubt about consent, do not call this tool.

Configuration

Env var

Required

Default

BUYER_PRIVATE_KEY

yes

SMS_URL

no

https://x402-sms-server-production.up.railway.app/send

To point the MCP server at your own seller deployment, override SMS_URL.

Errors you might see

The MCP surfaces three distinct error shapes so the model can explain what happened to the user and decide whether to retry.

Cause

What you'll see in chat

Was payment taken?

Seller's toll-free number still in TFV review (HTTP 503)

"SMS not sent — service is in pre-launch wait" + the seller's submitted date and retry guidance

no

Buyer wallet exceeded per-minute/hour/day rate limit (HTTP 429)

"SMS not sent — this buyer wallet hit the per-X rate limit" + retry_after_seconds

no

Twilio-side rejection (e.g. invalid number 21211, opted-out 21610)

Friendly hint mapped from the Twilio error code + the full response body

yes (the send tried)

For the full mapping of Twilio error codes the MCP recognizes, see TWILIO_HINTS in src/index.ts.

How it works

Claude Desktop ──tool call──> MCP server (this package, on your machine)
                              │
                              │ x402 payment (USDC, Base Sepolia)
                              │ + to/message/opt_in_attestation
                              ▼
                              Public seller (Hono + Twilio on Railway)
                              │
                              │ Twilio dispatch
                              ▼
                              SMS lands on recipient's phone
                              │
                              │ Twilio SID + status
                              ▼
                              MCP server ──tool result──> Claude Desktop

The MCP server doesn't talk to Twilio directly. It signs an x402 payment with the buyer's wallet, sends the payment + message details to the seller endpoint, and the seller's verified toll-free number dispatches the SMS. Your private key never leaves your machine. The seller never sees it.

Roadmap

  • Now (2026-05-22): Base Sepolia testnet, TFV pending. Payment flow verified end-to-end; deliveries gated on Twilio approval.

  • Once TFV clears: Real US SMS delivery, testnet pricing held while we collect early traffic.

  • A few weeks out: A2P 10DLC Brand approval → higher per-day throughput tier.

  • Mainnet flip: Production launch, USDC settles on Base mainnet; Solana facilitator on roadmap after.

License

MIT

Available Tools

1 tool
send_smsA

Send one transactional SMS message to a US phone number. Costs $0.03 USDC per message, paid automatically from the configured wallet on Base Sepolia (testnet during beta, will flip to Base mainnet at launch). Messages are sent from a Twilio toll-free number and automatically get 'Reply STOP to opt out' appended if not already present. CRITICAL — only call this tool when ALL of the following are true: (1) the user has explicitly asked to text someone, or has previously set up an automation that texts; (2) the recipient is the user themselves OR someone the user has confirmed has consented to receive texts from this automation; (3) the content is transactional or informational (order updates, alerts, reminders, 2FA, agent task completion notifications) — NOT marketing, promotion, or unsolicited outreach. If unsure whether the recipient consented, ASK the user before calling. Setting opt_in_attestation: true is the operator's (user's) legal attestation that consent was obtained — it is not a no-op flag. Use cases: 'text me when the long-running task finishes', 'send Mom an order confirmation for the gift I just bought her', 'remind me at 3pm to call the dentist by texting my cell'.

ParametersJSON Schema
NameRequiredDescriptionDefault
toYesRecipient phone number in E.164 format: +1XXXXXXXXXX (US only).
messageYesSMS body. 1-1600 characters. Will be automatically suffixed with ' Reply STOP to opt out.' if no opt-out language is present.
opt_in_attestationYesMust be true. Operator's attestation that the recipient has consented to receive this message. Setting this to true when the recipient has NOT consented is a TCPA violation and exposes the operator to statutory damages.

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations provided, the description carries full burden and excels: it discloses per-message cost ($0.03 USDC), wallet network (Base Sepolia/testnet), Twilio toll-free sending, automatic opt-out suffix append, and the legal significance of opt_in_attestation. No behavioral trait is hidden.

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

Conciseness4/5

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

The description is longer than average, but every sentence adds necessary context (cost, source number, legal attestation, use cases). It is front-loaded with purpose and structured with a clear warning block. Slightly verbose but fully justified given the compliance stakes.

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 tool with no output schema and no annotations, the description is unusually complete. It covers purpose, cost, network, sender, opt-out behavior, consent requirements, and concrete examples. The only omission is return value format, but that is not essential for correct invocation.

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

Parameters3/5

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

Schema coverage is 100%, so baseline is 3. The description adds some color about opt_in_attestation ('not a no-op flag') and the opt-out suffix behavior, but these are largely repeated from the schema descriptions. The description does not materially reduce ambiguity beyond 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?

The description opens with a specific verb+resource: 'Send one transactional SMS message to a US phone number.' It clearly distinguishes transactional messaging from other types and specifies the US-only scope. Even without sibling tools, it fully communicates what the tool does.

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?

The CRITICAL section explicitly enumerates all four conditions for safe usage, includes examples of appropriate versus prohibited content, and instructs the agent to ask the user when consent is uncertain. This is model when-to-use guidance with clear exclusions.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool updatev0.2.0
    • First observedsend_sms

TDQS

A4.7/5.0

Scored across 1 tool

Disambiguation5/5

Only one tool exists, so there is no possibility of confusion or overlap with other tools. The tool's purpose is clearly defined and distinct.

Naming Consistency5/5

The single tool name 'send_sms' follows the verb_noun convention and is descriptive. With only one tool, there are no inconsistencies to assess.

Tool Count5/5

The server is purpose-built for sending SMS messages, and one tool fully serves that purpose. The count is appropriate for the narrow scope.

Completeness5/5

The tool covers the only operation needed for the stated domain (sending transactional SMS). No obvious missing features like message status retrieval are required for its intended use.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    D
    maintenance
    MCP server for provisioning dedicated real-SIM US phone numbers, receiving inbound SMS, and extracting OTP codes. Built for AI agents automating phone verification workflows.
    20
    1
    MIT
  • A
    license
    Not graded
    quality
    C
    maintenance
    An MCP server that enables AI agents to search, pay for, and call paid APIs using the x402 protocol, with automatic USDC settlement.
    2
    MIT
  • A
    license
    Not graded
    quality
    F
    maintenance
    MCP server for the x402 protocol that lets AI agents discover and call payment-gated HTTP APIs automatically.
    77
    Apache 2.0
  • A
    license
    Not graded
    quality
    B
    maintenance
    MCP server that lets AI agents retrieve the latest SMS verification code by keyword, using self-hosted phone forwarding and persistent storage.
    22
    MIT