LiveCRM

Create Deduplication Run

create_deduplication_run

Create a run that finds duplicate records in a scope and queues each group for review. It does nothing until dispatched, and it merges nothing on its own -- a merge is a separate decision per group, through approve_duplicate_group. It requires one rule template per kind (matching, master_record, survivorship); the connection is seeded a Default for each.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "connection_id": "<connection_id>",
      "name": "<name>",
      "object_type": "<object_type>",
      "template_ids": "<template_ids>"
    },
    "name": "create_deduplication_run"
  }
}

Input Schema

Name	Required	Description
`name`	Yes	A name for the run, shown in the Runs tab. It finds duplicates; it does not merge them.
`write_back`	No	Has no effect on a deduplication run, which never writes when dispatched: it detects duplicate groups and queues each for review. Leave it unset.
`filter_spec`	No	Which 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.
`object_type`	Yes	Which records the run deduplicates: contact, account or lead finds duplicates within that object; lead_to_contact (Salesforce only) matches each Lead in scope against existing Contacts, and approving a group converts the Lead into that Contact and its Account. For lead_to_contact the filter_spec scopes Leads (object_type 'lead'), and the templates are lead_to_contact templates.
`template_ids`	Yes	One rule template id per kind: matching, master_record and survivorship. All three are required -- a run that does not fully specify its pass is refused. Call list_rule_templates with tool_type=deduplication to get them; every connection is seeded a Default of each kind.
`connection_id`	Yes	The CRM connection. Required. Call list_crm_connections to get one.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 9, 2026

changedInput schema / properties / object_type / description

Previous value: -"Which CRM object the run targets: contact, account or lead."New value: +"Which records the run deduplicates: contact, account or lead finds duplicates within that object; lead_to_contact (Salesforce only) matches each Lead in scope against existing Contacts, and approving a group converts the Lead into that Contact and its Account. For lead_to_contact the filter_spec scopes Leads (object_type 'lead'), and the templates are lead_to_contact templates."

Changed1 schema field changedOct 14, 2026

addedInput schema / properties / write_back / description

Added value: +"Has no effect on a deduplication run, which never writes when dispatched: it detects duplicate groups and queues each for review. Leave it unset."

First observedOct 14, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Adds real behavioral context beyond the annotations: the tool is non-destructive despite being a create/mutation (annotations give destructiveHint=false but not why), it never writes when dispatched, and it merges nothing on its own. The gap is return behavior — no output schema exists and the description never says whether a run id comes back.

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

Conciseness5/5

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

Three short sentences, no waste: purpose first, the 'does nothing / merges nothing' constraint second, the template requirement last. Nothing is buried and nothing repeats the title.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given six parameters, a deep filter_spec tree, and no output schema, the description covers the essential mental model — detect, queue, await dispatch, merge elsewhere. The only shortfall is the unstated return value and the unnamed dispatch step, both small against a fully documented schema.

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 coverage is 100%, so all six parameters are already documented in detail. The description's notes on one-template-per-kind and seeded Defaults largely restate the template_ids and connection_id schema descriptions, adding reinforcement rather than new meaning; baseline 3 is appropriate.

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 ('Create a run that finds duplicate records in a scope and queues each group for review') and immediately distinguishes its outcome from the merge-oriented sibling approve_duplicate_group. An agent can separate it from the many other create_*_run siblings by the 'duplicates / review queue' framing alone.

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?

Clear about the lifecycle: nothing happens until dispatched, and merging is a separate per-group decision routed explicitly to approve_duplicate_group. It does not name dispatch_run as the next required call, so the agent must infer the dispatch step from 'does nothing until dispatched'.

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

All LiveCRM tools Inspect

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.