Job Change Tracker MCP Server

Overview Schema Source Related Servers Discussions Admin

Track job change

track_job_change

Read-onlyIdempotent

Check if CRM contacts still work at the company on file and return current employer, title, start month, and status (left, landed, promoted, or still there).

Instructions

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.

Input Schema

TableJSON Schema

Name	Required	Description
`email`	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.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 16, 2026

TDQS

A4.6/5.0

Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

Deploy Server

Other Tools

track_job_changeA