Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Job Change Tracker MCP Server Check if Jane Doe still works at example.com and where she went"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server for the Mamba Labs Job Change Tracker actor on Apify. Send the contacts in your CRM. Get one row back per person: where they work now, their title, when they started, their role history, and whether they left the company you know them at, landed somewhere new, or moved up inside the same company. Every row says how the person was matched, which source the answer came from, and how old that source is.
Related MCP server: Team Page People Extractor MCP Server
Check whether one contact, or a list of contacts, still works at the company your records hold. Returns one flat, Clay-ready JSON row per person: current employer, title, start month, role history, status (left, landed, promoted, or still there), how the person was matched, the source of the answer, and that source's date, with a namesake check. Runs on data you send (known_history) and on your own Serper or SerpApi, Prospeo, and BounceBan keys passed as inputs; this tool never fetches LinkedIn and holds no key of its own. Provide person_name with company_domain or company_name, or a people list. 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.
All of the work runs on Apify. This package is a thin client that starts the actor run, waits for it, and hands back the dataset rows.
You need Node.js 18 or newer and an Apify account with an API token.
Add this to your Claude Desktop config (claude_desktop_config.json), Cursor, or any MCP client:
{
"mcpServers": {
"mamba-job-change-tracker": {
"command": "npx",
"args": [
"-y",
"@mambalabsdev/mcp-job-change-tracker"
],
"env": {
"APIFY_TOKEN": "your-apify-token"
}
}
}
}Restart the client. The track_job_change tool appears.
Node.js 18 or newer.
An 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.
"Check whether Jane Doe still works at example.com and where she went if she left."
"Run these 20 contacts and tell me who changed jobs in the last 6 months."
track_job_change. One tool. Example arguments:
{
"person_name": "Jane Doe",
"company_domain": "example.com",
"company_name": "Example Inc"
}Every buyer facing input of the live actor, unchanged. Omitted inputs take the actor's own defaults.
Input | Type | Required | Description |
| string | no | Full name of the person to check. |
| string | no | Website domain of the company your records place this person at, for example microsoft.com. Left, landed, and promoted are worked out against this company. |
| string | no | Name of that company. Used with or instead of the domain to match roles in the person's history. |
| string | no | The title your records hold. Echoed on the row as input_title. |
| string | no | Optional. The person's LinkedIn profile URL, used as the identity. This actor never opens it. Without it, the run looks the profile up with your search key and charges profile_resolved when it finds and accepts one. |
| string | no | Optional. The person's work address at the last known company. With a BounceBan key, an undeliverable answer marks the person as left. |
| string | no | Optional. The strongest company match when a role history carries LinkedIn company URLs. |
| string | no | Optional. Echoed for your records. |
| string | no | Optional. Returned unchanged on the row so you can join it back to your CRM or table. |
| string | no | Optional. A role history you already have, as JSON: {"source": "heyreach", "source_date": "2026-10-07", "experiences": [...]} or {"source": "crm", "roles": [{"company_name", "title", "start_month", "end_month"}]}. Read before any paid key; a history newer than Max source age skips Prospeo. |
| array | no | Many people at once. Each item takes the same keys as the single person fields: person_name, company_domain, company_name, last_known_title, profile_url, email, company_linkedin_url, location, input_id, and known_history (an object). |
| string | no | Optional. Web search (serper.dev): finds profile URLs and reads the search result line for the current role. About 1 to 3 searches per person. Your own key, sent as a run input; never stored by the actor. |
| string | no | Optional. Used for web search only when no Serper key is set. Your own key, sent as a run input; never stored by the actor. |
| string | no | Optional. Prospeo enrich-person: the person's role history with start and end months. Skipped when you send a fresh history of your own. Your own key, sent as a run input; never stored by the actor. |
| string | no | Optional. Verifies the old work address only while the person still reads as at the company. Only an undeliverable answer is used. Your own key, sent as a run input; never stored by the actor. |
| string | no | A history you send that is older than this is treated as lagging, so the run also reads Prospeo and the search result. Default 30. |
| string | no | Free. Looks for the person on up to 4 team and about pages of the last known company domain. |
| string | no | Free. Cites up to 3 headlines from the last year that name the person with a move word. Evidence only; a headline never sets the employer. |
| string | no | With a BounceBan key: one check per person who still reads as at the company. Uses the address you send, or one Prospeo returns on the company domain. |
| string | no | No keeps role_count and drops the role_history array. |
| string | no | Reuse a reading made in the last N days, uncharged, from a store in your own Apify account. 0 turns it off. Rows with your own history are never cached. Default 7. |
| string | no | Stop after this many people. Default 1000. |
| string | no | Optional. The run stops before any row that would take its event charges past this amount. |
Pay per event on Apify, billed to your Apify account. Prices in USD.
Event | Free plan | Bronze | Silver | Gold |
| $0.025 | $0.02375 | $0.0225 | $0.02125 |
| $0.006 | $0.0057 | $0.0054 | $0.0051 |
| $0.001 | $0.001 | $0.001 | $0.001 |
The actor holds no provider key of its own. Every paid provider key is yours, passed as an input and stored by Apify as a secret input. Without a key, the actor skips that step and says so in the run.
apify.com/mambalabs/job-change-tracker
MIT. See LICENSE.
Check whether one contact, or a list of contacts, still works at the company your records hold. Returns one flat, Clay-ready JSON row per person: current employer, title, start month, role history, status (left, landed, promoted, or still there), how the person was matched, the source of the answer, and that source's date, with a namesake check. Runs on data you send (known_history) and on your own Serper or SerpApi, Prospeo, and BounceBan keys passed as inputs; this tool never fetches LinkedIn and holds no key of its own. Provide person_name with company_domain or company_name, or a people list. 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.
| Name | Required | Description | Default |
|---|---|---|---|
| No | Optional. The person's work address at the last known company. With a BounceBan key, an undeliverable answer marks the person as left. | ||
| people | No | Many people at once. Each item takes the same keys as the single person fields: person_name, company_domain, company_name, last_known_title, profile_url, email, company_linkedin_url, location, input_id, and known_history (an object). | |
| input_id | No | Optional. Returned unchanged on the row so you can join it back to your CRM or table. | |
| location | No | Optional. Echoed for your records. | |
| checkNews | No | Free. Cites up to 3 headlines from the last year that name the person with a move word. Evidence only; a headline never sets the employer. | |
| maxPeople | No | Stop after this many people. Default 1000. | |
| serpApiKey | No | Optional. Used for web search only when no Serper key is set. Your own key, sent as a run input; never stored by the actor. | |
| person_name | No | Full name of the person to check. | |
| profile_url | No | Optional. The person's LinkedIn profile URL, used as the identity. This actor never opens it. Without it, the run looks the profile up with your search key and charges profile_resolved when it finds and accepts one. | |
| cacheTtlDays | No | Reuse a reading made in the last N days, uncharged, from a store in your own Apify account. 0 turns it off. Rows with your own history are never cached. Default 7. | |
| company_name | No | Name of that company. Used with or instead of the domain to match roles in the person's history. | |
| serperApiKey | No | Optional. Web search (serper.dev): finds profile URLs and reads the search result line for the current role. About 1 to 3 searches per person. Your own key, sent as a run input; never stored by the actor. | |
| known_history | No | Optional. A role history you already have, as JSON: {"source": "heyreach", "source_date": "2026-10-07", "experiences": [...]} or {"source": "crm", "roles": [{"company_name", "title", "start_month", "end_month"}]}. Read before any paid key; a history newer than Max source age skips Prospeo. | |
| prospeoApiKey | No | Optional. Prospeo enrich-person: the person's role history with start and end months. Skipped when you send a fresh history of your own. Your own key, sent as a run input; never stored by the actor. | |
| company_domain | No | Website domain of the company your records place this person at, for example microsoft.com. Left, landed, and promoted are worked out against this company. | |
| max_charge_usd | No | Optional. The run stops before any row that would take its event charges past this amount. | |
| verifyOldEmail | No | With a BounceBan key: one check per person who still reads as at the company. Uses the address you send, or one Prospeo returns on the company domain. | |
| bouncebanApiKey | No | Optional. Verifies the old work address only while the person still reads as at the company. Only an undeliverable answer is used. Your own key, sent as a run input; never stored by the actor. | |
| checkCompanySite | No | Free. Looks for the person on up to 4 team and about pages of the last known company domain. | |
| last_known_title | No | The title your records hold. Echoed on the row as input_title. | |
| maxSourceAgeDays | No | A history you send that is older than this is treated as lagging, so the run also reads Prospeo and the search result. Default 30. | |
| includeRoleHistory | No | No keeps role_count and drops the role_history array. | |
| company_linkedin_url | No | Optional. The strongest company match when a role history carries LinkedIn company URLs. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations (readOnly/openWorld/idempotent/non-destructive) by disclosing the credit/charging model, the APIFY_TOKEN requirement, that it never fetches LinkedIn and holds no key of its own, that failures return an error with a run ID, and how caching behaves. With annotations already covering safety, this adds substantial operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded in the first sentence and the return shape follows immediately; the second sentence packs cost, key, and error semantics. It is dense and list-like but every clause carries weight for a 23-parameter tool, with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 23-parameter tool with no output schema, the description compensates by describing the returned row (employer, title, start month, role history, status, match method, source and source date, namesake check) and the error behavior. Nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds meaningful semantics the schema does not: the required input combination (person_name + company_domain/company_name, or people list), that serpApiKey is only used when no Serper key is set, and that known_history is read before any paid key. That relationship-level guidance lifts it above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Check whether one contact... still works at the company your records hold') and enumerates the returned fields, so an agent knows exactly what the tool produces. No sibling tools exist to disambiguate against, but the scope is precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear invocation guidance: 'Provide person_name with company_domain or company_name, or a people list,' and explains which inputs drive which behavior (known_history read first, keys optional, 0 required params). It stops short of explicit when-not-to-use conditions, but with no alternatives to route between, the context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0track_job_changeScored across 1 tool
There is only a single tool, so there is no possibility of misselection or overlapping purpose. Its scope (batch job-change verification for contacts) is clearly stated.
The lone tool follows a clean verb_noun snake_case pattern (track_job_change). With one tool there is no convention mixing to penalize.
A single tool is defensible for a narrow, one-shot enrichment service that accepts a list of people, but it is thin: there is no companion tool for retrieving async run results, checking credits, or inspecting history.
The core verification operation is covered and returns rich per-person output, but the surface has a dead end: failures return a run ID with no tool to fetch results by that ID, and there is no way to query past runs or validate configuration/keys separately.
Open jobs and hiring changes for any company, from its domain. Runs on Apify.
Live LinkedIn people, company, post and job data, ICP search and job-change signals for AI agents.
Find and enrich people from 750M professional profiles, with Next Move Signal job-change scores.
People, company, job and LinkedIn post data, plus email finding and verification.
