Capable

Merge duplicate records

merge_records

Destructive

Merge duplicate contacts/accounts. Contact blanks fill without overwrites; links move (activities/tasks/notes/deals/rosters/enrollments/meetings/attachments/relationship fields). Email/phone/LinkedIn identities stay with the survivor. The archived duplicate points to it, so its id still resolves. Colliding rows (same activity or active sequence enrollment) stay in duplicate history and appear in collisions. Account merges require a workspace admin and active Core workspace; Core billing rules apply, without field filling. Preview first; only confirm:true changes data. Without keep_id/merge_id, list possible duplicates with the older record proposed to keep; record_id narrows the list.

When to use: Two records represent one person/company: merge to preserve history instead of deleting the twin.

Example: Merge these duplicate people; keep the one linked to the company.

Input Schema

Name	Required	Description
`limit`	No	Listing only: at most this many pairs (default 25).
`confirm`	No	true merges; omitted or false previews.
`keep_id`	No	The record that stays and keeps the history.
`merge_id`	No	The duplicate that is folded in and archived.
`record_id`	No	Listing only: possible duplicates of this record. People match by live email/phone/LinkedIn URL or name on one account; companies by domain/LinkedIn page/name. These are candidates, not proven identities.
`object_type`	Yes	What the ids are.
`expected_keep_revision`	No	The kept record's mcp_revision from the preview; the merge refuses if it moved.
`expected_merge_revision`	No	The duplicate's mcp_revision from the preview; the merge refuses if it moved.

Output Schema

Name	Required	Description	Default
`kept`	No
`note`	No
`filled`	No
`merged`	No
`preview`	No
`merged_id`	No
`candidates`	No
`collisions`	No
`object_type`	No
`identities_added`	No
`requires_confirm`	No
`transferred_links`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 27, 2026

changedInput schema / properties / record_id / description

Previous value: -"Listing only: possible duplicates of this one record."New value: +"Listing only: possible duplicates of this record. People match by live email/phone/LinkedIn URL or name on one account; companies by domain/LinkedIn page/name. These are candidates, not proven identities."

Changed5 schema fields changedOct 24, 2026

addedInput schema / properties / limit

Added value: +{
+  "description": "Listing only: at most this many pairs (default 25).",
+  "maximum": 100,
+  "minimum": 1,
+  "type": "integer"
+}

changedInput schema / properties / object_type / description

Previous value: -"What the two ids are."New value: +"What the ids are."

addedInput schema / properties / record_id

Added value: +{
+  "description": "Listing only: possible duplicates of this one record.",
+  "format": "uuid",
+  "type": "string"
+}

changedInput schema / required

Previous value: -[
-  "object_type",
-  "keep_id",
-  "merge_id"
-]New value: +[
+  "object_type"
+]

addedOutput schema / properties / candidates

Added value: +{
+  "items": {
+    "type": "object"
+  },
+  "type": "array"
+}

AddedOct 24, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare destructiveHint=true and non-idempotent, but the description adds substantial context beyond them: blank fields fill without overwriting, links move, identities stay with the survivor, the archived duplicate redirects by id, colliding rows are retained in duplicate history and reported in collisions, account merges require workspace admin and active Core workspace, and Core billing rules apply. This is exactly the behavioral detail an agent needs for a destructive merge.

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?

The description is dense but front-loaded: core merge behavior appears first, followed by a clear 'When to use' section and an example. Every sentence carries relevant operational detail for a destructive tool with eight parameters. It could be slightly tightened, but the length is justified by the complexity.

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?

Given the destructive nature, eight parameters, 100% schema coverage, and an output schema, the description covers everything an agent needs: listing vs merging modes, preview/confirm semantics, collision handling, identity retention, prerequisite conditions for account merges, and the archived-duplicate redirect. No critical gaps remain.

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 baseline is 3. The description adds value beyond the schema by explaining the default listing behavior when keep_id/merge_id are absent ('list possible duplicates with the older record proposed to keep') and how record_id narrows that list. It also clarifies that only confirm:true performs the merge. The schema already documents most parameter semantics, but the description supplements them usefully.

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?

The description opens with a specific verb and resource: 'Merge duplicate contacts/accounts.' It explicitly distinguishes merging from deleting ('merge to preserve history instead of deleting the twin') and clarifies the two supported object types. An agent can tell this apart from siblings like delete_record or update_record without opening the 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?

It provides an explicit 'When to use' section: 'Two records represent one person/company: merge to preserve history instead of deleting the twin.' It also states the alternative (deleting the twin) and describes the listing mode when keep_id/merge_id are omitted. The 'Preview first; only confirm:true changes data' guidance further clarifies safe invocation.

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

All Capable 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.

Resources

Need Help?