Skip to main content
Glama

Start a paused campaign (two steps)

launch_campaign
Destructive

Activate a paused campaign, in two calls. Without confirm_token it only runs a preflight and changes nothing: the account's limits, the note and follow-ups, the plan's campaign limit, the activation checks, approval, whether the desktop app and a LinkedIn account are linked, and whether the campaign has anyone in it. When every check passes it returns a plain-language summary, every person waiting with the exact connection note they will get and its approval state, and a single-use confirm_token (valid 10 minutes, tied to this account, this campaign and its exact state, including each person's note). For a campaign whose notes ZenMode's AI writes with review off, it also returns unreviewed_ai_warning, a line the person must see on its own before saying yes. With that confirm_token it re-checks everything and activates the campaign. A token that is missing, expired, used, for another campaign, or from before the campaign changed is refused. Activating contacts nobody at that moment: ZenMode's engine works through the campaign's people later, inside the account's daily and weekly limits and business hours, only while the ZenMode desktop app is open. Nothing happens on LinkedIn at the moment you call this. ZenMode's campaign engine works through each campaign later, inside your daily and weekly limits, business hours and pacing.

Input Schema

NameRequiredDescriptionDefault
campaign_idYesThe campaign id, from create_campaign or list_campaigns.
confirm_tokenNoThe confirm_token from the preflight. Leave out to run the preflight.
idempotency_keyNoOptional. A unique string you make up for this exact change (8 to 128 letters, digits, - _ . :). If the call is repeated with the same key and the same arguments within 24 hours, nothing happens twice and the first result is returned again. Use a fresh key for every new change.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior5/5

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

Beyond the annotations, the description discloses substantial behavior: preflight changes nothing, activation re-checks all conditions, confirm_token is single-use and state-bound, and no LinkedIn contact happens at call time but later through the campaign engine within limits and business hours. It also explains the special unreviewed_ai_warning case. The annotations mark this as destructive and not idempotent, and the description is consistent with that.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The opening is front-loaded and clear, but the description is long and contains noticeable redundancy. The final sentence about the campaign engine working later inside limits, business hours, and pacing largely repeats an earlier sentence about the same behavior.

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?

Given the lack of an output schema and the complexity of a two-step destructive activation, the description is complete enough for correct invocation. It explains preflight checks, returned summary content, token semantics, invalid-token handling, delayed activation behavior, and the unreviewed AI warning case.

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 already 100%, so the baseline is 3. The description still adds meaningful semantics for confirm_token, including its single-use nature, 10-minute validity, account/campaign/state binding, and rejection conditions. It adds little about idempotency_key beyond the schema, but the token explanation is valuable.

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 states a specific verb and resource: 'Activate a paused campaign, in two calls.' It clearly explains the preflight/activation split. However, it does not explicitly distinguish this tool from the sibling resume_campaign, so an agent must infer that difference from naming alone.

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?

The description gives clear operational guidance: omit confirm_token for preflight, include it to activate, and expect refusal for missing, expired, used, mismatched, or stale tokens. It does not name alternatives such as resume_campaign, so it falls short of explicit when-to-use-this-vs-another guidance.

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.