Skip to main content
Glama

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

add_lead_finder_prospects

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 search_lead_finder 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: after an error or a timeout, call list_lead_finder_imports to see whether it started. 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 get_lead_finder_import 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). Poll get_lead_finder_import with the importId until finishedAt is set. Check get_credit_balance first; buy credits with purchase_credits.

Input Schema

TableJSON 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. Added

TDQS

A4.7/5.0
Behavior5/5

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

The description discloses far more than annotations: costs per person, metered email verification, non-idempotent repeat behavior ('repeating the same add adds the NEXT count people and charges again'), concurrency limits, and response fields like estimatedCredits and importId. It also explains skip conditions and edge cases such as catch-all addresses.

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 description is extremely long and dense, covering many edge cases without visual structure (no headings or bullets). While each sentence adds value, the sheer length makes it harder for an agent to parse quickly. Some details, such as verifyEmails behavior, are repeated from the schema, and the opening warning is front-loaded but the rest is a wall of text.

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?

With no output schema, the description fully covers return values, errors, prerequisites, and follow-up actions. It names related tools for polling (get_lead_finder_import), filter limits (get_lead_finder_filters), and credit purchases (purchase_credits), making it complete for correct invocation.

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, but the description adds critical behavioral semantics beyond the schema: mutual exclusivity of refs and filters, how repeat filters adds walk from the top and skip already-leads, and verification details for verifyEmails. It also clarifies that duplicates are dropped, which is not fully explicit 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?

The description opens with 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.' It clearly differentiates this from sibling tools like add_leads by tying it to Lead Finder and credits.

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?

The description explicitly describes two usage modes and when to use each: 'Pass refs ... to add exactly those people, or pass filters and count ... to add count people matching the filters.' It also provides strong anti-retry guidance ('Never repeat an add to retry: after an error or a timeout, call list_lead_finder_imports') and prerequisites ('Check get_credit_balance first').

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