Provides tools for sending, receiving, and scheduling SMS and MMS messages, managing conversation threads, and retrieving Twilio account and phone number information.
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., "@Twilio SMS MCP Server Send a text to +12025551234 asking if they're free for lunch today"
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.
Production-grade Model Context Protocol server for Twilio SMS.
Send, receive, schedule, redact, and inspect SMS/MMS conversations through any MCP-compatible client — VS Code Copilot, Codex CLI, Claude Desktop, and more.
Tool | Description |
| Send a single SMS or MMS |
| Send the same message to up to 100 recipients with bounded concurrency |
| Schedule a message for future delivery (requires Messaging Service) |
| Cancel a scheduled message |
| List outbound messages with optional filters |
| Fetch one message by SID, enriched with delivery status |
| Delete a message record from Twilio |
| NEW — Redact message body for GDPR / privacy compliance |
| List inbound webhook-captured messages |
| Merge local inbox with Twilio history for a full thread |
| Mark inbox messages as read |
| List Twilio phone numbers on the account |
| Carrier and line-type intelligence lookup |
| NEW — Validate any phone string and return E.164 + national format |
| NEW — Daily SMS/MMS usage and cost analytics |
| Account balance, status, and metadata |
URI | Description |
| High-level account summary (SID, sender, version) |
Prompt | Description |
| AI-assisted SMS drafting given a recipient and topic |
| Summarize all messages exchanged with a number |
Retry with exponential backoff on transient Twilio API errors (429, 5xx, network failures)
Webhook rate limiting — in-memory per-IP throttle (120 req/min)
Structured logging — timestamped, leveled, consistent format on stderr
Input validation — Pydantic v2 strict schemas with E.164, SID pattern enforcement
Webhook signature verification — Twilio RequestValidator on all inbound hooks
Health and readiness endpoints — /healthz, /readyz for orchestrators
Docker multi-stage build with non-root user, health checks, persistent volume
py.typed marker for downstream type-checker compatibility
Related MCP server: Twilio MCP Server
Python 3.11+
A Twilio account and a Twilio phone number
For scheduled messages: a Twilio Messaging Service SID
For inbound messages: a publicly reachable webhook URL
Docker Desktop (optional, for container deployment)
cp env.example .env # fill in your Twilio credentials; for local runs set TWILIO_DB_PATH=inbox.db
pip install -e ".[dev]"
pytest # run the test suite
python -m twilio_sms_mcp.boot # start MCP + webhook serverAdd to your VS Code settings.json or .vscode/mcp.json:
{
"mcp": {
"servers": {
"twilio-sms": {
"command": "python",
"args": ["-m", "twilio_sms_mcp.boot"],
"env": {
"TWILIO_ACCOUNT_SID": "ACxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
"TWILIO_AUTH_TOKEN": "your_auth_token_here",
"TWILIO_FROM_NUMBER": "+12025551234"
}
}
}
}
}Add to claude_desktop_config.json (macOS: ~/Library/Application Support/Claude/, Windows: %APPDATA%\Claude\):
{
"mcpServers": {
"twilio-sms": {
"command": "python",
"args": ["-m", "twilio_sms_mcp.boot"],
"env": {
"TWILIO_ACCOUNT_SID": "ACxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
"TWILIO_AUTH_TOKEN": "your_auth_token_here",
"TWILIO_FROM_NUMBER": "+12025551234"
}
}
}
}codex mcp add twilio-sms \
-- docker run --rm -i \
--env-file .env \
-p 8080:8080 \
-v twilio_sms_data:/data \
twilio-sms-mcpVerify:
codex mcp get twilio-sms
codex mcp listBuild and run:
docker build -t twilio-sms-mcp .
docker run --rm -i \
--env-file .env \
-p 8080:8080 \
-v twilio_sms_data:/data \
twilio-sms-mcpOr use Docker Compose:
docker compose up -dConfigure Twilio to POST to <your-host>/webhook/sms for inbound messages.
Configure Twilio to POST to <your-host>/webhook/status for delivery callbacks.
Set TWILIO_PUBLIC_WEBHOOK_BASE_URL when behind a reverse proxy or ngrok.
Keep TWILIO_VALIDATE_WEBHOOK_SIGNATURES=true in production.
Variable | Required | Default | Description |
| Yes | — | Twilio Account SID (starts with |
| Yes | — | Twilio Auth Token |
| Yes | — | Default sender in E.164 format |
| No | — | Required for |
| No | — | Override for webhook signature validation |
| No | — | Public URL for webhook signature validation |
| No |
| Disable only for local debugging |
| No |
| Max parallel sends for |
| No |
| Logging verbosity |
| No |
| SQLite database location |
| No |
| Webhook HTTP server port |
| No |
| Retry count for transient API errors |
| No |
| Base delay in seconds between retries |
| No |
| MCP transport: |
| No |
| Bind address for SSE/HTTP transport |
| No |
| Port for SSE/HTTP transport |
pip install -e ".[dev]"
pytest -vUse HTTPS for webhook delivery
Set TWILIO_VALIDATE_WEBHOOK_SIGNATURES=true
Use a Messaging Service SID for sender pooling and scheduled messages
Persist /data volume so inbox state survives restarts
Never commit .env — it is excluded via .gitignore and .dockerignore
Monitor /healthz and /readyz from your orchestrator
Set TWILIO_LOG_LEVEL=WARNING in high-traffic environments
Fetch account balance, status, and friendly name.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover key behavioral traits (read-only, non-destructive, idempotent, open-world), so the bar is lower. The description adds value by specifying what data is fetched (balance, status, friendly name), which is useful context beyond the annotations. It does not contradict the annotations, as 'Fetch' aligns with read-only behavior.
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 a single, efficient sentence that directly states the tool's purpose with zero waste. It is front-loaded and appropriately sized for a no-parameter tool, making it easy for an agent to parse and understand quickly.
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?
Given the tool's simplicity (0 parameters, annotations covering safety and behavior, and an output schema), the description is complete enough. It specifies what data is retrieved, which complements the structured fields. However, it lacks usage guidance, which slightly reduces completeness for agent decision-making.
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?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately focuses on the tool's purpose without redundant parameter details, earning a high baseline score for not adding unnecessary information.
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 clearly states the specific action ('Fetch') and the resources retrieved ('account balance, status, and friendly name'). It distinguishes itself from sibling tools like 'sms_usage_stats' by focusing on account-level information rather than usage metrics, making the purpose unambiguous.
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 description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, such as authentication, or differentiate it from similar tools like 'sms_usage_stats', leaving the agent to infer usage context solely from the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate a phone number and return its E.164 form, national format, and country code.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering safety and idempotency. The description adds value by specifying the validation aspect and output formats (E.164, national format, country code), but doesn't disclose behavioral traits like error handling for invalid numbers, rate limits, or authentication requirements beyond what annotations imply.
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 a single, efficient sentence that front-loads the core action ('Validate a phone number') and immediately lists the three return values. Every word contributes essential information without redundancy or unnecessary elaboration.
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?
Given the tool's low complexity (1 required parameter), rich annotations covering safety and idempotency, and the presence of an output schema (which likely details the return structure), the description is mostly complete. It could improve by mentioning use cases or prerequisites, but it adequately conveys the tool's function and outputs for an agent to invoke it correctly.
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 description coverage is 0%, but the description compensates by explaining the purpose of the parameters: 'phone_number' is for validation and reformatting to E.164, and 'country_code' is for disambiguating national numbers. However, it doesn't detail the exact input formats or constraints beyond what the schema's min/max length and type indicate.
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 clearly states the specific action ('Validate a phone number') and the outputs ('return its E.164 form, national format, and country code'), distinguishing it from sibling tools like sms_lookup_number or sms_list_numbers which have different purposes. It uses precise terminology that indicates transformation and validation rather than lookup or listing.
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 description provides no guidance on when to use this tool versus alternatives like sms_lookup_number (which might provide additional carrier info) or sms_list_numbers (which lists owned numbers). It mentions validation and reformatting but doesn't specify use cases such as preparing numbers for sending SMS or standardizing user input.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Redact the body of a delivered message. Twilio keeps metadata but clears the text for compliance / privacy.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond annotations: it clarifies that Twilio keeps metadata but clears the text, which is crucial for understanding the partial nature of this redaction. Annotations already indicate destructive (true) and idempotent (true), but the description provides specific implementation details about what gets destroyed (text) versus preserved (metadata).
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?
Two concise sentences with zero waste. The first sentence states the action and target, the second explains the behavioral outcome and purpose. Every word earns its place in this efficiently structured description.
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?
Given the destructive nature (annotations show destructiveHint: true), the description provides good context about what happens during redaction. With an output schema present, the description doesn't need to explain return values. However, it could mention that this only works on delivered messages (not scheduled or failed ones) for full completeness.
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?
With 0% schema description coverage, the description doesn't mention the 'sid' parameter at all. However, since there's only one required parameter and the schema provides a clear pattern (SM followed by 32 hex characters), the baseline is appropriate. The description doesn't compensate for the coverage gap but the simplicity of the single parameter keeps it from being lower.
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 clearly states the specific action ('redact'), target resource ('body of a delivered message'), and purpose ('for compliance/privacy'). It distinguishes this from siblings like sms_delete_message (full deletion) and sms_get_message (retrieval without modification).
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 description provides clear context about when to use this tool ('for compliance/privacy') and implies it's for delivered messages only. However, it doesn't explicitly state when NOT to use it or name specific alternatives like sms_delete_message for complete removal versus metadata retention.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve daily SMS/MMS usage statistics for the account, useful for cost monitoring and analytics.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover key behavioral traits: read-only, non-destructive, idempotent, and open-world. The description adds value by mentioning the tool's utility for 'cost monitoring and analytics,' which provides practical context beyond the annotations. However, it doesn't disclose additional details like rate limits, authentication needs, or specific data formats, leaving some behavioral aspects uncovered.
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 concise and front-loaded: a single sentence that directly states the tool's purpose and utility. Every word earns its place, with no redundancy or unnecessary elaboration, making it efficient and easy to parse for an AI agent.
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?
Given the tool's moderate complexity, rich annotations (read-only, idempotent, etc.), and the presence of an output schema, the description is reasonably complete. It covers the core purpose and usage context. However, it could be more comprehensive by mentioning sibling tools or specific limitations, but the annotations and schema provide sufficient support for basic understanding.
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?
The input schema has 100% description coverage for its parameters ('category' and 'days'), with clear defaults and constraints. The description doesn't add any parameter-specific information beyond what the schema provides, such as explaining 'category' options in more detail. Since schema coverage is high, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
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 clearly states the tool's purpose: 'Retrieve daily SMS/MMS usage statistics for the account.' It specifies the resource (SMS/MMS usage statistics) and the action (retrieve). However, it doesn't explicitly differentiate from siblings like 'sms_account_info' which might also provide account-level data, though the focus on 'usage statistics' suggests a distinction.
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 description provides clear context for usage: 'useful for cost monitoring and analytics.' This implies when to use the tool—for monitoring expenses and analyzing usage patterns. It doesn't specify when not to use it or name alternatives, but the context is helpful for guiding selection among siblings focused on messaging operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v2.0.0sms_account_infosms_cancel_scheduledsms_delete_messagesms_format_numbersms_get_conversationsms_get_messagesms_list_inboxsms_list_numberssms_list_sentsms_lookup_numbersms_mark_readsms_redact_messagesms_schedulesms_sendsms_send_bulksms_usage_statsMost tools have distinct purposes targeting different SMS operations like sending, scheduling, listing, and managing messages, but some ambiguity exists between 'sms_list_inbox', 'sms_list_sent', and 'sms_get_conversation' without descriptions, which could cause confusion in message retrieval contexts. Overall, the set is well-differentiated with clear resource-action pairs.
All tool names follow a consistent 'sms_' prefix with snake_case and clear verb_noun patterns (e.g., 'sms_send', 'sms_list_numbers', 'sms_delete_message'), making them predictable and easy to parse. There are no deviations in naming conventions across the 16 tools.
With 16 tools, the count is slightly high but reasonable for a comprehensive SMS management server covering account info, message handling, number operations, and usage stats. It might feel heavy but each tool appears to serve a specific function in the domain without obvious redundancy.
The tool set covers core SMS functionalities like sending, scheduling, listing, and deleting messages, but lacks clear update operations (e.g., no tool for modifying scheduled messages) and has several tools without descriptions, making it hard to assess full lifecycle coverage. Gaps in update capabilities could lead to agent workarounds.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Build and send email, SMS, and push straight from your AI agent.
Envoyez des SMS et gérez vos campagnes directement depuis vos agents IA.
Communication stack for AI agents: SMS, AI voice calls, phone numbers, and account events.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/0x-Professor/Twilio-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
