Skip to main content
Glama

Preview Sms Announcement

preview_sms_announcement

Prepare the exact SMS body and eligible audience for host review. Use a separate brief message (usually <=160 characters), not the full email. Host introduction, event link and STOP footer are added automatically. The complete text must fit three SMS segments. Returns body, audienceSize, previewId and expiry; nothing is sent. Show these before send_sms_announcement.

Input Schema

NameRequiredDescriptionDefault
messageYesA brief SMS version, usually at most 160 characters. Do not add the host introduction, event link or STOP footer; the server adds them.
event_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior4/5

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

Annotations declare readOnlyHint=false, destructiveHint=false, openWorldHint=false, and the description adds substantive context: nothing is sent, the host introduction/event link/STOP footer are auto-appended, text must fit three segments, and it returns body/audienceSize/previewId/expiry. The auto-append and 'nothing is sent' details go well beyond the annotations, though it does not clarify the side effect implied by readOnly=false.

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?

Six short sentences, front-loaded with purpose and ending on the routing directive. Every sentence carries information, though the content is dense and could be slightly tighter.

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?

With no output schema, the description takes responsibility for return values (body, audienceSize, previewId, expiry) and adds the operational constraints (three segments, auto-appended elements). An agent has everything needed to invoke and interpret this 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 only 50%, so the description must compensate. It richly explains the 'message' parameter (brief SMS, ~160 chars, three-segment limit, do not add footer/host intro). event_id is left to the schema pattern and inferred from context, but the primary parameter semantics are well covered.

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+resource combination ('Prepare the exact SMS body and eligible audience') and clearly frames this as a preview step distinct from the actual send. The agent can immediately tell this differs from send_sms_announcement without opening any schema.

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 positions this as a prerequisite: 'Show these before send_sms_announcement', and warns to use a brief separate SMS message rather than the full email. Both the when and the content constraint are spelled out.

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.