Skip to main content
Glama
mambalabsdev

mcp-new-hire-finder

Find new hires

find_new_hires
Read-onlyIdempotent

Identify people who started matching roles at target companies within a lookback window; get flat JSON rows with name, profile, title, start month, prior role, and move type.

Instructions

Find people who started a role matching your titles at a company inside a lookback window. Give company_domain (or company_domains), target_titles, and lookback_months. Returns one flat, Clay-ready JSON row per person with name, profile URL, title, start month, prior role, move type (new hire, internal promotion, or announcement only), and source, plus one summary row per company that says whether anyone was found or why nothing could be looked up. Runs on your own Prospeo, Serper, SerpApi, or Exa keys passed as inputs, and on a people list you send; it never fetches LinkedIn and holds no key of its own. A run that does not succeed is returned as an error with its run ID. Read-only; requires an APIFY_TOKEN and consumes Apify credits per call.

Input Schema

NameRequiredDescriptionDefault
peopleNoPeople you already hold, with role histories. Each item: person_name, company_domain, profile_url (optional), and roles, a list of {title, company_name, start (YYYY-MM), end (YYYY-MM or null)}. The same window, title, and move rules run on them, with no provider call.
sourcesNoRoutes to run. Default all. buyer_data is your people list; prospeo and web_search run only with your key; news, newsroom, and team_pages are free.
seniorityNoOptional. Keep only these seniority levels.
move_typesNoWhich moves to return and charge. new_hire is a person who came from another employer. promotion is a new role at the same employer. unknown is a hire announcement with no work history. Default new_hire only.
skip_cacheNoSearch again even when the same company and filters ran in the last 7 days. A cached result is returned free.
departmentsNoOptional. Keep only these departments.
exa_api_keyNoYour own Exa key. Exa people search returns work histories with start months, so its results need no enrichment. Your own key, sent as a run input; never stored by the actor.
company_nameNoOptional, single company runs only. Leave empty and the name is read from the homepage.
target_titlesNoTitle phrases to match, for example marketing, head of content, editor. A title matches when it contains every word of a phrase as a whole word. Also sent to Prospeo and web search as the title filter.
company_domainNoOne company domain, for example zapier.com. Use this or Company domains (batch); both are merged.
exclude_titlesNoOptional. Drop any title that contains one of these phrases, for example intern.
max_charge_usdNoOptional. The run stops before any charge that would take this run past this amount, and keeps every row already paid for. Leave empty to rely only on the maximum cost per run set in Apify, which the run also honors.
serper_api_keyNoYour own Serper.dev key for web search. One search per company by default. Search results carry no start date, so they are dated with your Prospeo key or counted as undated. Your own key, sent as a run input; never stored by the actor.
company_domainsNoA list of company domains. Each company gets its own summary row.
lookback_monthsNoHow many calendar months back to look, including this month. 1 to 24, default 6. 6 in October means May to October. Typed as text so Clay can send it.
prospeo_api_keyNoYour own Prospeo key. Gives the work history behind start month and move type. One Prospeo credit per search page of 25 people and one per person enrichment, billed by Prospeo to you. Never stored. Your own key, sent as a run input; never stored by the actor.
serpapi_api_keyNoYour own SerpApi key for web search. A different vendor from Serper. Your own key, sent as a run input; never stored by the actor.
include_year_onlyNoAlso return people whose start is known only to the year and could fall inside the window. They are charged like any row. Off by default.
web_search_providerNoWhich of your search keys to use. auto takes the first key present: Serper, then SerpApi, then Exa.
expand_title_synonymsNoAlso match a short synonym list (marketing also matches growth, brand, demand generation). Off by default, because every row is charged.
max_enrich_per_companyNoProspeo enrichment calls per company to date people found by web search, headlines, and team pages. 0 to 25, default 5.
max_people_per_companyNoMost person rows to return per company, newest starts first. 1 to 100, default 25.
max_prospeo_pages_per_companyNoProspeo search pages of 25 people per company. 1 to 4, default 1.
max_search_queries_per_companyNoWeb search queries per company on your key. 1 to 4, default 1.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior5/5

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

Annotations cover read-only/idempotent, but the description adds substantial context beyond them: it runs on the caller's own Prospeo/Serper/SerpApi/Exa keys, never fetches LinkedIn, holds no key of its own, requires an APIFY_TOKEN, consumes Apify credits per call, and returns failed runs as errors carrying the run ID. Auth, cost, and failure semantics are all disclosed.

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?

A dense but well-ordered block: purpose first, then required inputs, output shape, execution model, error handling, and safety. Every sentence carries information for a 24-parameter tool, though the single-paragraph density is slightly heavy.

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 properly explains the return shape (one flat Clay-ready row per person with named fields, plus one summary row per company and its reason when nothing is found) and the costs/keys involved. Given the tool's complexity and zero required params, this is complete enough to call correctly.

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 all 24 parameters in detail. The description restates only the three key inputs and names the move-type categories, adding little beyond what the schema enums already explain. Baseline 3 is appropriate.

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 first sentence states a specific verb and resource with scope: 'Find people who started a role matching your titles at a company inside a lookback window.' It is precise enough that an agent knows exactly what kind of result to expect, with no sibling tools to confuse it with.

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 tells the agent which inputs to supply ('Give company_domain (or company_domains), target_titles, and lookback_months') and clarifies the alternate data path (runs on a people list you send). It stops short of explicit when-not-to-use or exclusions, but the usage context is clear.

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

Deploy Server

Other Tools