Skip to main content
Glama
kostikpenzin

mcp-b24

by kostikpenzin
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

bx24_crm_requisites

Manage Bitrix24 CRM requisites: create, read, update, and delete company details, presets, bank details, links, and user fields. Resolve missing or outdated requisites with direct REST operations.

Instructions

Bitrix24 CRM requisites (реквизиты): CRUD, presets, bank details, links, user fields. Methods crm.requisite., crm.requisite.preset., crm.requisite.bankdetail., crm.requisite.link., crm.requisite.userfield.* (REST 1.0 + 3.0). RU/EN: реквизиты, добавить реквизиты компании, пресет, банковские реквизиты, привязка / requisites, company details, preset, bank details, link.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoEntity ID
orderNoOrder object (e.g. { 'ID': 'DESC' })
startNoPagination offset (number of records to skip)
actionYesOperation to perform: - "add": Create requisite (INN/KPP/etc.) for a company/contact - "get": Get a requisite by ID - "list": List requisites - "update": Update requisite fields - "delete": Delete a requisite (destructive) - "fields": Describe requisite fields - "preset_list": List requisite presets - "preset_get": Get a preset by ID - "preset_add": Add a requisite preset - "preset_update": Update a preset - "preset_delete": Delete a preset (destructive) - "preset_countries": List preset countries - "preset_fields": Describe preset fields - "bankdetail_add": Add bank details - "bankdetail_get": Get bank details - "bankdetail_list": List bank details - "bankdetail_update": Update bank details - "bankdetail_delete": Delete bank details (destructive) - "bankdetail_fields": Describe bank detail fields - "link_add": Link a requisite to an entity - "link_register": Register a requisite link - "link_get": Get a requisite link - "link_list": List requisite links - "link_unregister": Unregister a requisite link (destructive) - "link_fields": Describe link fields - "userfield_add": Create a requisite user field - "userfield_get": Get a requisite user field - "userfield_list": List requisite user fields - "userfield_update": Update a requisite user field - "userfield_delete": Delete a requisite user field (destructive)
fieldsNoRequisite fields: ENTITY_TYPE_ID, ENTITY_ID, PRESET_ID, NAME, RQ_INN, RQ_KPP, RQ_COMPANY_NAME, RQ_ADDRESS.
filterNoFilter object (e.g. { '>OPPORTUNITY': 10000, 'STAGE_ID': 'WON' })
selectNoArray of field names to return (projection)
confirmNoSet to true to confirm destructive actions when BX24_CONFIRM_DESTRUCTIVE is enabled.
presetIdNoRequisite preset ID
userfieldNoUser field definition
linkFieldsNoLink fields: ENTITY_TYPE_ID, ENTITY_ID, REQUISITE_ID
userfieldIdNoCRM userfield ID (e.g. UF_CRM_123)
bankdetailIdNoBank detail ID

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?

No annotations are provided, so the description carries the full disclosure burden. It only lists CRUD categories and REST method prefixes; it does not mention destructive side effects, permission requirements, rate limits, or system behavior after delete/update operations. The schema's action enum marks destructive actions, but that is structured data, not descriptive transparency.

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?

The description is compact and front-loads the resource name, but it reads as a keyword index rather than a structured explainer. The bilingual RU/EN tail adds search-surface value but no operational clarity.

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

Completeness3/5

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

The input schema is rich and the action enum documents each operation, so the description is not solely responsible for completeness. However, for a tool with 32 operations, nested objects, no output schema, and five sub-resources, the description lacks high-level selection criteria or usage examples to help an agent choose the right action confidently.

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 all 13 parameters and the action enum. The description adds no parameter-level meaning beyond naming the sub-resources, so the baseline of 3 is appropriate.

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 names the resource (Bitrix24 CRM requisites) and the operation families (CRUD, presets, bank details, links, user fields), which clearly separates it from sibling CRM tools. It stops short of a single crisp verb+object sentence, but the method groups are unambiguous.

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 guidance on when to use this tool versus alternatives like bx24_crm_companies or bx24_crm_contacts. The description implies it is for requisites, but it offers no scenarios, exclusions, or comparisons to related tools.

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