Skip to main content
Glama

Lead Finder: search the contact database (free)

search_lead_finder
Read-only

Searches Emailchaser's B2B contact database (Lead Finder) with explicit filters and returns one page of matching people, masked: first name, last initial, title, seniority, job function, company name, industry, size and revenue band, and location. Email addresses, domains, LinkedIn URLs and phone numbers are never shown; contact details are revealed only when people are added to a campaign. Spends no credits, but every result row uses the account's daily browsing allowance (rowsLeftToday; 2,000 rows a day by default, 250 on a trial). An account may start 20 searches a minute. Searches that find nobody also draw on a bucket of 120 that refills one every 30 seconds; while it is empty every new search is refused for a moment (rate_limited, reason empty_searches, with retryAfterSeconds). The same page asked for again within 10 minutes costs nothing. total is the exact audience size only when totalIsExact is true; otherwise it is a lower bound (often 50,000). If status is running or totalStatus is pending, total, hasMore and maxPage are recomputed when the search is read again by its searchId. The exact count is fetched in the background and can take up to about a minute, so totalStatus can read pending (and totalIsExact false) on several polls in a row: that is normal, not an error. The count is settled once totalIsExact is true or totalStatus is done (exact) or failed (the count could not be fetched, so total stays a lower bound); each read of the search waits about six seconds, so around ten reads cover it. The people already returned are final and usable the whole time: show them, and add them with their refs, without waiting for the count. status failed means the search did not run, and error says why (rate_limited, timeout, provider_blocked, budget_exhausted, invalid_filters, expired or internal): it is not an empty audience, so try again later. Each result's ref identifies that person when adding them to a campaign, valid for 60 minutes after its page was last shown. inWorkspace means Lead Finder added that person to this workspace and their lead is still there, so adding them again is skipped for free; someone who is a lead from another source shows false, and adding them is skipped for free too. A read-only key may use this tool.

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": {
      "filters": "<filters>"
    },
    "name": "search_lead_finder"
  }
}

Input Schema

NameRequiredDescriptionDefault
pageNoResults page, starting at 1 (default 1). The deepest page is 100 by default, and a search's maxPage says how deep that audience goes
filtersYesWho to look for. Every field is optional but at least one include filter is required. Free-text fields take up to 50 values of up to 100 characters each (get_lead_finder_filters has the limits that apply); a value with commas is split into one value per comma, and blank values are ignored. A filter the API cannot use is refused with the field, value and reason named.
pageSizeNoPeople per page: 25 (default) or 50

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?

Beyond the readOnly/openWorld annotations it discloses the full operational envelope: daily row allowance (2,000 vs 250 trial), 20 searches/minute, the 120-token empty-search bucket refilling every 30s with rate_limited/empty_searches/retryAfterSeconds behavior, a 10-minute result cache, and 60-minute ref validity. It also explains asynchronous total computation, the ~6 second per read and ~10 reads to settle, and gives a concrete error taxonomy distinguishing 'failed' from an empty audience — nothing contradicts the annotations.

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?

It is front-loaded correctly — purpose, returned fields, and masking rules come before the operational detail. The block is dense and long, with the 'pending is normal, not an error' point restated several times across sentences, which could be tightened, but nearly every sentence carries distinct operational information for a genuinely complex tool.

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 and a nested 3-parameter input, the description supplies the missing return contract (field list, totals, totalIsExact/totalStatus states, hasMore/maxPage recomputation, per-result ref lifetime, inWorkspace semantics) plus failure modes. An agent can call it, interpret partial results, and know when to poll again without further documentation.

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 schema already carries filter semantics and page/pageSize limits; the description nonetheless adds meaning by explaining that re-requesting the same page within 10 minutes is free and that maxPage bounds how deep an audience can be paged. It does not explain filter combination rules itself, deferring to get_lead_finder_filters, which is a minor gap but consistent with the schema text.

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 opening sentence gives a specific verb and resource ('Searches Emailchaser's B2B contact database (Lead Finder)'), states the filter-driven nature, and enumerates exactly what a result page contains (masked names, title, seniority, company, industry, size/revenue, location). It also immediately draws the boundary that emails, domains, LinkedIn URLs and phones are never returned, which distinguishes it from the enrichment/lead tools in the sibling set.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It makes the cost/eligibility context explicit ('spends no credits', 'a read-only key may use this tool') and points at the follow-up path by describing that contact details appear only once people are added to a campaign and that refs are used for adding. It stops short of naming the sibling tools to call for the next step (adding prospects) or for re-reading results by searchId, so the agent must infer those names.

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