mcp-twilio-sms

send_sms

Send SMS text messages via Twilio and receive a message SID to track delivery status.

Instructions

Send an SMS text message via Twilio.

WORKFLOW:

Call send_sms(to="+33612345678", body="Your message here")
Get back a message_sid and status
Optionally call get_sms_status(message_sid=...) later to confirm delivery

PARAMETERS:

to: Recipient phone number in E.164 format ("+33612345678" for France, "+15551234567" for US). Must include country code with + prefix.
body: The text message content. Max 1600 characters (messages over 160 characters are split into segments and billed per segment).
from_number: Override the sender phone number. Default: TWILIO_PHONE_NUMBER env var. Must be a Twilio number you own.

RETURNS:

message_sid: Unique identifier for tracking this message
status: Initial status (typically "queued")
to/from: The phone numbers used
segments: Number of message segments (billing units)

TIPS:

Keep messages under 160 characters for 1 segment (cheapest)
Unicode characters (accents, emojis) reduce the limit to 70 chars/segment
Use get_sms_status() to verify delivery if needed

Args: to: Recipient phone number in E.164 format (e.g. "+33612345678") body: The text message content (max 1600 characters) from_number: Sender phone number override (default: TWILIO_PHONE_NUMBER env var)

Input Schema

TableJSON Schema

Name	Required	Description	Default
`to`	Yes
`body`	Yes
`from_number`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 28, 2026

TDQS

A4.7/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses segment-based billing, the 160/70-character segment boundaries, the unicode penalty, and the default sender resolution via the TWILIO_PHONE_NUMBER env var. It does not mention auth/credential requirements, rate limits, or that a sent SMS cannot be recalled, so it falls short of a 5.

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?

Front-loaded with the purpose, then cleanly sectioned into WORKFLOW/PARAMETERS/RETURNS/TIPS, which is easy to scan. The trailing 'Args:' block restates the three parameters almost verbatim, adding length without new information.

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?

An output schema exists and the description still summarizes the return fields (message_sid, status, to/from, segments) in a way that tells the agent what to pass to get_sms_status. Format, limits, defaults, and the follow-up workflow are all covered; nothing needed to invoke it correctly is missing.

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

Parameters5/5

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

Schema coverage is 0% and every parameter is fully compensated: 'to' specifies E.164 with country-code and example formats, 'body' gives the 1600-char max and segment splitting behavior, and 'from_number' states the default and the Twilio-number ownership constraint.

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?

States a specific verb+resource ('Send an SMS text message via Twilio') and the resource is unambiguous against the only sibling, get_sms_status, which reads status rather than sending.

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?

Provides an explicit numbered workflow showing this is the entry point, then routes to the alternative ('Optionally call get_sms_status(message_sid=...) later to confirm delivery') with the condition that selects it.

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

Deploy Server