Skip to main content
Glama

LiveCRM

by ai.livecrm
OverviewDiscussionsAdmin

Create Job Change Run

create_job_change_run

Create a run that asks, for a scope of CONTACTS, which of them have CHANGED JOBS -- and queues what follows for review. This is the tool for 'check whether our contacts have moved', 'our data goes stale because people leave and nobody tells us', 'find me the people who are no longer there'. It does nothing until dispatched. AN ENRICHMENT RUN IS NOT THIS. Enrichment fills a contact's own missing fields and maps no employer, so it cannot notice a move. This one compares each contact's current employer against what the CRM believes and acts on the difference. IT IS THE WHOLE SEQUENCE. For every mover it queues the entire departure -- contact archived, account updated, owner alerted, person created at their new employer -- so no create run or alert run belongs after it. NOTHING REACHES THE CRM WITHOUT A PERSON: every one of those lands in the review queue. SCOPE AND A CREDIT CAP ARE THE CONFIGURATION. Always contacts, so there is no object to choose. credit_cap is required and is the most the run may spend, one credit per contact asked about at most; if a person asks for a budget, set it here. A cap above the workspace's per-run maximum is refused. IT SPENDS: one credit per contact the first time it is asked about, free afterwards, so a book never checked is the expensive pass and a repeat is close to free. IT DOES NOT RE-ASK ABOUT SOMEBODY IT ASKED ABOUT RECENTLY, which is what makes it safe to SCHEDULE: put it in a plan with a schedule and each firing advances through the book rather than re-checking the same contacts.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesA name for the run, shown in the Runs tab. It asks the provider who in scope has changed jobs and queues each mover's departure.
credit_capYesRequired: the most provider credits this run may spend, one per contact asked about at most. Contacts past it are not asked about by this run.
filter_specNoWhich records this run covers, as a filter tree. Omit for the whole object. It DESCRIBES a population and is resolved when the run is DISPATCHED, so write what you mean -- the CRO at Skypoint is `account_name is Skypoint AND title contains CRO` -- and never look a record up to write one. You need no ids and no counts. Call list_filterable_fields first, for the field names and operators only.
connection_idYesThe CRM connection. Required. Call list_crm_connections to get one.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / description
      Previous value: -"The Job Change run's create contract. TWO fields, and the emptiness is the point.\n\nfilter_spec is the whole configuration: WHICH contacts to ask about. There is nothing else to say --\nno scheme, no mapping, no per-record value -- because the question this run asks is fixed (\"has this\nperson moved?\") and what it does with a yes is fixed too: it enqueues the departure the reactive path\nhas always enqueued.\n\nNO object_type. It is always contacts. An account does not change jobs, and a lead that has is a\ncontact this product has not met yet; offering the choice would be offering three answers to a\nquestion with one.\n\nNO DISPOSITION, for the reason the alert run has none but arriving from the other side. `propose` is\nnot a mode here -- it is what this run ALWAYS does. Every mover becomes review-queue rows a person\napproves one at a time, so a run that \"executes\" and a run that \"proposes\" would be the same run.\n\nNO CREDIT CAP. Every other spending tool carries its ceiling in its own arguments; this one's is the\ndeployment's JOB_CHANGE_SWEEP_CREDIT_CAP and cannot be set per run. The plan estimator prices against\nthat ceiling and says so before anybody confirms, which is the honest version of a cap a person\ncannot set."New value: +"The Job Change run's create contract. TWO fields, and the emptiness is the point.\n\nfilter_spec is the whole configuration: WHICH contacts to ask about. There is nothing else to say --\nno scheme, no mapping, no per-record value -- because the question this run asks is fixed (\"has this\nperson moved?\") and what it does with a yes is fixed too: it enqueues the departure the reactive path\nhas always enqueued.\n\nNO object_type. It is always contacts. An account does not change jobs, and a lead that has is a\ncontact this product has not met yet; offering the choice would be offering three answers to a\nquestion with one.\n\nNO DISPOSITION, for the reason the alert run has none but arriving from the other side. `propose` is\nnot a mode here -- it is what this run ALWAYS does. Every mover becomes review-queue rows a person\napproves one at a time, so a run that \"executes\" and a run that \"proposes\" would be the same run.\n\nITS OWN CREDIT CAP (spend controls), as every other spending tool carries in its own arguments: the most\nprovider credits its pass may spend, one per contact asked about at most. Required, and refused above the\nworkspace's per-run maximum when an admin has set one."
    • addedInput schema / properties / credit_cap
      Added value: +{
+  "description": "Required: the most provider credits this run may spend, one per contact asked about at most. Contacts past it are not asked about by this run.",
+  "minimum": 1,
+  "title": "Credit Cap",
+  "type": "integer"
+}
    • changedInput schema / required
      Previous value: -[
-  "connection_id",
-  "name"
-]New value: +[
+  "connection_id",
+  "credit_cap",
+  "name"
+]
  2. First observed

TDQS

A4.3/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false, openWorldHint=false, and the description's review-queue framing is consistent with destructiveHint=false rather than contradicting it. It adds genuinely useful undisclosed behavior: the credit economics (one credit per contact first ask, free on re-ask), the de-duplication of recent asks, the workspace per-run cap refusal, and the 'nothing reaches the CRM without a person' review gate. That is real context beyond the annotations, but much of the credit-cap text merely restates the schema's own field description, so it lands at solid-but-not-maximal.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core verb and the enrichment contrast, which is good, but the body is heavily padded with all-caps emphasis and repeats material the schema already carries (credit cap, no object_type, filter_spec scope appear in both places). The shouty formatting and duplicated arguments make it slower to scan than its information content warrants.

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 create tool with no output schema, it covers the full lifecycle an agent needs: dispatch requirement, credit spend mechanics, review-queue disposition, scheduling safety, and scope configuration. Combined with the 100%-covered input schema, nothing material for correct invocation 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; the description earns a 4 by explaining what the schema cannot say — why there is no object_type (always contacts), why there is no disposition ('propose is what this run ALWAYS does'), and the intent behind credit_cap ('if a person asks for a budget, set it here'). It adds rationale rather than field syntax, which is the right layer given the schema already documents each field.

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+resource (create a job-change run) and pins down exactly what the run asks ('which contacts have changed jobs') and what it queues ('each mover's departure'). It explicitly distinguishes itself from the closest sibling, create_enrichment_run ('AN ENRICHMENT RUN IS NOT THIS... it maps no employer'), and rules out create_records_run/create_alert_run as follow-ups.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete user phrasings that select it ('check whether our contacts have moved', 'people who are no longer there'), states the precondition ('does nothing until dispatched'), and names the when-not ('no create run or alert run belongs after it'). It also explains the safe-scheduling condition, covering when/when-not/alternative in one pass.

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

All LiveCRM toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources