x402-sms-mcp
Allows sending SMS messages to US phone numbers via Twilio, with automatic opt-out language and compliance attestation.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@x402-sms-mcpSend 'Task done' to +15551234567, I consent."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
x402-sms-mcp
A paid MCP server that lets AI agents send SMS messages to US phone numbers.
Each send_sms tool call:
Sends a transactional SMS via a verified toll-free number
Auto-appends
Reply STOP to opt outif the body doesn't include opt-out languageCosts $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
/sendcalls short-circuit to a503 delivery_pending_tfv_approvalresponse 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:
A small amount of ETH for gas (free from https://www.coinbase.com/faucets/base-ethereum-sepolia-faucet)
USDC for payments (free from https://faucet.circle.com, select Base Sepolia)
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-
+1E.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 outto every messageHonors 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 |
| yes | — |
| no |
|
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 ( | "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 ( | "SMS not sent — this buyer wallet hit the per-X rate limit" + | no |
Twilio-side rejection (e.g. invalid number | 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 DesktopThe 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 toolsend_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'.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Recipient phone number in E.164 format: +1XXXXXXXXXX (US only). | |
| message | Yes | SMS body. 1-1600 characters. Will be automatically suffixed with ' Reply STOP to opt out.' if no opt-out language is present. | |
| opt_in_attestation | Yes | Must 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
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.
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.
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.
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.
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.
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 tool update
v0.2.0- First observed
send_sms
TDQS
Scored across 1 tool
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.
The single tool name 'send_sms' follows the verb_noun convention and is descriptive. With only one tool, there are no inconsistencies to assess.
The server is purpose-built for sending SMS messages, and one tool fully serves that purpose. The count is appropriate for the narrow scope.
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
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
The Mobile Text Alerts SMS MCP server enables your AI to send SMS messages & manage contacts
Give AI agents real phone numbers, messages, and voice calls via MCP.
Phone, SMS & email for AI agents — one remote MCP endpoint, OAuth login, zero install.
Hosted email MCP for AI agents with inboxes, send/receive, memory, recovery, and credits.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceMCP server for provisioning dedicated real-SIM US phone numbers, receiving inbound SMS, and extracting OTP codes. Built for AI agents automating phone verification workflows.201MIT

opendexterofficial
AlicenseNot gradedqualityCmaintenanceAn MCP server that enables AI agents to search, pay for, and call paid APIs using the x402 protocol, with automatic USDC settlement.2MIT- AlicenseNot gradedqualityFmaintenanceMCP server for the x402 protocol that lets AI agents discover and call payment-gated HTTP APIs automatically.77Apache 2.0
- AlicenseNot gradedqualityBmaintenanceMCP server that lets AI agents retrieve the latest SMS verification code by keyword, using self-hosted phone forwarding and persistent storage.22MIT