SMS MCP server: how to let AI agents send texts safely

An SMS MCP server is a Model Context Protocol endpoint that gives an AI agent, such as Claude, ChatGPT or Cursor, a set of texting tools: send a message, manage contacts, build a campaign. You can let an agent text real people safely when the server enforces consent, opt-outs and quiet hours instead of the model, and when the agent has no way to buy numbers or register brands by itself.

This post explains what that looks like in practice on Ready's MCP server. It covers what the tools do, when to use OAuth and when to use an API key, how test keys let an agent rehearse without texting anyone, and which guardrails matter once the agent reaches a real phone. It also works through the per-segment math, because an agent that likes emoji can triple your bill without anyone noticing.

What an SMS MCP server actually is

MCP (Model Context Protocol) is a standard way for an AI client to discover and call tools on a remote server. You don't write glue code for each model. You point the client at one URL, it authenticates, and the model sees a list of tools it can call, with descriptions it can reason about.

Ready runs a remote MCP server at https://api.tryready.com/mcp. Clients that support remote MCP servers can connect to it, including Claude, ChatGPT custom connectors, Claude Code and Cursor. Once connected, the agent can text, look up a conversation or set up a campaign as part of whatever task you gave it.

The difference from a plain REST integration is who decides when to call. In a normal SMS API integration, your code decides exactly when POST /v1/messages fires. With MCP, the model decides. That shift is the reason the guardrails below matter more than the tool list.

Full reference: https://docs.tryready.com/api/mcp.

What Ready's MCP tools can do (and what they can't)

An agent connected to Ready's MCP server can:

• Send texts to a single contact (the send_sms tool)
• Manage contacts: create, update and look them up
• Read and work with conversations, so the agent has the thread history before it writes anything
• Build and send campaigns to a list
• Enroll contacts in drip campaigns you've already set up
• Check number deliverability, so the agent can catch a bad or unreachable number before it spends money on it
• Read billing, so the agent can check the prepaid balance before it starts a large send

Some things are left out on purpose. MCP has no tools for buying numbers or registering. An agent can't provision a phone number, submit a 10DLC brand or campaign registration, or change your carrier setup. Those actions cost money and carry legal weight with carriers, and a model that misreads a prompt shouldn't be able to trigger them. A person does registration in the app, where most approvals take 2 to 7 days.

One more clarification. The AI agent is yours: the one you build or the one running in your client. Ready no longer lets accounts create AI reply agents. Inside the product, AI helps write and check messages (the AI message writer and the spam-filter check). If your agent drafts replies to inbound texts, the decision to send them belongs to your design, and we recommend having a person approve them until you trust the setup.

OAuth or API key: picking the auth

The server accepts two kinds of authentication:

A practical rule: if a person sits in front of the agent and clicks "connect," use OAuth. Dynamic client registration means you don't hand out client IDs by hand. If the agent runs unattended on a server, use an API key, keep it in a secrets manager, and give that agent its own key so you can revoke it without breaking anything else.

If you run a platform with customer sub-accounts, scope keys accordingly. An agent working for one customer should not hold credentials that reach another customer's contacts.

Test keys: let the agent rehearse before it texts anyone

This is the most useful feature for teams building agents, and it gets skipped too often.

A test key simulates send_sms and refuses every other tool that changes or bills something. Point your agent at the MCP server with a test key and it can go through its whole reasoning loop: decide to text someone, write the message, call the send tool. No real text goes out and nothing is charged. If the agent tries to build a campaign, enroll contacts in a drip campaign or make any other change that writes data or costs money, the call is refused.

What to check during a test-key run:

1. Does the agent text people it shouldn't? Give it a prompt like "follow up with everyone who went quiet" and see who it picks.
2. How long are its messages? Agents tend to write long and friendly. Count characters and emoji (the cost section shows why).
3. Does it notice a refusal and stop? When a tool call is refused, a well-behaved agent reports back. A badly prompted one retries in a loop or looks for another way around.
4. Does it ask before bulk actions? Put "confirm with me before any campaign" in the system prompt and check that it actually does.

Only switch to a live key once the transcripts look boring.

The guardrails that matter when an agent can text real people

A prompt is a suggestion to the model. A guardrail is something the server enforces no matter what the model decides. When an agent has a send button, you want as many protections as possible in the second category.

Consent stays your system's job

Texting goes only to people who opted in. On Ready, cold outreach happens by phone and mail, and SMS goes to consented or replied leads. The REST API makes this explicit: POST /v1/messages takes "consent_attested": true, which is your promise that the recipient agreed to receive texts. Ready records the sender's attestation per bulk send and per API send that sets consent_attested (who sent, to how many, when), and that gives you an audit trail.

That record is not a per-contact consent record. Ready doesn't store each recipient's opt-in time, wording or page URL, and a keyword reply doesn't create one. Your system has to keep that. In practice, the agent should only ever pick contacts from a list your system has already filtered for consent. Don't let it infer consent from the content of a conversation. (A contact who signs up on a Ready-hosted opt-in page is the exception: Ready stores that sign-up, with the time, IP address and exact wording, and support@tryready.com can send you a copy.)

Opt-outs are enforced by the platform

When a contact replies STOP or UNSUBSCRIBE, the opt-out is honored and applies across every campaign, so that contact can't be texted again. Sends to opted-out numbers, numbers on your Ban list and known landlines are refused up front and not charged. If your agent tries to message someone who opted out, the platform says no. The model doesn't have to remember. Our guide to handling SMS opt-outs covers the keyword rules in detail.

Quiet hours apply even if the agent runs at 2 AM

Agents don't sleep, and a task scheduled in UTC can easily fire at 6 AM in the recipient's local time. Ready refuses or holds sends outside permitted local hours, based on the recipient's area. A one-to-one send is held only if the window opens within 6 hours (charged only when it goes out); otherwise the tool call is refused with QUIET_HOURS_BLOCK and the agent should report it, not retry. A campaign either waits for the window or skips those contacts, per its quiet-hours setting. If your send logic covers several timezones, see the timezone-aware quiet-hours fix.

Litigator and DNC scrubbing

You can screen known TCPA-litigator and DNC numbers out before a send. Scrubbing is off by default. When you switch it on for an account, it adds $0.003 per segment. A standalone scrub is also available at $0.005 per contact if you'd rather clean a list before the agent ever sees it. TCPA exposure runs $500 to $1,500 per text, so the cost of scrubbing is small next to the risk (the math is here). Treat scrubbing as a way to reduce risk, not as protection from lawsuits. Compliance is still the sender's responsibility.

No numbers, no registration

As noted above, an agent can't buy numbers or submit registrations through MCP. It can only send from what a person has already provisioned and registered.

What an agent's texts cost: the segment math

Ready's Standard rate is $0.0075/segment plus a $0.0045 carrier fee per segment. This all-in figure excludes the optional compliance surcharge: $0.003 per segment each for scrubbing and landline validation, when switched on. Replies you receive are billed the same way as sent texts. See pricing.

Segments are where agents get expensive. A GSM-7 segment holds 160 characters. A single emoji switches the whole message to unicode, where a segment holds 70 characters, or 67 per part when the message has more than one part.

Worked example (assumed numbers): your agent sends a follow-up to 1,000 opted-in leads.

• Version A, written by the agent: 175 characters with one emoji. 175 ÷ 67 rounds up to 3 segments. That's 3,000 segments × $0.0075 = $22.50, plus 3,000 × $0.0045 in carrier fees.
• Version B, after a "plain text, under 160 characters" instruction: 150 characters, no emoji, 1 segment. That's 1,000 × $0.0075 = $7.50, plus 1,000 × $0.0045. With scrubbing switched on, add 1,000 × $0.003 = $3.00.

One emoji and some extra length triple the cost. Ready replaces curly quotes, long dashes and ellipses with plain characters before sending, so those don't change the count. Emoji do. Put a length and character rule in your agent's system prompt, and have it check the balance with the billing tool before any campaign.

Throughput matters as well. A fresh standard 10DLC campaign typically gets about 1 to 4 segments per second. At an assumed 2 segments per second, Version A's 3,000 segments take about 25 minutes to send. On T-Mobile, the lowest trust tier caps a brand at roughly 2,000 messages a day. An agent told to "text everyone now" will run into those limits, so it should expect sends to queue rather than try again and again.

A rollout checklist (and when MCP is the wrong tool)

1. Register your brand and campaign in the app. Most approvals take 2 to 7 days. Until then, an account can send up to 500 texts a month at its normal rate.
2. Connect the agent with a test key and review its transcripts.
3. Give it a pre-filtered, consented contact list, not your whole CRM.
4. Add system-prompt rules: plain text, under 160 characters, confirm before any campaign, stop on refusal.
5. Turn on scrubbing, or run a standalone scrub, for any list that's older than a few months.
6. Switch to a live key with its own revocation path. Start with one-to-one sends before campaigns.

When not to use MCP: if your backend already knows exactly when to send ("order shipped" sends a text), call POST /v1/messages directly. That path is deterministic, and you don't need a model making the decision (docs). And if all you want is the lowest raw per-segment price and you'll build compliance yourself, Twilio lists about $0.0083/segment, which is less per segment than our Standard rate. What you get with Ready is the compliance layer and the platform: opt-outs, quiet hours, scrubbing, registration in the app, an inbox and campaigns.

FAQ

What is an SMS MCP server?

An SMS MCP server is a remote endpoint that exposes texting actions as tools an AI agent can call through the Model Context Protocol. Instead of writing API code for each model, you connect the AI client to one URL, and the agent can send texts, manage contacts and run campaigns.

Can ChatGPT or Claude send text messages?

Yes, if you connect them to an SMS MCP server such as Ready's at https://api.tryready.com/mcp. Claude, ChatGPT custom connectors, Claude Code and Cursor can all authenticate with OAuth or an API key and then call the send tool.

How do I test an AI agent's texting without sending real messages?

Use a Ready test key. It simulates send_sms and refuses every other tool that changes or bills something, so you can review the agent's decisions and message drafts without texting anyone or being charged.

Can an AI agent text someone who replied STOP?

No. On Ready, opt-outs apply across all campaigns, and sends to opted-out numbers are refused up front and not charged. The platform enforces this, so it doesn't depend on the model remembering.

Can an AI agent buy phone numbers or register 10DLC through MCP?

No. Ready's MCP server has no tools for buying numbers or registering. A person handles those in the app, and the agent can only send from numbers that are already provisioned and registered.

The practical takeaway

Giving an agent the ability to text is easy. Making sure it can only text the right people, at reasonable hours, with messages that don't cost three times what they should, takes more work. Put that work in the places the model can't override: platform-enforced opt-outs and quiet hours, a consented list your system filters, scrubbing, and no MCP access to numbers or registration. Then prove the agent's behavior with a test key before it goes live.

If you want to try it, sign up, add a card, and connect your agent using the MCP docs. Your first 20 one-to-one texts are free (campaigns are paid from the first text), so use them to check the live behavior before you register.