Skip to main content
Glama

Sergio by Serviche

Edit, pause or archive a campaign

edit_campaign
Idempotent

Edits a campaign as its builder does (the fields you pass change; the rest stay), or pauses (status paused, pulls back its queued sends) or archives it. Turning automatic sending off (auto_send false) is open. To start or resume one, use start_campaign (your person confirms first). Held for the owner, refused with where: starting it here, turning automatic sending on, and changing the messages, audience, caps or send window of a started campaign that sends automatically (turn auto_send off first, in the same call or before). Templates, offer and audience_filter follow the same rules as create_campaign (listed on each field). Pass the same idempotency_key when retrying.

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": {
      "campaign_id": "<campaign_id>",
      "idempotency_key": "<idempotency_key>"
    },
    "name": "edit_campaign"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameNo
colorNo
stepsNo
statusNo
auto_sendNo
daily_capNo
offer_textNooffer_text is the offer, written the way the builder writes it ("$25 off your next booking", "10% off your next booking", "a free fridge clean"); {{Offer}} sends those exact words to every recipient. A percent offer is NOT priced per person: "10% off your next booking" goes out as written, and there is no per-client dollar amount on a campaign. When your person asks for "10% of their booking as a credit", use the percent offer and tell them each client sees "10% off" rather than a dollar figure; a dollars offer is one amount for everyone. offer_expiry_days N: the offer is good for N days after each person's first message goes out; {{Offer Expiry Date}} quotes that date and every later step quotes the same one. When your person says to give clients a credit ("a $29.86 credit in their account"), that is the campaign's offer, described in the message: write the message the way they asked (for example "you have a $29.86 credit on your account, good until {{Offer Expiry Date}}"), with offer_text naming the credit and offer_expiry_days the days it lasts. Building or starting a campaign never puts money on anyone's account and nothing has to be applied first: the business honors the credit when the client books. So never tell your person to apply or add credits before sending, and never call the wording a problem.
short_codeNo
campaign_idYes
audience_modeNo
cooldown_daysNo
dismissed_tipsNo
audience_filterNoWho the campaign is for, as the builder's Audience section sets it. Use these keys only; every key given must hold.
audience_sourceNoInstead of audience_filter, follow Contacts: { kind: "list", listId } | { kind: "view", viewId } | { kind: "people", clientIds: [...] } | { kind: "filter", query } (a Contacts filter).
idempotency_keyYesYour id for this operation (8-128 of A-Z a-z 0-9 . _ : -). Reuse it on every retry of the same operation; use a new one for a new operation.
send_time_localNo
enrollment_sourceNo
offer_expiry_daysNoDays the offer stays good after each person's first message; {{Offer Expiry Date}} quotes the date.
queue_expiry_daysNo
send_window_hoursNo
contact_floor_daysNo
min_days_since_visitNo
text_by_email_subjectNoThe one email subject every text step takes when it goes by email to someone Sergio may not text. An email step keeps its own.
hold_negative_feedbackNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare non-readonly, non-destructive, idempotent, closed-world; the description adds real value on top: patch rather than replace semantics, the side effect that pausing withdraws queued sends, owner-confirmation holds, and a specific retry contract (reuse idempotency_key). It does not describe what a pause/archive returns or the state a campaign must be in for edits to be accepted beyond the auto_send case, so it falls 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 primary verb and its modes, then refusals, then delegation to create_campaign, then the idempotency note — a sensible order with no filler sentences. It is dense and somewhat run-on in the refusal clause, which costs a point but nothing is wasted.

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 24-parameter, nested-object mutation tool with no output schema, the description covers the highest-risk information: what changes, what is refused, why, and how to retry safely. The remaining gap is coverage of the many lesser parameters, partly mitigated by delegating field rules to create_campaign, so it is strong but not fully self-sufficient.

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 only 25% across 24 parameters, so the description carries a heavy burden. It clarifies the semantics of the three interesting ones (status paused/archived only, auto_send constrained to false, idempotency_key reuse on retry) and defers templates/offer/audience_filter to create_campaign's per-field docs, but many parameters (send_time_local, cooldown_days, queue_expiry_days, contact_floor_days, enrollment_source, short_code, dismissed_tips) get no mention at all.

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 and resource plus the three modes it covers: partial edit ("the fields you pass change; the rest stay"), pause ("pulls back its queued sends"), and archive. It explicitly names the sibling it is not (start_campaign) and the creation tool whose field rules it inherits, so an agent can distinguish it 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?

Gives explicit routing: use start_campaign to start or resume, and note that the person confirms first. It also enumerates the operations refused here (starting, enabling auto_send, editing messages/audience/caps/send window of an auto-sending started campaign) along with the workaround (turn auto_send off first, same call or before), which is exactly the when-not guidance the dimension asks for.

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