Skip to main content
Glama

SMS Everyone MCP by usefulapi

by io.usefulapi
OverviewDiscussionsAdmin

Send SMS

smseveryone_send_sms
Destructive

WRITE: SENDS REAL SMS to real people and SPENDS CREDITS from the user's SMS Everyone account; a sent message cannot be recalled (a campaign scheduled for later can be cancelled with cancel_campaign). One message text to 1 to 25 phone numbers in international format without "+" (e.g. 61400123456 for Australia, 6421123456 for New Zealand). Cost = credits per part x number of parts x recipients: a text is 160 characters per part (153 when longer), and one emoji or non-English character makes it unicode: 70 characters per part (67 when longer), more credits. Numbers on the account's optout list are skipped. The originator is where the message appears to come from and must be one registered with SMS Everyone for the account (an Australian alphanumeric sender must be ACMA registered). Optional time_scheduled (YYYYMMDDHHmm in the account's time zone; a time in the past sends at once). Only send what the user explicitly asked for; confirm the text, recipients and sender first. No stored lists, no bulk. SMS Everyone REST: POST /api/campaign with Action create.

Input Schema

NameRequiredDescriptionDefault
confirmYesMust be true only after the user confirms this exact write and its affected recipients/campaign.
messageYesThe message text (long texts are split into several parts and cost more).
originatorYesSender: the registered originator exactly as SMS Everyone gave it (a mobile number without +, a 4 to 6 digit short code, or a registered alphanumeric name; names are case sensitive).
destinationsYes1 to 25 recipient numbers in international format with country code, no leading 0, e.g. 61400123456.
time_scheduledNoOptional send time YYYYMMDDHHmm in the account's time zone, e.g. 203507301300 = 30 July 2035, 1pm. Omit to send now.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already flag destructive/openWorld/non-idempotent, and the description goes further with credit spend, irreversibility, optout-list skipping, and the originator registration constraint. It does not cover response timing or delivery-status follow-up (e.g. get_delivery_status), which is the main remaining gap.

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 write/irreversible warning, which is the highest-priority fact, and all sentences carry actionable content. It is a dense wall of text in a single paragraph, and the cost arithmetic is slightly over-elaborated for the 10% weight it deserves.

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 destructive, credit-spending write with no output schema, the description covers cost model, irreversibility, recipient constraints, sender registration rules, scheduling semantics, and the underlying REST call. An agent has everything needed to call it safely and correctly.

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

Parameters4/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 real value by explaining billing/segmentation for message (160 vs 153, unicode 70/67), the registered-originator requirement, and that a past time_scheduled sends immediately. Only the confirm parameter's contract is left to 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?

States a specific verb and resource (sends real SMS to 1-25 numbers) with explicit warning that it spends credits and is irreversible. It also names the sibling cancel_campaign as the alternative for scheduled messages, so an agent can separate this from the campaign-management tools.

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?

Explicit preconditions: 'Only send what the user explicitly asked for; confirm the text, recipients and sender first,' plus the exclusion 'No stored lists, no bulk' and the routing hint to cancel_campaign. This is a clear when/when-not with a named alternative.

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

All SMS Everyone MCP by usefulapi toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources