Skip to main content
Glama

YouSpot

by com.youspot
OverviewDiscussionsAdmin

Text the user

send_text_to_user

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.

Input Schema

TableJSON 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.4/5.0
Behavior4/5

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

The description discloses important behaviors beyond the readOnlyHint=false annotation: it sends immediately by default, the recipient is always the user themself, no other number can be reached, and there is a rate cap. It also covers the no-verified-number fallback. It doesn't describe the success/error response shape, but there is no output schema.

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?

The description is dense and information-rich with every sentence earning its place, but it is a single long paragraph. It could be slightly more scannable, though the key points are front-loaded and clear.

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 two-parameter tool with no output schema, this description is complete: it covers sending now vs scheduling, timezone requirements, recipient restrictions, rate limits, and the behavior when no verified number exists. Nothing essential is missing 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.

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 significant semantics: send_at must include the user's UTC offset, never guess UTC, and ISO 8601 format with an example. It also reinforces message length expectations, adding value beyond 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?

The description states a specific verb and resource: 'Send a short text message (iMessage/SMS) to the user's own phone.' It also clarifies the exact recipient scope, which distinguishes it from general messaging tools like send_slack_message or send_email.

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?

It gives explicit use cases (reminders, nudges before meetings), a clear when-not ('never use this for routine chatter' due to rate cap), and names scheduling-related alternatives (list_scheduled_texts, cancel_scheduled_text). However, it does not explicitly contrast with send_slack_message or send_email for choosing the right messaging channel.

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