Argorant

Change campaign settings

argorant_update_campaign

Destructive

Change one campaign's settings; only the settings you pass change. Use it for sending limits, days, hours, time zone, gaps, bounce protection, reply handling, the unsubscribe line, the planned start or tags. For the emails use argorant_set_campaign_emails, for mailboxes argorant_set_campaign_senders, and to start, pause or stop use argorant_launch_campaign. stop_on_reply is true by default, so a reply ends that person's emails. Bounce protection (auto_pause) pauses the campaign by itself when too many emails bounce or its mailboxes go offline, and only a person can start it again. Never turn include_unsubscribe on unless the user asks. Campaigns always send plain text. More in the docs at https://docs.argorant.com/docs/agents/tools#campaigns

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>",
      "settings": "<settings>"
    },
    "name": "argorant_update_campaign"
  }
}

Input Schema

Name	Required	Description	Default
`settings`	Yes	Only the settings to change, for example {"daily_limit": 40, "window_start": "09:00"}. The keys are name, daily_limit (whole campaign per day), per_mailbox_daily_limit, max_active_mailboxes, timezone (such as America/New_York), timezone_mode (fixed, or lead for each person's local time), window_start and window_end (such as 08:00 and 17:00), skip_weekends, gap_minutes_min, gap_minutes_max, include_unsubscribe (an unsubscribe link at the end of each email, off by default and only where the campaign has an unsubscribe page), skip_shared_bounces (true by default; also leaves out addresses that bounced for other Argorant users, while a reply or unsubscribe stops a person in this workspace only), stop_on_reply (true by default; with false the emails keep going unless the reply starts a subsequence or asks to stop), planned_start_date (YYYY-MM-DD), tags, auto_pause, auto_pause_bounce_rate_pct (1 to 50, default 10), auto_pause_min_sent (people contacted before the bounce rule applies, default 100), auto_pause_when_offline (true by default) and auto_pause_offline_share_pct (share of mailboxes offline that pauses it, default 100, which means all of them).
`campaign_id`	Yes	The campaign's id, from argorant_list_campaigns.

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 8, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the annotations (readOnlyHint=false, destructiveHint=true), it discloses consequential defaults: stop_on_reply true ends a person's emails on reply, auto_pause halts the campaign on bounces or offline mailboxes and only a human can restart it, and campaigns always send plain text. Those are behavior-level facts an agent cannot infer from the flag set and are exactly what an agent needs before mutating a live campaign.

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 is front-loaded with the core contract in the first clause, then routing, then behavioral caveats — a sensible order. The middle enumeration of setting families partly duplicates the schema and could be trimmed, but no sentence is filler and the docs link is placed last where it belongs.

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?

For a destructive, nested-object partial-update tool the description covers the update semantics, sibling routing, defaults and side effects, and a safety constraint; return values are covered by the existing output schema. Nothing an agent needs in order to call this safely is missing.

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 100% and the nested settings object already documents every key, including defaults and value examples. The description mostly re-lists those same categories (limits, days, hours, time zone, gaps, bounce protection) without adding syntax, ranges, or format information that the schema lacks, so the baseline of 3 applies.

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?

"Change one campaign's settings; only the settings you pass change" states a specific verb (change/partial update), a specific resource (one campaign), and the key semantic that unspecified settings are untouched. It then enumerates the setting families it covers, so an agent knows exactly the surface of this tool 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 Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It routes the agent away explicitly: emails go to argorant_set_campaign_emails, mailboxes to argorant_set_campaign_senders, and start/pause/stop to argorant_launch_campaign — covering the three most likely misroutings. It also gives a hard usage constraint ("Never turn include_unsubscribe on unless the user asks") rather than just describing the field.

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

All Argorant tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.