Skip to main content
Glama

Add leads to a campaign

argorant_add_campaign_leads
Destructive

This spends credits. Add people to a campaign from a saved list (list_id), from people of a search (record_ids), from another campaign of the workspace (lead_ids with from_campaign_id) or from rows the user gives you. Use it to fill a campaign before a launch; to take people out use argorant_remove_campaign_leads, and to move them between campaigns use argorant_move_campaign_leads. Each new person from Argorant costs 1 credit, like a reveal. People already unlocked, people already in the campaign and the user's own rows are free, and argorant_account shows the credits left. Tell the user the cost and ask the user before adding, every time. Call it first without grades. When the people include addresses that are not plainly valid, the answer is needs_choice, with counts, a question and a plain explanation of catch-all, unknown and risky, and nothing is added yet. Put that question to the user in its own words, recommend valid only, then call again with grades=["valid"] or ["valid", "catch_all"]. Invalid addresses are never added, the same person joins once, and addresses still being checked join later if they match the choice. If credits run out, the first people are added and the rest are reported. More than 2,000 people, or a slow add, runs in the background with a job_id; follow it with argorant_add_campaign_leads_status about every 30 seconds. Calling again with the same list and choice returns the same job, so nobody is added or charged twice. "Add the rest" means the rest of the search into the SAME list (argorant_create_list with its list_id), then this again with that list_id. The answer's summary says where every person went; tell the user in its words. Nothing is sent until the campaign is launched. 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_add_campaign_leads"
  }
}

Input Schema

NameRequiredDescriptionDefault
rowsNoThe user's own people, as [{email, first_name?, last_name?, company?, title?}], up to 5,000. A row whose address Argorant knows gets its empty name, title and company filled in (filled_from_argorant). Free.
gradesNoWhat the user chose after needs_choice, ["valid"] (recommended) or ["valid", "catch_all"]. It is saved for the campaign. Leave it out on the first call. Unknown and risky addresses cannot be sent to yet.
list_idNoA saved list, from argorant_create_list or argorant_list_lists. Adding it again later adds only the people not in the campaign yet.
lead_idsNoPeople already in another campaign (ids from argorant_list_campaign_leads); needs from_campaign_id.
record_idsNoPeople of a search: the same ids argorant_create_list takes. 1 credit per new person, like a list.
campaign_idYesThe campaign's id, from argorant_list_campaigns.
restore_removedNoBring back people of this add who were taken out of the campaign earlier and never emailed. When it is left out, rows, record_ids and lead_ids bring them back and a saved list does not.
from_campaign_idNoThe campaign the lead_ids are in. Same workspace only.
include_catch_allNoOlder form of grades=["valid", "catch_all"]; prefer grades.
keep_given_addressNotrue adds the addresses exactly as given. By default a better address of a person can take the place of the one in the campaign (counted in swapped) and a second address of the same person is left out (alternate_skipped); tell the user both.
exclude_private_emailsNotrue leaves out free mail and home internet addresses, counted in skipped_private_email. Only when the user asks for business emails only.

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 already mark this as destructive, non-read-only, and open-world, and the description adds substantial context beyond them: 1 credit per new person, which people are free, deduplication, invalid addresses never being added, partial adds when credits run out, background jobs over 2,000 people, and idempotent retries. It is consistent with the annotations rather than contradicting them.

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 credit-spend warning, then routes to siblings and explains the choice and background workflow in a logical order. The density is justified for an 11-parameter destructive tool, but it is long and has a few repetitive user-instruction passages that keep it from a perfect score.

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 an output schema, 11 parameters, and complex credit, verification, and background-job behavior, the description covers what an agent needs: cost consent, source selection, needs_choice handling, idempotency, and launch timing. Nothing material 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 description coverage is 100% and already documents each parameter in depth, so baseline credit is warranted. The description adds integration-level meaning by explaining source combinations such as lead_ids with from_campaign_id, the first call without grades, the needs_choice re-call, and idempotency when using the same list and choice, though most per-parameter syntax remains in the schema.

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, then enumerates the four source types: saved list, search records, another campaign, and user rows. It explicitly names the remove and move siblings it is not, so an agent can distinguish it without opening another 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?

States when to use it (fill a campaign before launch), when to use alternatives (argorant_remove_campaign_leads and argorant_move_campaign_leads), and mandates telling the user the cost and asking before every add. It also prescribes the first-call/no-grades flow, the needs_choice follow-up, and background polling with argorant_add_campaign_leads_status.

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.