Skip to main content
Glama
Arsel-SA

Arsel MCP Server

Official
by Arsel-SA

Update SMS Campaign

update-sms-campaign
Destructive

Update draft or scheduled SMS campaigns by editing content, sender, or target lists. Omitted fields remain unchanged; confirm before modifying scheduled sends.

Instructions

Update an SMS campaign. Only draft and scheduled campaigns can be edited. Editing a scheduled campaign changes what goes out at its scheduled time, so confirm with the user first. Omitted fields are unchanged.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesThe SMS campaign id.
fromNoPre-approved sender name, 3-11 characters. Ask the user if you don't know it.
nameNo
contentNoMessage text. Long or non-Latin text is split into several billed segments.
tag_idsNoTags to target.
list_idsNoLists to target.
descriptionNo
segment_idsNoSegments to target.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already flag destructiveHint=true and readOnlyHint=false, and the description adds meaningful context beyond that: the editable-state restriction, the side effect that edits to scheduled campaigns change what actually goes out, and that omitted fields are left unchanged. This is strong behavioral disclosure; it stops short of describing permissions or auth needs.

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?

Four short sentences, each carrying distinct information, with the editability constraint and destructive-caution front-loaded. No filler.

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 mutation tool with full annotations and no output schema, the description covers the key risks (state restriction, destructive scheduled-campaign edits, PATCH semantics). It is close to complete, arguably missing only return/confirmation behavior.

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 coverage is 75%, so most parameters are documented in the schema itself. The description adds a useful partial-update semantic ('omitted fields are unchanged') but does not expand on individual fields like tag_ids/list_ids/segment_ids targeting. 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?

States a specific verb ('Update') and resource ('SMS campaign'), which cleanly distinguishes it from the many sibling catalog entries (update-email-campaign, update-push-campaign, update-in-app-campaign). An agent can route to it without opening the schema.

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?

Explicitly states the precondition that only draft and scheduled campaigns are editable, and adds a caution to confirm editing scheduled campaigns with the user. There is clear when-to-use context, though no alternative tool is named.

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