Mailercloud

Duplicate Campaign

duplicate_campaign

Copy a campaign into a new draft, choosing which parts to keep (content, subject, sender, recipients, send settings, A/B setup; all kept by default). Lists, segments, tags or senders that were deleted since are skipped and reported. The copy is only a draft: nothing is scheduled or sent. Needs campaign_id; name defaults to Mailercloud's suggestion. For an A/B campaign ab_mode is whole (both variants, the default) or winner (only the winning variant, once one is decided). Set dry_run: true to see what would be copied and what can't be, without creating anything.

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

Input Schema

Name	Required	Description
`name`	No	Name for the copy, up to 150 characters (default: the name Mailercloud suggests, like Copy (1) - original name)
`ab_mode`	No	For an A/B campaign: whole (copy both variants; the default) or winner (copy only the winning variant; needs a decided winner)
`dry_run`	No	Show what the copy would carry and what can no longer be used, without creating anything
`campaign_id`	Yes	ID of the campaign to copy (regular or A/B, sent or not)
`keep_sender`	No	Keep the sender and reply-to (default true)
`keep_content`	No	Keep the email design and content (default true)
`keep_subject`	No	Keep the subject and preview text (default true)
`keep_ab_setup`	No	For an A/B campaign: keep the test setup (default true)
`keep_recipients`	No	Keep the lists, segments, tags and exclusions (default true)
`keep_send_settings`	No	Keep the send settings such as tracking and schedule options (default true)

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 4, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the annotations it discloses the key behavioral traits: only a draft is produced, nothing is scheduled or sent, references deleted since (lists, segments, tags, senders) are silently skipped but reported, and dry_run previews without side effects. It also states that all parts are kept by default, which is the non-obvious default an agent must know.

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 core action and organized logically (what it does, edge cases, draft-only guarantee, params, dry_run). Slightly redundant in listing content/subject/sender/recipients/send settings/A-B setup, which duplicates the keep_* parameter names verbatim.

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 10-parameter mutation tool with no output schema, the description covers purpose, defaults, failure modes for stale references, and what the response will report, so an agent has everything needed to call it correctly or choose dry_run first.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3; the description goes modestly beyond it by stating the all-kept-by-default policy as a group, the campaign_id requirement, the name default, and the precondition that winner mode needs a decided winner. Much of the keep_* enumeration restates parameter names the schema already documents.

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?

"Copy a campaign into a new draft, choosing which parts to keep" gives a specific verb (copy), resource (campaign), and result state (draft), with the keep/discard granularity stated up front. An agent can distinguish it from create_campaign, clone_template, or update_campaign 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 Guidelines4/5

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

It clearly frames when to use it (preview with dry_run, winner-only copy for decided A/B tests) and when the result is safe (draft only, nothing scheduled or sent). It never names a sibling alternative such as create_campaign or clone_template, so routing between similar tools is left to inference.

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

All Mailercloud 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?