Skip to main content
Glama
Sign In
suprsonic-mcp

suprsonic-mcp

by O-mega-Enterprise
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

sms

Send text or WhatsApp messages via one API call. Defaults to text for reliable delivery; WhatsApp requires recipient opt-in within 24 hours.

Instructions

Send SMS or WhatsApp messages. Default channel is SMS (reliable delivery). WhatsApp requires recipient opt-in: they must have messaged your Business number within 24 hours. Cost: 1 credit.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "to": "<to>",
      "message": "<message>"
    },
    "name": "sms"
  }
}

Input Schema

NameRequiredDescriptionDefault
toYesPhone number (E.164).
channelNoDelivery channel. Auto sends via SMS. WhatsApp requires opt-in: recipient must have messaged your Business number in the last 24 hours, otherwise the message is silently dropped by Meta.auto
messageYesMessage text.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.3.1
    • changedInput schema / properties / channel / description
      Previous value: -"auto, sms, or whatsapp"New value: +"Delivery channel. Auto sends via SMS. WhatsApp requires opt-in: recipient must have messaged your Business number in the last 24 hours, otherwise the message is silently dropped by Meta."
    • addedInput schema / properties / channel / enum
      Added value: +[
+  "auto",
+  "sms",
+  "whatsapp"
+]
    • changedInput schema / properties / message / description
      Previous value: -"Message text"New value: +"Message text."
    • changedInput schema / properties / to / description
      Previous value: -"Phone number in E.164 format (e.g. +1234567890)"New value: +"Phone number (E.164)."
  2. First observedv0.3.0

TDQS

A4/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It usefully discloses a credit cost of 1 and the WhatsApp 24-hour opt-in window, but says nothing about failure handling, delivery confirmation, rate limits, or what happens to the credit if a message is dropped. It covers the notable constraints without giving a full behavioral picture.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with the core action, then the default-channel behavior, then the opt-in caveat and cost. Every sentence carries information an agent needs, with no filler or restatement of the tool name.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a three-parameter send tool with no output schema, the description covers the essentials: action, channel default, the WhatsApp eligibility constraint, and cost. It does not describe what a successful send returns (message ID, delivery status) or error behavior, which would matter for an agent that must confirm delivery.

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

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so 'to', 'message', and the channel enum are already fully documented in the schema, including the silent-drop warning for WhatsApp. The description's channel comments align with the schema (default 'auto' routes to SMS) but add no syntax or formatting detail beyond it. Baseline 3 is appropriate.

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 leads with a specific verb and resource ('Send SMS or WhatsApp messages') and immediately scopes the channels supported. None of the listed siblings (email-verify, tts, scrape, etc.) overlaps with outbound messaging, so there is no ambiguity to resolve. An agent knows exactly what this tool does from the first sentence.

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 real selection guidance between the two channels: SMS is framed as the default and 'reliable delivery', and WhatsApp is conditioned on the recipient having messaged your Business number within 24 hours. What is missing is any statement of when not to use the tool at all, or a pointer to an alternative channel/tool if WhatsApp is unavailable.

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

Deploy Server

Other Tools