Check Job Change

Give it a LinkedIn profile URL, find out whether that person has recently changed jobs.

What it does

• Checks one LinkedIn profile for a recent job change. A bare username works in place of the full URL.
• Answers a single question — did this person move — so it is cheaper to read and act on than a full profile enrich.
• One profile per call, flat cost.

Two common uses:

• Timing. A new hire in their first 90 days is buying, rebuilding and replacing tools. This is the window.
• Hygiene. A champion who left means the contact record in your CRM is dead and the account may be at risk.

For a promotion rather than a move, use check_promotions.

Use cases

• Catch the 90-day buying window. Someone who just started is replacing tools and setting up their stack. Reaching them in that window beats reaching them in month ten.
• Follow a champion into their new company. A user who loved the product elsewhere is the warmest new-logo lead you have.
• Flag churn risk on open accounts. If the champion behind a live deal or renewal has left, the deal has no owner — surface it before the renewal date does.
• Keep CRM contacts alive. Run it across a stale contact list to find the records that are pointing at a company the person no longer works for.

How to use it

Has linkedin.com/in/janedoe changed jobs recently?

Check these 60 LinkedIn URLs for recent job changes. Return only the
people who moved, with their new company. Report credits used.

For everyone who moved, pull their new work email and draft a
three-line note referencing the new role.

Example prompts

Best prompting practices

• Say “changed jobs”. “Got a new role” is ambiguous — it may route your client to check_promotions, which is a different signal at the same price.
• Pass the profile URL, not the person. profile_url takes a LinkedIn URL or username. Give it a name and your client resolves the profile first, and a wrong Sarah Chen still bills 2 credits.
• Normalise the URLs before the run. linkedin.com/in/<slug> — drop the protocol, www., the trailing slash and any ?query. Unnormalised URLs are how a deduped list turns out not to be deduped.
• Deduplicate before the run. At 2 credits each, duplicate URLs are expensive.
• Ask for movers only, with the fields. “Return only the people who moved, as a table: name, old company, new company, new title, date detected.” A summary loses the date, which is the only thing that tells you whether the move is still fresh.
• Gate the spend. Number the steps and stop before the paid one: “count the deduped URLs, tell me the credit total, wait for my go-ahead.”
• Cap the batch. “Stop after 50 and report credits used” keeps a CRM sweep predictable.
• Re-check on a schedule, not on a loop. Job changes are slow-moving. Re-running the same list weekly doubles your spend for almost no new signal.
• Chain the follow-up. A mover needs a new work email — the old one is dead. Pair with find_work_email.

Output

{
  "profile_url": "https://linkedin.com/in/janedoe",
  "job_change": true,
  "new_company": "Ramp",
  "new_title": "VP Sales"
}

Credits and limits

2 credits per check, flat. Run check_credits (free) before sweeping a large list.

Parameters

Related tools

Next steps

• All MCP tools — the full catalogue with credit costs
• MCP use cases — signal-triggered outreach workflows
• Signals & ABM — workflows that chain this tool into a play

Keep learning

Two courses take these tools past the reference page — clustered by GTM job, then chained into workflows.