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 with add_lead_finder_prospects. 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, call get_lead_finder_search with the searchId: total, hasMore and maxPage are recomputed then. 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 is what add_lead_finder_prospects takes, 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.

Input Schema

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

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the readOnlyHint and openWorldHint annotations, the description discloses detailed runtime behavior: no credit spend, daily browsing allowance, per-minute search limits, empty-search rate limiting with retryAfterSeconds, 10-minute page caching, total exactness semantics, status and error handling, ref expiry, and inWorkspace behavior. This is exceptionally transparent.

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?

The description is long but every sentence carries a distinct behavioral fact with no filler or repetition. It is front-loaded with the core purpose before diving into limits and edge cases. A more structured layout would improve scannability, but the density is justified for this tool's complexity.

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?

Despite having no output schema, the description covers the critical output fields (total, totalIsExact, status, error, ref, inWorkspace) and all relevant operational constraints (rate limits, daily allowance, cache, ref validity). An agent has enough context to call the tool correctly and handle the main follow-up paths.

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 coverage is 100% and the schema already documents every parameter thoroughly, including filter constraints, defaults, and allowed values. The description adds no parameter-specific detail beyond the schema, so the baseline of 3 applies. It does not harm, but the schema is doing the heavy lifting.

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 names the exact action (search Emailchaser's B2B contact database), the resource (Lead Finder), and the output (one page of masked matching people). It also differentiates itself from add_lead_finder_prospects and get_lead_finder_search by explaining how contact details are revealed and how status is checked.

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?

The description gives clear context for when to use the tool and routes the agent to add_lead_finder_prospects for revealing contacts and to get_lead_finder_search when a search is still running. It does not explicitly contrast with get_lead_finder_filters or get_audience_size, but the intended use is clear enough for an agent.

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