Skip to main content
Glama

update_campaign

DestructiveIdempotent

Update a draft campaign. Only the fields you pass are changed. list_ids REPLACES the full current list set (and replaces a segment target): to add or remove a list, prefer add_lists_to_campaign / remove_lists_from_campaign. segment_id sends to one segment instead of lists. Exclusions (excluded lists, segments, tags) and frequency cap cannot be changed here: they can only be set at creation (create_campaign) or in the panel. Setting scheduled_at publishes the campaign for sending, so it takes two steps: call first without confirm to get a preview (nothing is changed), get an explicit yes from the user, then call again with confirm: true. Set dry_run: true to see the exact fields that would be sent without changing anything.

Input Schema

NameRequiredDescriptionDefault
htmlNoHTML email content
nameNoCampaign name
rulesNoSend rules object: limit (number of contacts), contacts_order (first or last)
tag_idNoCampaign tag ID
confirmNoMust be true when scheduled_at is set, because that schedules the campaign to send. Leave false first to get a preview; nothing is changed
dry_runNoValidate inputs and show what would be sent without changing anything, even when confirm is true
subjectNoEmail subject line
list_idsNoList IDs to send to (max 150). REPLACES the campaign's full recipient list set, and replaces a segment if the campaign sends to one: to add a list, include the current lists as well (or use add_lists_to_campaign)
reply_idNoPre-configured reply email ID
plain_textNoPlain text content
segment_idNoOne segment ID to send to. Replaces the campaign's lists. Give list_ids or segment_id, not both
campaign_idYesCampaign ID
pause_rulesNopause rules object as in the panel: pause_target, pause_limit, pause_criteria, pause_condition
reply_emailNoReply-to email address
report_spamNoAdd a report-abuse link
sender_nameNoSender display name (give together with sender_email)
scheduled_atNoSchedule datetime (YYYY-MM-DD HH:MM:SS, account timezone). Setting it PUBLISHES the campaign for sending at that time, so it requires confirm: true
sender_emailNoSender email address (give together with sender_name)
viewin_browserNoAdd a view-in-browser link
email_preheaderNoEmail preheader text (max 150 chars)
mailing_preferenceNoAdd a mailing-preference link
permission_reminderNoPermission reminder text (3-150 chars)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior3/5

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

Annotations already declare destructiveHint=true, idempotentHint=true, readOnlyHint=false and openWorldHint=true, so the bar is lower. The description does add real value beyond that: partial-update semantics, the publishing side effect of scheduled_at, the confirm gate, and the fact that a preview changes nothing. It still omits auth/permission expectations and rollback behavior for a destructive 22-parameter write.

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 purpose and the partial-update rule, then the highest-risk behavior (list_ids replacement, scheduled_at publishing, confirm, dry_run). It is a single dense paragraph that largely restates schema descriptions for list_ids, segment_id, scheduled_at, confirm and dry_run, so a small amount of redundancy remains.

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 22-parameter, nested-object, destructive mutation with no output schema, the description covers the dangerous and ambiguous parts thoroughly. The remaining gap is what the tool returns on success versus the preview, and any permission preconditions, neither of which is stated.

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 100%, so the baseline is 3 and each parameter is already documented. The description goes beyond the schema on the cross-field interactions: list_ids replaces the whole recipient set and supersedes segment_id, and confirm is only mandatory when scheduled_at is set. That is genuine added meaning, but most other parameters get no description-level semantics.

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 the specific verb and resource (update a draft campaign) plus the key scoping rule that only passed fields change. It further differentiates from siblings by naming add_lists_to_campaign / remove_lists_from_campaign and create_campaign in the contexts where they are the right alternative.

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?

Explicitly routes the agent: use add_lists_to_campaign/remove_lists_from_campaign for incremental list edits, exclusion and frequency-cap fields must go to create_campaign or the panel, and scheduled_at requires a two-step preview-then-confirm flow with an explicit user yes. It also states dry_run as the safe inspection path.

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.