Skip to main content
Glama

Lead Finder: add people to a campaign (spends credits)

add_lead_finder_prospects
Destructive

SPENDS CREDITS, AND BY DEFAULT METERED EMAIL VERIFICATION. Adds people from the Lead Finder contact database to a campaign as leads, revealing their contact details, in the background. Pass refs (from Lead Finder search results; up to 1,000 different people by default) to add exactly those people, or pass filters and count (1 to 5,000 by default) to add count people matching the filters who are not in the workspace yet. A filters add always walks the matches from the top and skips anyone already a lead, free and not counted, so repeating the same add adds the NEXT count people and charges again. Never repeat an add to retry: an add that errors or times out may still have started, and adding again can add the same people twice. A filters add stops early when the audience runs out or once it has looked at five people for every one requested (at least 1,000). People already added count toward that limit even though skipping them is free, so after an add of more than about 1,000 people a small follow-up can stop with nobody added. Every person a filters add looks at, added or skipped, also uses the account's daily allowance for filters adds (25,000 people by default). Each person added costs 1 credit ($0.033 at list), reported as creditsPerProspect; the response reports estimatedCredits, the most the add can cost in credits, and the wallet must hold that much for it to start. People already in the workspace, blocklisted, without a usable address, on a personal mailbox when the campaign only takes business addresses, or marked invalid by verification are skipped and cost no credits. verifyEmails (on by default) checks every screened address with the paid email verification waterfall, including the ones it marks invalid: one or two checks per address, billed as metered usage on the next invoice (price per check: GET /email-verification/rates in the REST API), within the account's monthly verification spend limit. Catch-all and unconfirmed addresses are added and charged, and so is every address once that limit is reached; verification.limitReached and verification.unknown on the add's import record count them. Leads added to a running or paused campaign get their emails at once (a paused campaign sends them when resumed); adding to a completed campaign resumes it, so it starts sending again; in a draft campaign the emails are created at launch. At most 3 adds run at once in a workspace. A refusal names its reason, and a 429 also says when to retry (reason running_imports, daily_import_limit, daily_budget, monthly_budget or fair_use_floor). The response carries an importId, and the add's import record keeps changing until finishedAt is set.

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": {
      "campaignId": "<campaignId>"
    },
    "name": "add_lead_finder_prospects"
  }
}

Input Schema

NameRequiredDescriptionDefault
refsNoRefs of the people to add, from search_lead_finder results. Duplicates and blanks are dropped before sending; up to 1,000 different people per add by default (get_lead_finder_filters has the limit that applies). Use either refs, or filters with count
countNoHow many people not yet in the workspace to add with filters (1 to 5,000 by default; get_lead_finder_filters has the limit that applies)
filtersNoAdd people matching these filters (same shape as search_lead_finder). Needs count. The matches are walked from the top every time and people already in the workspace are skipped, so a repeat adds the next count people
campaignIdYesThe numeric campaign ID (from list_campaigns)
verifyEmailsNoCheck each address with the paid email verification waterfall before adding it (default true): one or two checks per address, billed on the next invoice, including addresses that turn out invalid. Invalid addresses are skipped and cost no credits; catch-all and unconfirmed ones are still added and charged, and so is every address once the monthly verification spend limit is reached. false skips verification

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  2. Added

TDQS

A4.6/5.0
Behavior5/5

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

Adds substantial context beyond the destructive/non-idempotent annotations: 1 credit per prospect with cost basis, wallet pre-check on estimatedCredits, metered email verification billing and its limit semantics, skip rules that cost nothing, concurrency cap of 3 adds, and resumed-sending behavior on completed campaigns. It also explains how to track progress via importId until finishedAt.

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?

Critical warning ('SPENDS CREDITS') is front-loaded and virtually every sentence carries operational weight. However, it is a single dense block with no separation between cost, eligibility, verification, and failure modes, which makes it harder to scan than it needs to be.

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 destructive, credit-spending, asynchronous operation with no output schema, the description covers cost estimation, wallet precondition, skip/charge rules, verification limits, concurrency, retry hazards, and the shape of the returned import record. Nothing an agent needs to invoke or reason about the outcome is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents every parameter including the nested filters object; the description largely restates those defaults (1,000 refs, 1 to 5,000 count, verifyEmails default true). It does add the useful implicit constraint that refs and filters+count are mutually exclusive and that duplicates/blanks are dropped, but most of the parameter knowledge lives 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?

States a specific verb and resource ('Adds people from the Lead Finder contact database to a campaign as leads, revealing their contact details, in the background') and immediately distinguishes the two operating modes (refs vs filters+count). An agent can tell this apart from search_lead_finder or add_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?

Explicit routing: pass refs from Lead Finder search results, or pass filters with count to pull not-yet-in-workspace people. It also gives hard when-not guidance — 'Never repeat an add to retry' — plus the exact failure and retry semantics (429 reasons), and points to get_lead_finder_filters for the applicable limits.

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