Skip to main content
Glama

Update campaign

update_campaign
DestructiveIdempotent

Edit a campaign. Partial: only the sent fields change. flows / pixels / postbacks, when sent, REPLACE the stored lists entirely (rows match by id, omitted rows are deleted) — fetch the current tree with get_campaign include=flows first and send it back whole with your changes. Status is changed via set_campaign_status.

Input Schema

NameRequiredDescriptionDefault
idYesCampaign id
nameNo
tagsNoTag ids (see list_tags)
aliasNoShort code used in the click URL /c/{alias}; generated when omitted. Globally unique.
flowsNoRouting tree, evaluated in order. Exactly one flow should be is_default (catch-all, no rules). On update the list is complete: rows match by id, omitted rows are deleted.
notesNo
pixelsNoAttached conversion pixels (complete list on update)
group_idNo
owner_idNoHand the campaign to another workspace member (user id from list_workspace_members). Needs edit rights on the campaign; a non-admin may only pick members of their own team. Click history keeps the owner at click time unless rewrite_history is true.
cost_typeNoHow click cost is booked (auto = from the {cost} macro)
domain_idNoTracking domain (see list_domains; defaults to the workspace default on create)
postbacksNoCampaign-level outgoing postbacks (complete list on update)
cost_valueNoCost per click / per 1000 (cpc / cpm) or per conversion (cpa); % for revshare
auto_metricNo
sticky_flowNoCookie-pin a returning visitor to the flow and destination they got first (priority flows still win)
site_list_idNoSite list attached to the campaign
traffic_lossNo0–100 % traffic-loss compensation; null = inherit the traffic source
cost_currencyNoDefault USD
flow_rotationNoauto = EPC/CR bandit split of each flow's destinations
network_linksNoIds of campaigns already running on the campaign's API traffic source, exactly as the network shows them — network actions (start/stop, stats, bids, lists) then act on them. Complete list: replaces the manual links, [] clears them, omit to leave them as they are. A link turns a manual campaign into an api one; removing the last turns it back. Ignored for sources without an API connection.
remember_offerNoKeep a returning visitor on the offer they first got
auto_min_clicksNoauto rotation: clicks before exploiting (default 100)
back_button_urlNoBack button target http(s) URL, macros allowed (target = url)
rewrite_historyNoWith owner_id: also re-stamp the clicks and conversions already booked onto the new owner (asynchronous; lands within minutes). Default false.
uniqueness_modeNo
uniqueness_scopeNo
backup_domain_idsNoOrdered failover pool for automatic domain switching (max 20)
traffic_source_idNo
uniqueness_periodNoHours (1–8760, default 24)
back_button_targetNoBack button: where a visitor pressing Back on a served landing / PWA install page is sent; null = off
auto_explore_percentNoauto rotation: exploration share 0–50 (default 10)
back_button_offer_idNoBack button target offer (target = offer)
back_button_campaign_idNoBack button target campaign (target = campaign; not the campaign itself)
sticky_flow_keep_click_idNoSticky flow: a return visit resumes the original click id instead of minting a new click
sticky_flow_skip_inactiveNoSticky flow: route afresh when the sticky flow is paused (default true); false keeps serving it

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A3.8/5.0
Behavior3/5

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

The annotations already declare destructiveHint=true, idempotentHint=true, readOnlyHint=false and openWorldHint=true, so the risk profile is known from structured data. The description adds the crucial mechanism behind the destructive hint: flows/pixels/postbacks are whole-list replacements where omitted rows are deleted, which tells the agent exactly what gets destroyed. It does not cover permissions, error behaviour, or whether partial nested-row updates are allowed within a replaced list, so it adds real but bounded context.

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, front-loaded: purpose, partial-update rule, the destructive exception, then the alternative tool. Every clause carries decision-relevant information — the replacement rule and the fetch-first instruction are precisely what a 35-parameter mutation tool needs stated up front.

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 35-parameter mutation tool with no output schema, the description covers the highest-risk behaviour (destructive list replacement) and the correct preparation workflow, which is the main thing the schema cannot express. Gaps remain around permission requirements for ownership transfer and concurrency, though owner_id's schema text partially compensates. Adequate but not exhaustive.

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 80% across 35 parameters, so most field meaning is already in the schema (including per-list "complete list on update" notes). The description's added value is the cross-field rule that three array parameters are replace-not-merge, which the schema only states per-field and scattered. It doesn't clarify anything about owner_id/rewrite_history or the many back-button and rotation fields.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb+resource ("Edit a campaign") and immediately narrows the semantics to a partial update. It explicitly carves status changes out to the sibling set_campaign_status, so the agent can route between the two without opening either schema. It does not distinguish itself from create_campaign or clone_campaign explicitly, but the "edit"/"partial" framing makes the intent 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 names an alternative tool (set_campaign_status) and the condition selecting it, and prescribes a preparatory step (fetch via get_campaign include=flows before calling). What's missing is guidance on when a full replacement is appropriate versus using narrower siblings, or any exclusion around concurrent edits.

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