Skip to main content
Glama
mambalabsdev

mcp-people-finder

by mambalabsdev

Find People and Emails

find_people_and_emails
Read-onlyIdempotent

Find people at any company and verify their business email using a domain, company name, or LinkedIn URL, with filters for role, seniority, department, and location.

Instructions

Find people at a company and optionally discover and verify their business email. Identify the company by bare domain, by company name, by LinkedIn company URL, or pass a list of domains to run a batch where every output row echoes its source domain. Results are filtered by job title include and exclude lists, by normalized seniority, by normalized department and by country. A four layer cascade runs the company website, public search and a licensed database fallback, with company match scoring on every candidate; nothing here scrapes LinkedIn directly. Email discovery runs a two provider waterfall and verification escalates catch all domains to a second provider for a definitive answer. Provider keys are yours: you supply them, the vendors bill you directly, and the actor does not mark them up. Without a Serper key the search layer is off and coverage drops sharply. targetCount is a hard cost cap because billing is per person actually returned. Requires an APIFY_TOKEN and consumes Apify credits. Read only: it finds and verifies, it writes nothing.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
domainNoBare domain without https:// or trailing slash. Example: stripe.com
domainsNoOptional list of bare domains. Takes precedence over the single domain field. Each domain is searched independently and every output row echoes its source domain.
batchSizeNoHow many companies to search concurrently in batch mode. Default 5, maximum 10. Default: 5.
countriesNoISO 3166-1 alpha-2 codes. Filters to people located in these countries. Example: US, GB, NL
jobTitlesNoCase-insensitive substring match against the person's current title. Any match qualifies. Leave empty for no title filter. Example: VP Sales, Head of Growth
seniorityNoFilter to these normalized seniority levels. Leave empty for all.
skipCacheNoResults are cached for 7 days and reused on repeat lookups. Set true to force a fresh search. Default: false.
serpApiKeyNoSerper.dev API key. Unlocks the search layer, which is the highest-coverage source of LinkedIn profile URLs. Without it this actor falls back to company website parsing only, which returns far fewer people. Get a key at https://serper.dev. You are billed by Serper for searches; this actor does not mark them up.
departmentsNoFilter to these normalized departments. Leave empty for all.
reoonApiKeyNoPrimary email verification. Returns deliverability status for each discovered address. Get a key at https://emailverifier.reoon.com. Billed to you by Reoon.
targetCountNoMaximum people to return per company. Billing is per person actually returned, so a lower number is a hard cost cap. Default: 5.
claudeApiKeyNoOptional. Only used to classify job titles that the built-in rule table cannot place into a seniority and department. One batched call per run, never per person. Leave empty to leave those two fields null on the affected rows.
company_nameNoUsed when no domain is available, or as a disambiguation hint alongside a domain.
verifyEmailsNoCheck deliverability of each email found, escalating catch-all domains to a second provider for a definitive answer. Requires a Reoon and/or BounceBan key. Default: true.
icypeasApiKeyNoOptional. Only used for the licensed-database fallback layer, which runs when the company website and public search results do not yield enough people. Leave empty to skip that layer entirely; the run still succeeds and reports any shortfall in the summary.
includeEmailsNoDiscover a business email for each person found, using your Icypeas and/or Prospeo keys. Billed only when an email is actually returned. Turn off to build an org map cheaply. Default: true.
prospeoApiKeyNoSecond provider in the email waterfall. Used only for people the first provider could not resolve. Get a key at https://prospeo.io. Billed to you by Prospeo; this actor does not mark it up.
verifyPositionNoCheck that the person still holds the returned title at the target company, and report the reasoning. Reduces bounced outreach to people who have moved on. Default: false.
bounceBanApiKeyNoCatch-all resolution. Used only when the primary verifier returns catch-all or risky, to determine whether that specific mailbox exists. Get a key at https://bounceban.com. Billed to you by BounceBan.
excludeJobTitlesNoCase-insensitive substring match. A person matching any of these is dropped even if they matched an include. Example: intern, assistant, former
linkedin_company_urlNoExample: https://www.linkedin.com/company/stripe. Skips internal company resolution when provided.
suppressLinkedInUrlsNoLinkedIn profile URLs to exclude from results. Use to suppress already-contacted prospects or honor data subject removal requests.
Behavior5/5

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

The description discloses many behavioral traits beyond annotations: the four-layer cascade, no LinkedIn scraping, email provider waterfall, catch-all escalation, and the fact that provider keys are used directly with no markup. It also confirms the read-only nature, aligning with readOnlyHint and destructiveHint. This rich context adds significant value over 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?

The description is dense but well-structured, starting with the core purpose and then detailing pipeline behavior, constraints, and billing. Every sentence carries useful information; however, the length is considerable. It remains appropriately sized for a complex 22-parameter tool, and the front-loading of the core function is effective.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers identification, filtering, pipeline, costs, provider keys, and read-only behavior. Since there is no output schema, it does not explicitly specify the return structure beyond 'every output row echoes its source domain' and mentions a summary for shortfalls. This is a minor gap; otherwise the context is comprehensive for the tool's complexity.

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?

The input schema already describes all 22 parameters at 100% coverage, so the baseline is 3. The description adds high-level semantic context, such as targetCount acting as a cost cap, the precedence of domains over domain, and the overall identification modes. This goes slightly beyond the schema's per-parameter descriptions, earning a 4.

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 clear verb and resource: 'Find people at a company and optionally discover and verify their business email.' It then enumerates identification methods (domain, company name, LinkedIn URL, batch domains) and filtering dimensions, which fully specifies the tool's purpose. There are no sibling tools to distinguish from, and the description is unambiguous.

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 provides clear usage context: prerequisites (APIFY_TOKEN), cost implications (targetCount hard cap, provider billing), and consequences of missing keys (no Serper means lower coverage). It doesn't explicitly state 'use this when...' but the context is sufficient given no siblings. It lacks an explicit 'when not to use' section, which prevents a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/mambalabsdev/mcp-people-finder'

If you have feedback or need assistance with the MCP directory API, please join our Discord server