Skip to main content
Glama

Write the campaign emails

argorant_set_campaign_emails
Destructive

Replace a campaign's sequence of emails, the first email and its follow-ups, each with optional A/B versions. Use it to write or change the emails; for follow-ups that start on a reply keyword use argorant_set_campaign_subsequences, and to read the current emails use argorant_get_campaign. Saving replaces every email and every version, so always send the whole sequence. Write the final text. Never leave placeholders such as [link], [Name], , {link}, TBD or XX; ask the user for a missing link or detail, or leave it out. The answer's warnings list anything that would still go out exactly as written, and its summary says the same in one sentence. Fix each warning with another call, because a launch is held while one remains. A running campaign refuses text with warnings unless allow_placeholders=true, which is only for text the user clearly wants sent as written. A contact with no value for a variable waits at that email instead of getting a blank, unless the variable has a fallback. Follow-ups go in the same thread by default, with Re: before the subject. 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>",
      "emails": "<emails>"
    },
    "name": "argorant_set_campaign_emails"
  }
}

Input Schema

NameRequiredDescriptionDefault
emailsYesThe whole sequence in order, first email first, up to 8, as [{subject?, body, delay_days?, same_thread?, variants?}]. The first email needs a subject; each later one is a follow-up sent delay_days after the one before. Contact variables are {{first_name}}, {{last_name}}, {{company}}, {{company_normalized}} (the short name people say, best in the body) and {{title}}; a fallback goes after a | sign, such as {{company_normalized|your team}}. Sender variables {{sender_first_name}}, {{sender_last_name}}, {{sender_full_name}}, {{sender_title}}, {{sender_company}}, {{sender_email}} and {{signature}} come from the sending mailbox; a mailbox without a display name holds the contact unless the variable has a fallback such as {{sender_first_name|Sam}}. The campaign's own {{custom_...}} variables, written in lowercase as defined with argorant_set_campaign_personalization, give each contact their personal line. Single braces such as {Hi|Hello} are spintax, one picked at random per email. variants holds up to 9 other versions of an email for an A/B test, each with a body and an optional subject and label; each contact gets one version, picked at random with equal odds, and argorant_campaign_analytics shows the results per version. Set a mailbox's display name with argorant_update_inbox.
campaign_idYesThe campaign's id, from argorant_list_campaigns.
allow_placeholdersNotrue only when the user clearly wants text such as [link] or TBD sent exactly as written. Off by default.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only flag destructive=true; the description adds loads of behavior the agent could not infer: a save wipes every email and version, warnings block a launch until fixed, a running campaign rejects warned text unless allow_placeholders=true, and contacts missing a variable wait rather than get a blank. This is rich context beyond the annotations.

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 alternatives, then the placeholder rules. It is dense but each clause carries operational weight. Minor redundancy: 'the answer's warnings list anything... and its summary says the same in one sentence' is slightly repetitive against the output schema.

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 write tool with an output schema, the description covers the destructive scope, the warning/fix loop, the placeholder policy, and variable fallback behavior. Nothing an agent needs to invoke it correctly is missing.

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 further, explaining variables and fallback syntax, single-brace spintax, and that allow_placeholders is only for text the user clearly wants sent literally. Useful added meaning, though much of it duplicates the already-detailed schema text.

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 a specific verb and resource -- 'Replace a campaign's sequence of emails, the first email and its follow-ups, each with optional A/B versions' -- and then explicitly distinguishes this from argorant_set_campaign_subsequences and argorant_get_campaign. An agent knows exactly what this does and what it isn't.

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?

Names the two relevant alternatives and the condition that routes to each: subsequences for reply-keyword follow-ups, get_campaign to read. It also specifies that saving replaces everything, so the whole sequence must be sent. Both when-to-use and when-not are covered.

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.