Ballast - Cold Email

Update campaign

update_campaign

Destructive

Rename a campaign or change its schedule, mailboxes and options.

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

Name	Required	Description
`id`	Yes
`days`	No	Bitmask, bit 0 = Monday ... bit 6 = Sunday
`name`	No
`endOn`	No	Optional last sending day (YYYY-MM-DD, in timezoneFallback). After it nothing goes out and the campaign pauses. Null = no end
`startOn`	No	Optional first sending day (YYYY-MM-DD, in timezoneFallback). Null = start when launched
`dailyCap`	No	First emails a day for the campaign; null = only mailbox limits
`dayHours`	No	Hours for some weekdays instead of windowStart/windowEnd: {"4": [540, 780]} sends 9:00 to 13:00 on Fridays. Keys are day bits (0 = Monday). Null = the same window every day
`hourlyCap`	No	Campaign emails (every step) in any 60 minutes; null = no hourly cap
`skipDates`	No	Days off (holidays, breaks): YYYY-MM-DD, in each lead's own time zone. Nothing goes out on them, follow-ups wait. Past days are dropped on save
`skipRisky`	No	Leave out risky and catch-all leads: skipped when added and before their first email
`weeklyCap`	No	Campaign emails (every step) per week, Monday to Sunday in timezoneFallback; null = no weekly cap
`windowEnd`	No
`autoWinner`	No	Pick the winner automatically: once an hour while the campaign runs, a step's variant is turned off when it and the leading variant have 100+ emails each, the leader has 5+ replies and it's 95% likely the leader gets more replies. Variants a person turns back on stay on
`mailboxIds`	No	Replaces the campaign's mailboxes
`trackOpens`	No
`espMatching`	No
`sameVariant`	No	Same variant in every step: a lead who got variant B in step 1 gets B in later steps too, when that step has a B turned on, so variants compare whole sequences. Off: each step picks its own variant
`stopOnReply`	No
`trackClicks`	No
`windowStart`	No	Minutes after midnight
`stopForCompany`	No	When a lead replies, stop the sequence for everyone at the same company domain (free-mail domains excluded)
`bounceThreshold`	No	Pause at this bounce rate (%); null = workspace default
`noReplyAfterDays`	No	Days after the last email before a lead who didn't reply moves to the follow-on campaign
`timezoneFallback`	No	IANA timezone for leads without one
`noReplyCampaignId`	No	No-reply follow-on: leads who finish this sequence without a reply move into this campaign (draft, running or paused) noReplyAfterDays after their last email. Applies to leads finishing from now on. Null = they stop here

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 5, 2026

addedInput schema / properties / autoWinner

Added value: +{
+  "description": "Pick the winner automatically: once an hour while the campaign runs, a step's variant is turned off when it and the leading variant have 100+ emails each, the leader has 5+ replies and it's 95% likely the leader gets more replies. Variants a person turns back on stay on",
+  "type": "boolean"
+}

Changed1 schema field changedNov 2, 2026

addedInput schema / properties / sameVariant

Added value: +{
+  "description": "Same variant in every step: a lead who got variant B in step 1 gets B in later steps too, when that step has a B turned on, so variants compare whole sequences. Off: each step picks its own variant",
+  "type": "boolean"
+}

Changed4 schema fields changedOct 24, 2026

addedInput schema / properties / dayHours

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": {
+        "items": false,
+        "maxItems": 2,
+        "minItems": 2,
+        "prefixItems": [
+          {
+            "maximum": 1440,
+            "minimum": 0,
+            "type": "integer"
+          },
+          {
+            "maximum": 1440,
+            "minimum": 0,
+            "type": "integer"
+          }
+        ],
+        "type": "array"
+      },
+      "propertyNames": {
+        "enum": [
+          "0",
+          "1",
+          "2",
+          "3",
+          "4",
+          "5",
+          "6"
+        ],
+        "type": "string"
+      },
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "Hours for some weekdays instead of windowStart/windowEnd: {\"4\": [540, 780]} sends 9:00 to 13:00 on Fridays. Keys are day bits (0 = Monday). Null = the same window every day"
+}

addedInput schema / properties / hourlyCap

Added value: +{
+  "anyOf": [
+    {
+      "maximum": 100000,
+      "minimum": 1,
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "Campaign emails (every step) in any 60 minutes; null = no hourly cap"
+}

addedInput schema / properties / skipDates

Added value: +{
+  "description": "Days off (holidays, breaks): YYYY-MM-DD, in each lead's own time zone. Nothing goes out on them, follow-ups wait. Past days are dropped on save",
+  "items": {
+    "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
+    "type": "string"
+  },
+  "maxItems": 366,
+  "type": "array"
+}

addedInput schema / properties / weeklyCap

Added value: +{
+  "anyOf": [
+    {
+      "maximum": 1000000,
+      "minimum": 1,
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "Campaign emails (every step) per week, Monday to Sunday in timezoneFallback; null = no weekly cap"
+}

Changed2 schema fields changedOct 24, 2026

addedInput schema / properties / noReplyAfterDays

Added value: +{
+  "description": "Days after the last email before a lead who didn't reply moves to the follow-on campaign",
+  "maximum": 60,
+  "minimum": 0,
+  "type": "integer"
+}

addedInput schema / properties / noReplyCampaignId

Added value: +{
+  "description": "No-reply follow-on: leads who finish this sequence without a reply move into this campaign (draft, running or paused) noReplyAfterDays after their last email. Applies to leads finishing from now on. Null = they stop here",
+  "type": [
+    "string",
+    "null"
+  ]
+}

First observedOct 21, 2026

TDQS

B3.1/5.0

Behavior2/5

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

The annotations already declare readOnlyHint=false, destructiveHint=true, and openWorldHint=true, so the description only needs to add context beyond that. It does not explain whether omitted fields remain unchanged, whether mailboxes are replaced or appended (the schema says mailboxes are replaced), what permissions are needed, or what the destructive impact is. For a 25-parameter destructive update, this is a significant behavioral gap.

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?

The one-sentence description is efficient and front-loads the update action with the affected resource. It wastes no words, though its brevity is arguably too extreme for a destructive 25-parameter tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 25 parameters, destructive annotations, and no output schema, the description is far too sparse to guide correct invocation. It omits partial-update semantics, mailbox replacement behavior, scheduling constraints, and the consequences of changing options, all of which are material for this tool.

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 72%, so the schema documents most parameters and establishes a baseline of 3. The description groups parameters into 'schedule, mailboxes and options' but adds no meaning beyond that, and several parameters such as name, trackOpens, espMatching, stopOnReply, trackClicks, and windowEnd lack descriptions in both places.

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 gives a clear verb+resource (update/rename a campaign) and names the broad categories it can change: schedule, mailboxes, and options. It does not differentiate this tool from siblings such as create_campaign, get_campaign, launch_campaign, or pause_campaign, leaving the agent to infer the distinction from the name alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

Usage is only implied by the verb 'update'; there is no explicit statement of when to use this tool versus create_campaign, get_campaign, launch_campaign, or pause_campaign. The agent can infer that it edits an existing campaign, but no prerequisites or exclusions are provided.

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

All Ballast - Cold Email 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.

Resources

Need Help?