Skip to main content
Glama
kostikpenzin

mcp-b24

by kostikpenzin
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

bx24_crm_duplicates

Find duplicate leads, contacts, or companies in Bitrix24 CRM by email, phone, or matching fields, then merge them into a single record via ID or batch operations.

Instructions

Bitrix24 CRM duplicate search & merge. Methods crm.duplicate.*, crm.entity.mergeBatch (REST 1.0 + 3.0). RU/EN: дубли, найти дубли, объединить / duplicates, find duplicates, merge.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
typeNoCommunication type for findbycomm
orderNoOrder object (e.g. { 'ID': 'DESC' })
startNoPagination offset (number of records to skip)
actionYesOperation to perform: - "findbycomm": Find duplicates by communication (email/phone) - "findbyfields": Find duplicates by matching fields - "merge": Merge entities by ID (mainId absorbs otherIds) — destructive - "mergeBatch": Batch-merge duplicates — destructive, irreversible - "volatileType_fields": Describe volatile duplicate type fields - "volatileType_list": List volatile duplicate types - "volatileType_register": Register a volatile duplicate type - "volatileType_unregister": Unregister a volatile duplicate type (destructive) - "status_list": List CRM status/dictionary elements (stages, sources, ...) - "status_get": Get a status element by ID - "status_add": Create a status element - "status_update": Update a status element - "status_delete": Delete a status element (destructive) - "status_fields": Describe status fields - "status_entity_items": Get status items by entity ID - "status_entity_types": List status entity types
entityNoEntity type for findbyfields/merge
fieldsNoFields to match for findbyfields (e.g. NAME, LAST_NAME, EMAIL)
filterNoFilter object (e.g. { '>OPPORTUNITY': 10000, 'STAGE_ID': 'WON' })
mainIdNoEntity ID
selectNoArray of field names to return (projection)
valuesNoCommunication values (emails or phones)
confirmNoSet to true to confirm destructive actions when BX24_CONFIRM_DESTRUCTIVE is enabled.
otherIdsNoIDs to merge into mainId
statusIdNoCRM status ID (crm.status.* / dictionaries)
statusFieldsNoStatus element fields: NAME, STATUS_ID, SORT, COLOR
statusEntityIdNoStatus entity ID (e.g. STATUS, SOURCE)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.0

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries the behavioral disclosure burden, but it only says 'search & merge' and lists method names. It does not mention that merge is destructive, irreversible, or causes mainId to absorb otherIds; the schema conveys these details, but the description adds no behavioral safety context beyond 'merge.'

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?

The description is very compact: one purpose sentence, one method sentence, and one multilingual keyword sentence. It is front-loaded with the primary purpose and contains no filler or repetition.

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

Completeness2/5

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

This is a highly complex tool with 15 parameters, 16 distinct actions, and no output schema, yet the description does not explain return values, destructive side effects, or which action family to use when. The rich schema partially compensates, but an agent would still lack high-level guidance for safely invoking this tool.

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 100%, so the schema already documents every parameter and action. The description adds no parameter-level meaning, but under the baseline rule this is acceptable and needs no deduction.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb+resource ('Bitrix24 CRM duplicate search & merge') and names the relevant REST methods, which clearly separates this tool from the CRM siblings. However, it only advertises duplicate search/merge even though the schema includes a large set of status_* and volatileType_* actions, so it under-describes the tool's actual scope.

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

Usage Guidelines2/5

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

There is no explicit guidance about when to choose this tool over alternatives, and no exclusions such as 'for regular CRM records use bx24_crm_leads/contacts/etc.' The RU/EN keyword aliases imply duplicate-related queries, but they do not tell an agent when status or volatile-type actions are appropriate.

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

Deploy Server

Other Tools