Skip to main content
Glama
mambalabsdev

Career Change Signal Engine MCP Server

Watch career changes

watch_career_changes

Track a contact watch list and return only what changed since the last run: departures, new employers, replacements, and hires after a role closed, with evidence and outreach payloads.

Instructions

Read a watch list of contacts and return only what changed since the last run: who left, who landed where, who replaced them, and who started after a role closed. Each row carries evidence, a source date, a segment, a first line draft, and Slack, HubSpot, HeyReach, and Instantly payloads. Pass people (required) and, optionally, replies, bounces, posting changes, suppression, and your own provider keys in providerKeys; it never fetches LinkedIn and holds no key of its own. State is kept per watch_list_id. A run that does not succeed is returned as an error with its run ID. Requires an APIFY_TOKEN and consumes Apify credits per call.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
peopleYesYour watch list, one object per person: person_name, profile_url (optional), company_domain, company_name, title, work_email, relationship (prospect, mgl, deal_contact, customer_champion), external_id, crm_id, deal_id, known_history (a HeyReach copy, a Proofed LinkedIn reader row, or generic roles), last_reading (with state_source caller). The engine reads only these people. At most max_people_per_run per run.
bouncesNoOptional bounces: work_email, bounce_type, smtp_code, smtp_text, bounced_at.
repliesNoOptional reply texts: external_id or work_email or profile_url, text, received_at, channel, is_auto_reply. Text is classified and dropped; only its sha1 is kept.
featuresNoSwitches: replacement, closed_posting, contact_data, first_line, icp, include_promotions. Defaults on except include_promotions.
icp_tiersNoOptional map of company domain to tier, shown on landed rows. Never blocks a row.
read_modeNostored_first: your known_history first, then your keys. live_only: ignore known_history. stored_only: only known_history, no key calls.
concurrencyNoPeople read at once.
suppressionNoemails, profile_urls, opted_out_emails, opted_out_profile_urls, company_domains, company_names. Suppressed people are dropped before the read and cost nothing.
webhook_urlNoOptional: signed Standard Webhooks POST of up to 100 signal rows per request.
providerKeysNoYour own keys: serper or serpapi (web search), prospeo, bounceban (verifier), findymail, exa. Never written to state, output, logs, or the webhook. Your own key, sent as a run input; never stored by the actor.
state_sourceNoactor: the engine keeps state between runs in a named store. caller: you send last_reading per person and keep state yourself.
max_spend_usdNoStops the run before a charge that would cross it.
watch_list_idNoNames the list. State is kept per watch list id when state_source is actor.
first_run_modeNoreport: the first run returns every change it finds. baseline: the first run stores state and returns nothing, charging only contact_checked.
sender_contextNoOptional topic phrase for the first line draft, for example: content production at scale.
webhook_secretNoSigning secret; a whsec_ value is base64 decoded. Your own key, sent as a run input; never stored by the actor.
posting_changesNoOptional Account Hiring Watch rows. A closed posting starts a new hire search at that company.
max_people_per_runNoA list longer than this fails the run before any read or charge. Default 150, at most 1,000.
sweep_interval_daysNoWith state_source actor, a person read within this many days is skipped.
linkedin_reader_dataset_idNoOptional: the dataset id of a Proofed LinkedIn reader run on the same Apify account. Rows join to people by profile URL.
max_replacement_candidatesNoCandidates proposed per leaver. A person confirms each.

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?

Adds substantial context beyond annotations: it never fetches LinkedIn and holds no key of its own, state is kept per watch_list_id, an APIFY_TOKEN is mandatory, and each call consumes Apify credits. This explains why readOnlyHint=false and idempotentHint=false despite the 'Read' framing (state writes, cost), and the error-with-run-ID contract is disclosed. No contradiction with annotations.

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 and output shape are front-loaded in the first two sentences, followed by inputs and operational constraints. Dense and mostly waste-free, though the input enumeration sentence slightly duplicates the schema's own parameter list.

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 21-parameter, nested, stateful tool with no output schema, the description covers the essentials: what a row contains (evidence, source date, segment, first-line draft, Slack/HubSpot/HeyReach/Instantly payloads), auth, cost, state persistence, and error behavior. Nothing an agent needs to invoke it correctly is missing.

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% across all 21 parameters, so the schema already documents every field in depth. The description restates a few of them (people required, replies, bounces, posting changes, suppression, providerKeys) but adds no syntax or format detail beyond the schema. Baseline 3 is correct.

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 ('Read a watch list of contacts') plus the precise delta semantics it returns ('who left, who landed where, who replaced them, and who started after a role closed'). No siblings exist, but the purpose is unambiguous without opening the schema.

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?

Makes the required input clear ('Pass people (required)') and names the optional inputs that shape a run (replies, bounces, posting changes, suppression, providerKeys). It explains the failure contract ('A run that does not succeed is returned as an error with its run ID') but gives no explicit when-not or alternative guidance, though no siblings exist to route against.

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