Skip to main content
Glama
Sign In

SelieeAI

by io.github.neebloltd
OverviewDiscussionsAdmin

Create SMS Campaign

create_sms_campaign
Destructive

[write] Creates a DRAFT SMS campaign (the result has its id and uuid); nothing is sent until it is started in the panel, which needs the merchant's confirmation that the recipients agreed to receive it. sms_account_id or sms_account_uuid is the sending account. Give either sms_campaign_body ({name} or any {variable} is replaced by each recipient's value) or a template (sms_template_id / sms_template_uuid; its text is copied). sms_campaign_footer is added on a new line after every message; sms_campaign_schedule_datetime (ISO 8601) is when it goes out once started. A saved list (sms_list_id or sms_list_uuid; see list_sms_lists) adds all its numbers as recipients; numbers on the opt-out list are kept as skipped.

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": {
      "sms_campaign_title": "<sms_campaign_title>"
    },
    "name": "create_sms_campaign"
  }
}

Input Schema

NameRequiredDescriptionDefault
sms_list_idNo
sms_list_uuidNo
sms_account_idNo
sms_template_idNo
sms_account_uuidNo
sms_campaign_bodyNo
sms_template_uuidNo
sms_campaign_titleYes
sms_campaign_footerNo
sms_campaign_schedule_datetimeNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true, openWorldHint=true, and non-idempotent; the description goes beyond them by clarifying that this call only creates a draft, that activation requires consent confirmation in the panel, and that opt-out numbers are retained as skipped rather than dropped. It does not cover rate limits or validation errors, keeping it short of a 5.

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 the draft/write framing and then grouped by parameter concern (account, content, footer/schedule, recipients), so it is easy to scan. It is dense with backticked identifiers and parenthetical asides, but no sentence is redundant.

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 10-parameter mutation with no output schema and no schema descriptions, the definition covers essentially every field, the deferred-send model, and recipient side effects. Minor gaps remain: it does not say what happens if both a body and a template are supplied, or how optional account fields default when omitted.

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?

With 0% schema description coverage across 10 params, the description carries the full burden and does so: it explains the id/uuid account pair, body with `{name}`/`{variable}` substitution, template-by-id-or-uuid whose text is copied, footer placement on a new line, ISO 8601 schedule semantics, and list-derived recipients including opt-out handling. Only sms_campaign_title is left to the schema, which is self-evident.

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?

"[write] Creates a DRAFT SMS campaign (the result has its id and uuid)" states a specific verb, resource, and resulting state, and the draft framing immediately separates it from send_sms or list_sms_campaigns. The scope of what the tool does and does not do (nothing is sent) is unambiguous.

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 explains the precondition that continues after creation (the campaign must be started in the panel, with merchant confirmation that recipients agreed) and points to list_sms_lists for obtaining a list. It does not explicitly contrast with send_sms or create_email_campaign, but the draft-only framing implies the boundary.

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

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