Job Change Tracker MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| APIFY_TOKEN | Yes | Your Apify API token |
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 |
|---|---|
| track_job_changeA | 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. |
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 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.