Skip to main content
Glama

Add campaign step

add_campaign_step

Add an email to a campaign at a chosen point. delay_days is the wait after the email before it (or after the contact enters, for the first). On a live campaign the step applies at once to people who have not reached that point.

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>",
      "insert_after": "<insert_after>",
      "delay_days": "<delay_days>",
      "subject": "<subject>",
      "preview_text": "<preview_text>",
      "html": "<html>",
      "markdown": "<markdown>",
      "template_id": "<template_id>"
    },
    "name": "add_campaign_step"
  }
}

Input Schema

NameRequiredDescriptionDefault
htmlYesThe body as HTML. Null when you send markdown or a template_id.
subjectYes
markdownYesThe body as markdown. Null when you send html or a template_id.
delay_daysYes
campaign_idYes
template_idYesCopy a template's subject, preview text and body; then subject, preview_text, html and markdown are null.
insert_afterYesWhere the step goes: at the start, after a step, or first on a branch's true or false path. What followed that point now follows this step.
preview_textYesThe line inbox previews show after the subject.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Annotations cover the safety profile (write, non-idempotent, non-destructive), and the description adds genuinely new behavior: on a live campaign the step applies immediately to contacts who have not yet reached that point, which is a real side effect an agent must know before mutating a running campaign. It stops short of saying what is returned or that repeated calls create duplicate steps, which is notable given idempotentHint=false.

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?

Two tight sentences with the core action first and the subtle timing semantics second. Nothing is redundant, and the highest-risk information (immediate application to a live campaign) is not buried.

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 an eight-required-parameter mutation tool with no output schema, the description supplies the two pieces of semantics the schema cannot: what delay_days measures and the live-campaign propagation rule. The main residual gap is the absence of an explicit statement about return value or duplicate-step risk, but the parameter guidance is otherwise adequate.

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 only 63%, but the description compensates on the riskiest parameter: delay_days is not just a number but the wait after the preceding email, or after entry for the first step. It also reinforces insert_after's re-linking behavior. campaign_id and the content fields are left to the schema, which already documents the html/markdown/template_id exclusivity well.

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?

States a specific verb and resource: adding an email step to a campaign at a chosen position. That distinguishes it from update_campaign_step, move_campaign_step and delete_campaign_step without naming them, though the siblings' names already make the boundary obvious. It is clear but does no explicit sibling differentiation.

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: you use it to insert a new step, and 'at a chosen point' hints that insert_after controls placement. There is no explicit statement of when to prefer this over update_campaign_step or move_campaign_step, and no prerequisites (e.g. campaign must be a draft or live) are called out beyond the live-campaign sentence.

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