Argorant

Remove many people from a campaign

argorant_remove_campaign_leads

Destructive

Take many people out of a campaign at once, chosen by status, reply, bounce, address domain, tag, lead_ids, addresses, a CSV file of ids or addresses (up to 100,000) or a saved list. Use it for bulk clean ups. For one address use argorant_remove_campaign_lead, and to bring people back use argorant_restore_campaign_leads. Always call it first with preview=true and tell the user how many would be taken out and how many stay because they already got an email. People who already got an email stay unless the user clearly asks to stop them too (include_contacted=true); then the ones still waiting for a follow-up get no more emails, and replies and bounces are never touched. Nobody is deleted, and emails already sent stay in the numbers. Doing it needs confirmed=true after the user's clear yes. For many people, tag them with argorant_set_lead_custom_fields and remove by tag, or pass a file, instead of long id lists. More than 2,000 people are taken out in the background, with a job_id for argorant_add_campaign_leads_status. 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>"
    },
    "name": "argorant_remove_campaign_leads"
  }
}

Input Schema

Name	Required	Description
`tag`	No	Everyone who carries this tag (set with argorant_set_lead_custom_fields).
`file`	No	CSV text of lead ids or email addresses (a header such as id or email is optional), up to 100,000.
`emails`	No	The people's email addresses.
`status`	No	pending, queued, active, sent, replied, bounced, unsubscribed, failed or completed.
`bounced`	No	true for only the bounced addresses, false for only the others.
`domains`	No	Domains of the people's addresses.
`list_id`	No	Everyone of this saved list.
`preview`	No	Set it to true to only count, without changing anything.
`replied`	No	true for only the people who replied, false for only the ones who did not.
`lead_ids`	No	Ids from argorant_list_campaign_leads.
`confirmed`	No	true only after the user's clear yes to taking these people out
`campaign_id`	Yes	The campaign's id, from argorant_list_campaigns.
`include_contacted`	No	Also stop people who already got an email. Only when the user asks for it.

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 8, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already flag destructiveHint=true and readOnlyHint=false, and the description goes well beyond them: contacted people are preserved by default, replies and bounces are never touched, nobody is actually deleted, sent-email counts persist, and runs over 2,000 people go async with a job_id. The only shortfall is that it does not define what the preview response reports or how to poll the job beyond pointing at argorant_add_campaign_leads_status.

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?

Strongly front-loaded: scope first, safety and workflow second, operational limits last. It is long and several sentences are run-on with dashes, but almost every clause carries non-obvious information. The docs URL is a reasonable tail rather than padding.

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 13-parameter destructive bulk mutation with an output schema, this covers the decision-critical facts: selection modes, the mandatory preview gate, confirmation, the contacted-lead exception, and the async threshold. An agent could call it correctly and safely from this text alone.

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 the baseline is 3, but the description adds real semantic meaning: it explains the consequence of include_contacted=true (waiting leads stop receiving follow-ups), clarifies that preview defaults to counting, and ties confirmed=true to a user's explicit yes. The remaining selectors are covered adequately by the schema's own descriptions.

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 ("Take many people out of a campaign at once") and immediately enumerates the selectors by name (status, reply, bounce, domain, tag, lead_ids, addresses, CSV, saved list). It explicitly contrasts itself with argorant_remove_campaign_lead (single) and argorant_restore_campaign_leads (undo), so the agent can route without opening a 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?

Gives a positive use case ("bulk clean ups"), states the alternative for the single-address case, names the undo path, and prescribes the mandatory preview-then-confirm workflow. It even recommends a scaling strategy (tag via argorant_set_lead_custom_fields or pass a file instead of long id lists), which is unusually actionable.

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

All Argorant 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.