Skip to main content
Glama

Sparetext

Change a campaign

update_campaign
Destructive

Change a draft, or a paused campaign's words: any field; rows to add (up to 5,000 a call; reset starts the list again); finish_list once every row is in (duplicates merge, opted-out and other countries' numbers are left out, recent people go first); remove to take people out by tier or number. New words need a new test.

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": {
      "id": "<id>"
    },
    "name": "update_campaign"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesThe campaign's id (cmp_…)
askNoThe question people last seen over 5 years ago get first; only a YES gets them the text. On by default.
fromNoWho the texts are from, said first, e.g. XYZ Events
langNoThe text's language code (en, es, fr…): replies are read in it
nameNoIts name, for the user only
rowsNoPeople to add to a draft's list
simsNoThe SIMs it sends from, as get_campaign lists them
textNoThe text. Blanks: {{first_name}}, {{name}}, {{event}}, {{year}}, with a fallback like {{first_name|there}}. How to stop is added to each person's first text.
hoursNoSending hours in the recipients' own time; 09:00 to 20:00 every day unless changed, and always kept inside a texted country's own rule
resetNoWith rows: drop the list so far and start again
limitsNoOptional: a slower pace per SIM, in SMS parts. It can't go faster.
removeNoTake people who weren't texted yet out of the list
mid_lineNoOptional line for people last seen 2 to 5 years ago, e.g. You came to {{event}} in {{year}}.
start_atNoOptional: not before this (within 60 days)
finish_byNoOptional: when it should be done; the plan says if it fits
finish_listNoFinish the list once every row is in
other_countriesNoAlso text the list's numbers from other countries (left out by default)

Output Schema

NameRequiredDescriptionDefault
urlYes
addedNo
invalidNo
campaignYes
examplesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / hours / description
      Previous value: -"Sending hours in the recipients' own time; 09:00 to 20:00 every day unless changed"New value: +"Sending hours in the recipients' own time; 09:00 to 20:00 every day unless changed, and always kept inside a texted country's own rule"
  2. Added

TDQS

A4.4/5.0
Behavior4/5

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

Beyond the destructiveHint/readOnlyHint annotations, it discloses non-obvious behavior: 5,000-row cap per call, reset restarting the list, duplicate merging, opted-out and foreign numbers being dropped, recent people being ordered first, and remove by tier or number. It could be stronger on what happens to existing rows when not reset, but the key side effects are surfaced.

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?

It front-loads the scope constraint, which is the most decision-relevant fact, and wastes no words. The semicolon-chain sentence is dense and telegraphed, though, making it slightly harder to parse than a structured list of the same facts.

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 an output schema present, 100% schema coverage, and full annotation coverage, the description only needs to carry the operational and state rules — which it does, covering edit preconditions, list-building semantics, removal, and the retest requirement. Nothing an agent needs to invoke it correctly is missing.

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 already 100%, so 3 is the floor, and the description adds real meaning for rows (cap, reset, dedupe, ordering), finish_list, and remove (tiers vs phones). Most other parameters (ask, hours, limits, mid_line, start_at) are left to the schema, so it does not fully capitalize on the header's potential.

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?

It names a specific verb ('Change') and resource ('a draft, or a paused campaign's words') and states a scope constraint — only drafts and paused campaigns can be modified — that no sibling tool shares. That lets an agent distinguish it from create_campaign and request_campaign_launch without opening a 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?

The first clause establishes the precondition (draft or paused campaign) and 'New words need a new test' gives a concrete follow-up workflow. It stops short of naming alternatives such as pause_campaign or send_campaign_test explicitly, so the routing guidance is implied rather than 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.

Resources