Skip to main content
Glama
Sign In

YouSpot

by com.youspot
OverviewDiscussionsAdmin

Text the user

send_text_to_user
Destructive

Send a short text message (iMessage/SMS) to the user's own phone, the number they verified on the iMessage or SMS integration. Sends right now by default; pass send_at to schedule it for later (a reminder for tomorrow morning, a nudge before a meeting). send_at must be ISO 8601 WITH the user's UTC offset, e.g. 2026-09-18T09:00:00-04:00: work out their timezone from the conversation or ask, never guess UTC. Scheduled texts can be listed with list_scheduled_texts and cancelled with cancel_scheduled_text. The recipient is always the user themself; no other number can be reached. If no verified number is on file, the response says so and carries the link to connect one. Keep messages short and concrete; there is a rate cap, so never use this for routine chatter. If a send returns setup instructions, relay them and wait for the user to complete that step before retrying. Never report a failed send as delivered.

Input Schema

NameRequiredDescriptionDefault
messageYesThe text to send (max 1000 characters).
send_atNoWhen to send, ISO 8601 with a UTC offset (e.g. 2026-09-18T09:00:00-04:00), up to 90 days out. Omit to send immediately.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / send_at
      Added value: +{
+  "description": "When to send, ISO 8601 with a UTC offset (e.g. 2026-09-18T09:00:00-04:00), up to 90 days out. Omit to send immediately.",
+  "type": "string"
+}
  2. Added

TDQS

A4.9/5.0
Behavior5/5

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

Adds substantial behavior beyond the annotations: a rate cap, the fact no other number can be reached, the no-verified-number response and its setup link, the instruction to relay setup steps before retrying, and the delivery-integrity rule 'never report a failed send as delivered.' Nothing here contradicts destructiveHint=true; the description simply tells the agent that sends are irreversible and must be confirmed truthful.

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 purpose and default behavior before the scheduling mechanics, and nearly every sentence carries an actionable rule. It is on the long side for two parameters, with the timezone example and the rate-cap caveat both slightly expansive, but no sentence is filler.

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?

No output schema exists, and the description compensates by describing response outcomes: the 'no verified number' case returns a connect link, setup instructions may come back on a send, and failures must be reported as failures. For a two-parameter mutation tool with annotations, this is complete enough to call correctly.

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 100%, so the baseline would be 3, but the description earns more: it demands ISO 8601 WITH the user's UTC offset, supplies a concrete example, and instructs the agent to derive the timezone from conversation or ask the user rather than guessing UTC. That is semantics an agent cannot get from the schema alone.

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?

Starts with a specific verb+resource ('Send a short text message (iMessage/SMS)') and immediately bounds the recipient to the user's own verified number, which distinguishes it from send_email, send_slack_message, and the scheduled-text siblings in the list. The channel and target are unambiguous.

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?

Explicitly states when to use scheduling ('a reminder for tomorrow morning, a nudge before a meeting') and names both alternatives by name: list_scheduled_texts for inspection and cancel_scheduled_text for cancellation. It also gives a when-not: 'never use this for routine chatter' because of the rate cap.

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

All YouSpot 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