mcp-new-hire-finder
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| APIFY_TOKEN | Yes | Your Apify API token from console.apify.com/account/integrations, set as APIFY_TOKEN. The server lists its tool without a token; a call needs one. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| find_new_hiresA | 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 1 tool
There is only one tool, so there is no possibility of misselection between overlapping tools. Its purpose (finding new hires at target companies) is stated unambiguously in both name and description.
The single tool uses a clear snake_case verb_noun pattern (find_new_hires) that would scale predictably if more tools were added. No competing conventions exist to create inconsistency.
A single tool is on the thin side for what is otherwise a parameter-rich, multi-source lookup service; splitting discovery (companies/people lookup by run ID, retry of a failed run, credit/error inspection) into separate tools would make the surface easier to consume.
The one tool covers the core end-to-end workflow (company input, lookback window, title matching, flat per-person output plus per-company summary), which is solid for a read-only search service. Minor gaps: failed runs return a run ID but there is no tool to re-fetch or inspect a prior run, and no way to validate/normalize company domains separately.