Skip to main content
Glama

Sparetext

Send a text to each person

send_sms_batch
Destructive

Send a different text to each person in one batch, like each guest's own name and table, from the user's own number. Write each text in full; nothing is filled in for you. Up to 100 recipients in all. Confirm the list and the wording with the user first. Returns a batchId: check progress with get_batch. For people who expect the texts only: carriers filter bulk and marketing (A2P) traffic on personal numbers.

Input Schema

NameRequiredDescriptionDefault
simNoOptional, Android only: which SIM sends them, numbered as on the phone.
send_atNoOptional: send later (ISO 8601, up to 30 days ahead).
messagesYesOne entry per text
device_idNoOptional: which phone sends them (see list_devices).
ttl_secondsNoOptional: drop any text not out this many seconds after it may go.

Output Schema

NameRequiredDescriptionDefault
noteNo
deviceYes
batchIdYes
messagesYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Adds real context beyond the annotations: the texts go out from the user's own number, the recipient cap is 100, nothing is templated, and a batchId is returned for follow-up. The note that carriers filter bulk/A2P traffic on personal numbers is unusually useful behavioral disclosure for a destructive, open-world send.

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-loads what the tool does and keeps the hard limits and confirmation requirement early. The trailing sentence about A2P filtering is slightly dense and its purpose takes a moment to parse, but every sentence carries 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?

Covers what an agent needs to invoke it correctly: cap, sender identity, confirmation requirement, return value and the follow-up tool, plus a deliverability caveat. An output schema exists and the description still usefully names the batchId key.

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 the baseline is 3, but the description adds meaning the schema lacks: 'Write each text in full; nothing is filled in for you' clarifies that per-recipient personalization must be authored in the messages array, and the 100-recipient cap reinforces the maxItems bound.

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 plus the key differentiator: 'a different text to each person in one batch', which separates it from send_sms. It also quantifies scope ('Up to 100 recipients') and identifies the sending identity ('from the user's own number').

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a clear pre-call workflow ('Confirm the list and the wording with the user first') and a post-call pointer ('check progress with get_batch'), plus an implicit audience caveat about A2P filtering. It never explicitly contrasts with send_sms for single/repeated sends, so routing against that sibling is only inferred.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources