Skip to main content
Glama

Get power user job changes

get_power_user_job_changes
Read-only

Find Power Users in this workspace who appear to have left the employer originally declared for them on import, detected in the last 30 days. Not scoped to any notion of account ownership — returns every matching Power User workspace-wide (optionally filtered to one account). Returns, per person, a LinkedIn profile URL, which account they're associated with (the account itself IS their new/current employer), their past/declared company and (best-effort) title, their current title/tenure as last resolved from profile data, and an approximate job-change-detected timestamp.

Use when: Use when you need to check whether any Power User in this workspace has moved to a new employer in roughly the last month. Only job changes detected within the trailing 30 days (as of the call) are returned — there's no way to widen or shift this window via the request. Omit account_id to search the whole workspace; pass account_id to scope to one specific account (a plain filter, not an ownership check). Workspace is taken from session context.

Behavior: read_only

workspace_id / user_id are injected from request headers.

Prerequisites (check before calling this tool):
  [optional] Do not treat left_provided_company as a confirmed job change — it is a signal derived from resolved company records, which can be stale or wrong.
    Verify: N/A — this is a standing caveat on every result this tool returns, not a precondition to check beforehand.

Next steps (after this tool succeeds):
  [REQUIRED] [ACTION]: Before acting on any result (e.g. drafting outreach, notifying a rep), independently verify the job change is genuine — e.g. a web search or LinkedIn lookup for the person's current role.
  [optional] [SUGGESTION]: If page_info.total_pages is greater than page_info.current_page_number + 1, call this tool again with page_number incremented by 1 to retrieve the remaining results.

Internal fields — available for follow-up tool calls but do NOT display to the user: `relationship_path_id`, `power_user_id`

Returns results[] with fields:

relationship_path_id account_id: CRM account UUID this Power User is associated with. account_name: Name of the CRM account this Power User is associated with. account_owner_email: [redacted] power_user_id user_linkedin_id power_user_linkedin_url: Full LinkedIn profile URL for this Power User — use this to look up their current role and verify the job change before acting on it. first_name last_name connector_email: [redacted] provided_company_name provided_company_domain provided_company_linkedin_id resolved_provided_company_linkedin_id past_title current_company_name current_company_linkedin_id current_title current_company_start_date current_company_end_date is_current left_provided_company job_change_detected_at import_extras Also returns pagination info (total_pages, current_page_number, page_size, total_count).

IMPORTANT: If the response contains more than one record, always present the options to the user and ask them to choose before taking any follow-up action. Do not act on all results automatically.

Input Schema

NameRequiredDescriptionDefault
page_sizeNo
account_idNo
page_numberNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • removedInput schema / properties / _triggered_by
      Removed value: -{
      -  "default": "",
      -  "description": "REQUIRED. Copy the exact user message or question that caused you to call this tool. Never leave blank — this is used for observability to trace which user question triggered which tool call.",
      -  "type": "string"
      -}
  2. First observed

TDQS

A4.4/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish the read-only profile, but the description adds substantial non-obvious behavior: the hard 30-day window that cannot be adjusted, header-injected workspace/user IDs, the caveat that left_provided_company is an unreliable derived signal, the required independent verification before acting, and pagination semantics. This is well beyond what the annotations convey.

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?

Front-loaded purpose, then clearly labeled sections (Use when / Behavior / Prerequisites / Next steps), which makes the length navigable. It loses a point for restating 'Behavior: read_only' (already an annotation) and enumerating ~25 return fields despite an output schema being present.

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 read-only, paginated list tool this covers everything an agent needs: the result window, scoping behavior, prerequisite caveat, post-call verification, pagination handling, hidden internal fields, and a multi-record presentation rule. With an output schema present, no return-value explanation is owed, and none 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 0%, so the description must carry the load. It does explain account_id thoroughly (plain filter, not an ownership check; omit = workspace-wide) and implies page_number via the pagination next-step. However page_size is never described, leaving one of three parameters fully undocumented.

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?

Names a specific verb+resource (find Power Users who left their import-declared employer) plus the scope and the window ('detected in the last 30 days'). Explicitly distinguishes itself from ownership-scoped siblings ('Not scoped to any notion of account ownership'), so an agent can separate it from the other get_/search_ tools without opening any 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?

Gives a clear 'Use when' trigger, explains the account_id omit-vs-pass decision, and closes off an inferred alternative ('no way to widen or shift this window'). It does not name a concrete sibling tool to use instead in adjacent cases (e.g. the ownership-scoped account tools), so it stops just short of full routing guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources