Skip to main content
Glama

Add leads to campaign

add_leads_to_campaign

Move leads this account owns into a campaign this account owns, by explicit id. Updates membership only: this call sends nothing. But leads moved into an ACTIVE campaign with drip on or Auto Outreach running are texted or emailed on that campaign's next run, with no new review or approval (opt-outs, suppression, quiet hours and caps still apply); do that only when the operator wants those people contacted. Opted-out and suppressed leads are REJECTED with per-lead skip reasons even when listed explicitly; leads already in the target are deduplicated; the response includes the campaign's final lead count read back from the database. To pick the audience by filter instead of by id, use select_and_attach_leads (same attach semantics, driven by search_leads filters). If the target campaign was already reviewed, its earlier approval is stale (the launch step recounts recipients and refuses a token approved for a smaller audience), so a fresh review_campaign_readiness is required before launching.

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

Input Schema

NameRequiredDescriptionDefault
lead_idsYesLead ids to move (from find_lead, list_leads or search_leads).
campaign_idYesThe destination campaign.
idempotency_keyNoOptional but recommended. Retrying the same key returns the same result instead of re-running the move; reusing it with different arguments is rejected as idempotency_conflict.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / idempotency_key
      Added value: +{
      +  "description": "Optional but recommended. Retrying the same key returns the same result instead of re-running the move; reusing it with different arguments is rejected as idempotency_conflict.",
      +  "maxLength": 200,
      +  "type": "string"
      +}
    • changedInput schema / properties / lead_ids / description
      Previous value: -"Lead ids to move (from find_lead or list_leads)."New value: +"Lead ids to move (from find_lead, list_leads or search_leads)."
  2. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only say non-read-only, non-destructive, non-idempotent. The description adds what the annotations cannot: this call sends nothing itself, but moving leads into an ACTIVE campaign with drip or Auto Outreach causes messaging on the next run with no fresh approval; opt-outs and suppressions are rejected per-lead; duplicates are deduplicated; and a prior campaign approval becomes stale. That is exactly the consequential side effect an agent needs before invoking.

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-loads the core action and scope in the first sentence, then layers effect, rejection behavior, and the alternative in a sensible order. It is dense and long-ish, and the final stale-approval sentence is a heavy aside, but every sentence carries operational information.

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?

No output schema exists, yet the description still covers the return value ('the campaign's final lead count read back from the database'), per-lead skip reasons, and the downstream review_campaign_readiness prerequisite. For a non-idempotent mutation tool with real messaging side effects, this covers what an agent needs.

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 still adds meaning beyond the schema by stressing 'by explicit id' (contrasted with filter-based selection) and by describing per-lead rejection and dedup outcomes for the lead_ids list, which the schema's one-line item description does not.

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?

Opens with a specific verb and resource — 'Move leads this account owns into a campaign ... by explicit id' — and immediately draws the boundary against the filter-driven sibling select_and_attach_leads. An agent can distinguish it from attach_leads_to_campaign and select_and_attach_leads without opening any schema.

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?

Explicitly names the alternative ('use select_and_attach_leads ... driven by search_leads filters') and states the condition that selects it. It also gives a real when-to-use guard: do this 'only when the operator wants those people contacted,' plus the pre-launch review condition. Nothing 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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources