Skip to main content
Glama

LiveCRM

by ai.livecrm
OverviewDiscussionsAdmin

Run Job Change Sweep

run_job_change_sweep

For this connection's contacts, WHICH OF THEM CHANGED JOBS -- and queue what follows for review. 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 batch-enriches the scope, compares each employer against the CRM, and for every mover enqueues the whole JOB_CHANGE_DEPARTURE: contact archived, account updated, owner alerted, person created at their new employer. IT IS THE WHOLE SEQUENCE -- no create run afterwards, the movers are created by the plan it enqueues. IT RUNS ITSELF AND TAKES NO DISPATCH STEP: confirming the plan starts it, so a dispatch_run after it makes the plan unexecutable. It returns a task id and movers appear in the queue as it finds them. NOTHING REACHES THE CRM WITHOUT A PERSON: every action lands in the review queue. IT SPENDS: one credit per contact the first time it is enriched, free afterwards, so a book never swept is the expensive pass. credit_cap IS REQUIRED and is the most it may spend; if a person names a budget, set it here, and a scope past it leaves the remainder UNASKED, not unmoved. A cap above the workspace's per-run maximum is refused.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
credit_capYesRequired: the most provider credits this sweep may spend, one per contact asked about at most. Contacts past it are not asked about by this sweep; if a person names a budget, this is it.
filter_specNoWHICH contacts to ask about, as a filter over the mirror -- the same grammar count_crm_records takes, so a population you have already counted can be swept unchanged. Omit it and every contact on the connection is swept, up to credit_cap, which is rarely what a person asking a question means: a sweep of the whole book enriches contacts across it and charges for each one never enriched before.
connection_idYesThe CRM connection. Call list_crm_connections first.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / description
      Previous value: -"Which contacts to ask about. Omit the filter and it asks about all of them.\n\nTHE FILTER IS THE DIFFERENCE BETWEEN THIS AND THE NIGHTLY SWEEP. run() covers the whole book because\nthat is what a scheduled pass is for; a person asking about their procurement contacts means those,\nand _select_subjects has always taken a scope to say so. Without it here, a question about some\ncontacts would enrich every contact on the connection and charge for all of them."New value: +"Which contacts to ask about. Omit the filter and it asks about all of them.\n\nA person asking about their procurement contacts means those, and _select_subjects has always taken a\nscope to say so. Without it here, a question about some contacts would enrich every contact on the\nconnection, up to the sweep's credit_cap, and charge for each."
    • addedInput schema / properties / credit_cap
      Added value: +{
+  "description": "Required: the most provider credits this sweep may spend, one per contact asked about at most. Contacts past it are not asked about by this sweep; if a person names a budget, this is it.",
+  "minimum": 1,
+  "title": "Credit Cap",
+  "type": "integer"
+}
    • changedInput schema / properties / filter_spec / description
      Previous value: -"WHICH contacts to ask about, as a filter over the mirror -- the same grammar count_crm_records takes, so a population you have already counted can be swept unchanged. Omit it and every contact on the connection is swept, which is what the nightly pass does and is rarely what a person asking a question means: a sweep of the whole book enriches every contact on it and charges for each one that has never been enriched before."New value: +"WHICH contacts to ask about, as a filter over the mirror -- the same grammar count_crm_records takes, so a population you have already counted can be swept unchanged. Omit it and every contact on the connection is swept, up to credit_cap, which is rarely what a person asking a question means: a sweep of the whole book enriches contacts across it and charges for each one never enriched before."
    • changedInput schema / required
      Previous value: -[
-  "connection_id"
-]New value: +[
+  "connection_id",
+  "credit_cap"
+]
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the annotations (readOnly=false, destructive=false, openWorld=true) by disclosing cost mechanics (one credit per contact first enriched, free after), that credit_cap is required and caps spend, that a cap above the workspace max is refused, that nothing lands in the CRM without review, and that it returns a task id. These are exactly the behavioral facts an agent needs before invoking a spending mutation.

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 is front-loaded in the first clause and every block carries a distinct operational warning (no dispatch, credit spend, cap behavior). It is dense and the heavy all-caps emphasis and repetition around 'review queue' cost it a point, but there is little genuinely wasted text.

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 complex, cost-bearing, non-idempotent batch tool with no output schema, the description supplies everything needed: what it produces (task id, movers surfacing in the queue), the side-effect sequence it triggers, the spend model, and the required cap. Nothing material to 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% and the schema prose is already rich, so baseline is 3. The description still adds decision-relevant meaning: that credit_cap is where a stated budget goes, that a scope exceeding it leaves contacts unasked rather than unmoved, and that omitting filter_spec sweeps and charges for the entire book. It slightly exceeds baseline by tying parameters to the spending consequence.

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 concrete verb+resource: it identifies which contacts changed jobs and enqueues the JOB_CHANGE_DEPARTURE sequence for each mover. It explicitly distinguishes itself from enrichment ('An enrichment run is NOT this... it cannot notice a move'), so an agent can separate it from create_enrichment_run and create_job_change_run without opening a schema.

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?

Explicit when-not-to-use (enrichment) and explicit operational routing: 'IT RUNS ITSELF AND TAKES NO DISPATCH STEP... a dispatch_run after it makes the plan unexecutable.' It also warns that omitting filter_spec sweeps the whole book and charges for it. Alternatives and preconditions are named rather than implied.

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