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

No annotations are present, so the description carries the full behavioral disclosure burden. It does disclose that earlier results can be referenced with $result[key], which implies ordered execution, and mentions REST 1.0 + 3.0 compatibility. However, it omits error behavior, partial failure semantics, response structure, and destructive-command concerns beyond what the schema already shows.

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

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

The core purpose is front-loaded in a single, clear sentence, followed by the key reference mechanism. The bilingual keyword list is somewhat redundant for an AI agent and could be trimmed, but it does not significantly bloat the description. Overall it is compact and efficient.

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

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

The description covers the essence of batching and the $result reference mechanism, and the schema fully documents cmd, halt, and confirm. However, with no output schema and no annotations, the agent is left without information about the batch response format or how execution failures are surfaced. For a generic execution wrapper, this is a notable gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds a concise general rule for referencing results ($result[key]) that complements the schema's example. Yet the schema already contains the same reference syntax, so the description provides only marginal additional parameter insight.

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

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

The description opens with a specific verb-resource pair: 'combine multiple REST calls into one request' and identifies the exact Bitrix24 method ('batch'). It clearly distinguishes this generic batching tool from the domain-specific sibling tools. The bilingual keyword list reinforces meaning rather than obscuring it.

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

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

The description implies the use case: use this tool when multiple REST calls need to be combined into a single request. However, it does not explicitly state when not to use it, which sibling should be chosen instead, or any prerequisites such as REST method compatibility. The hybrid RU/EN phrases add searchability but no direct usage exclusions.

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

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

With no annotations provided, the description carries the full burden, but it only lists topic areas and API versions. It does not mention side effects, permission requirements, event polling behavior, or destructive potential; the destructive hints appear only in the schema's action enum and confirm parameter, not in the narrative description.

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

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

The description is a single compact sentence that front-loads the resource and version, then lists functional areas. The RU/EN keyword list adds minor redundancy but remains short and does not undermine clarity.

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

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

This is a large multi-action tool with 15 parameters and no output schema, yet the description provides only a category list. It omits prerequisites such as a registered bot or client_id, how event_get polling works, and any return-shape or error context, leaving the detailed action enum to carry the operational weight.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with every parameter already documented, including detailed per-action semantics in the action enum. The tool description adds no parameter-level meaning, so the baseline of 3 applies.

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

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

The description clearly identifies the resource (Bitrix24 chat bots v2) and functional scope (bot registration, chats, messages, reactions, commands, files, events), and names the API family (imbot.v2.*). It is distinguishable from CRM/tasks/projects siblings, though it does not explicitly differentiate from the closely related bx24_im and bx24_im_chat tools.

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

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

The description gives no guidance on when to use this tool versus alternatives like bx24_im or bx24_im_chat, and mentions no exclusions, prerequisites, or selection criteria. The RU/EN keyword list aids search but does not help an agent decide between sibling tools.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only lists method namespaces and API versions and does not mention destructive operations, permission requirements, rate limits, or side effects. The schema's delete-action descriptions cover destructiveness, but the description itself lacks this context.

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

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

The description is compact and starts with the domain, but the RU/EN keyword block and the method namespace list partly duplicate the already-listed functional areas. It is not bloated, but it contains some redundancy that could be tightened.

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

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

For a tool with 17 parameters, 21 actions, no annotations, and no output schema, the description is only a high-level overview. It does not explain the action-driven dispatch model, which parameters apply to which actions, or how destructive actions should be confirmed. The rich action enum compensates partially, but the description alone is insufficient for reliable invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The tool description adds no parameter-level meaning beyond naming domains and the 'create event' keyword, which is already represented in the action enum. The schema itself provides adequate parameter documentation.

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

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

The description identifies Bitrix24 calendar as the resource and enumerates its functional domains: events, sections, meeting status, resources, accessibility, and settings. This distinguishes it from CRM, tasks, and other sibling tools. However, it is a broad namespace description rather than a single specific operation, so it stops short of full precision.

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

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

There is no explicit guidance on when to use this tool versus alternatives, and no mention of exclusions or sibling routing. The Bitrix24 calendar label implies calendar-related use, but with 21 possible actions the description does not help an agent decide which operation or when to prefer this tool over related ones.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It conveys a raw, passthrough nature ('invoke any REST method', 'arbitrary params') but does not mention response format, destructiveness, or the confirm parameter's role. The schema provides confirm details, but the description itself offers little safety or outcome context.

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

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

The core function and usage condition are stated in two front-loaded sentences. The RU/EN synonym list is compact and useful for multilingual intent matching without bloating the description.

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

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

For a universal 4-parameter tool with dynamic output, the description covers purpose and use-case routing well. It lacks an explicit note that responses are raw REST responses, which would be valuable since no output schema exists. Still, the schema covers all parameter semantics, making this mostly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description's 'arbitrary params' aligns with the schema but adds no meaning beyond the per-parameter descriptions already present.

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

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

The description states a specific verb and resource: 'invoke any REST method by name with arbitrary params'. It clearly brands itself as an 'escapade-hatch' and 'Universal Bitrix24 REST call', which distinguishes it from the dedicated sibling wrappers by scope.

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

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

The phrase 'Escape-hatch for methods not covered by dedicated tools' explicitly tells an agent when to use this tool and implies when not to use it. This provides a clear routing rule without needing to enumerate each sibling tool.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only mentions the domain and API version; it does not disclose that actions create, delete, join, or leave conferences, does not mention destructive side effects, permissions, or return behavior. This is a significant transparency gap.

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

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

The description is short and front-loaded with the domain. The RU/EN synonym list adds useful multilingual matching context without bloat, and the method family reference is compact. It is concise, though at the cost of omitting behavioral detail.

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

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

Given 9 parameters, six distinct actions, nested objects, and no output schema, the description is far too sparse. It does not cover what the tool actually does per action, what responses look like, when confirm is needed, or how this relates to other Bitrix24 communication tools. The schema fills some gaps, but the description leaves critical context unresolved.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description itself adds no parameter-level meaning beyond the schema, but the schema already thoroughly documents each parameter, including the action enum descriptions.

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

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

The description identifies the resource as 'Bitrix24 video conferences' and references the im.conference.* method family, but it never states a concrete verb like 'manage' or 'schedule'. The action enum in the schema provides the actual operations, so the description alone is only a vague domain label rather than a clear statement of what the tool does.

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

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 sibling tools such as bx24_call, bx24_im, bx24_im_chat, or bx24_calendar. The description implies 'conference' usage through synonyms, but it does not state exclusions, prerequisites, or alternatives, leaving selection to inference.

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

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

With no annotations provided, the description carries the full burden of disclosing behavioral traits, but it only names operations like CRUD and complete without explaining consequences, reversibility, permissions, or side effects. The schema marks some actions as destructive, but the description text itself does not disclose these traits beyond what the structured data already says.

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

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

The description is dense and front-loaded with the resource and operation families, but it is a single run-on paragraph that mixes keywords, method names, Russian/English phrases, and timeline subresources without clear structure. It is not bloated, but it lacks the organized readability that a tool with this many operations needs.

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

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

Given the tool's high complexity (60+ action enum values, 12 parameters, nested objects, no output schema, no annotations), the description is incomplete. It does not explain which parameters are required for specific actions, what responses look like, how ownerId/ownerTypeId relate to binding semantics, or how destructive actions are confirmed. An agent would still need to infer much of this from the schema alone.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the structured schema already documents all 12 parameters. The description adds no meaningful parameter semantics beyond the schema; the one contribution is mentioning fields like TYPE_ID and OWNER_TYPE_ID indirectly through broader method names, but that adds no extra value.

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

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

The description clearly identifies the resource as Bitrix24 CRM activities (дела/звонки/встречи/письма) and enumerates the major operation families: CRUD, complete, todo, configurable, types, badges, and timeline. It is specific enough that an agent can tell this tool is about CRM activities rather than, say, deals or tasks. However, it does not explicitly distinguish itself from siblings like bx24_crm_calllists or bx24_telephony, which could overlap in the calls domain.

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

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

The description implies usage for CRM activity management and lists method groups, but it does not state when to prefer this tool over alternatives or when not to use it. The action enum in the schema provides per-operation guidance, but the description itself gives no explicit when/when-not/alternative differentiation.

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

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

Since no annotations are provided, the description must carry the full burden of behavioral disclosure. It only states 'CRUD' and 'delete by filter' without describing permanence of deletions, permission requirements, side effects, or consequences of bulk delete. The destructive flags in the action enum are part of the schema, not the description.

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

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

The description is tight and front-loads the core purpose with a resource label followed by the operation summary. The REST version note and bilingual synonym list are small additions that aid retrieval without introducing significant bloat.

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

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

For a tool with 10 parameters, 8 actions, nested objects, and no output schema or annotations, the description is too thin. It omits operational details such as required fields for add, how byclient selects entities, and error or pagination behavior, leaving the schema to carry nearly all invocation-relevant context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds RU/EN synonym keywords and the REST method family, but it does not clarify parameter relationships, required-field rules for add, or how byclient parameters interact beyond what the parameter descriptions already cover.

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

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

The description clearly identifies the resource as Bitrix24 CRM addresses, enumerates the operation families (CRUD, by client, delete by filter), and names the underlying REST methods (crm.address.*, crm.address.byclient). This distinguishes it from sibling tools that target different CRM entities such as deals, leads, or products.

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

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

The description provides no explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. Usage context must be inferred entirely from the tool name and the word 'addresses', with no routing to or away from siblings like bx24_crm_requisites.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions trigger execution and app triggers but does not disclose that trigger_delete is destructive, whether authentication or entity context is needed, what side effects firing a trigger produces, or any rate-limit consequences. The action enum's 'destructive' flag exists in the schema, but the description itself adds little transparency.

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

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

The description is reasonably concise and front-loaded with the core domain ('CRM automation triggers') followed by method details. The RU/EN keyword list is somewhat redundant and does not add functional guidance, but it does not bloat the entry excessively. It remains compact given the tool's 9-parameter surface.

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

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

This is a moderately complex multi-action tool with 9 parameters, nested objects, and no output schema, yet the description does not explain how actions relate to parameters (e.g., which params are needed for trigger versus trigger_list), when confirmation is required, or how trigger codes are supplied. The schema covers parameter meanings, but the description fails to provide the decision-level context an agent needs to invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3 and the schema already documents each parameter including action meanings, filter examples, and pagination semantics. The description adds only general domain context and RU/EN synonyms rather than parameter-level enrichment, so it does not exceed the baseline.

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

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

The description identifies the resource as Bitrix24 CRM automation triggers and mentions the three modes: app triggers, execute, webhook trigger. It clearly separates this tool from entity-focused siblings like bx24_crm_deals or bx24_crm_contacts by naming the crm.automation.trigger.* method family. However, it lacks a single explicit verb stating what the tool does, relying on the action enum to convey behavior.

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

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

The description gives no guidance on when to use this tool versus alternatives, nor does it state conditions such as 'use for automation triggers only' or 'not for CRM entity operations.' The RU/EN keyword list helps searchability but does not help an agent decide between this tool and, for example, bx24_workflows or bx24_events.

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

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

No annotations are provided, so the description must disclose behavior itself. It only names operations and REST versions; it does not explain side effects, destructive outcomes, permission needs, or behavior of 'start' and 'status' beyond their names. The destructive nature of delete appears only in the schema, not the description.

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

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

The description is compact and front-loaded with the core resource and operations. The RU/EN synonym list is useful for multilingual lookup and does not add meaningful bloat. It is appropriately sized for a multi-action tool though it lacks depth.

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

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

Although the schema is rich and covers 100% of parameters, the description itself does not explain per-action required fields, expected responses, or operational details for a tool that multiplexes six distinct actions. With no output schema and no annotations, an agent is left without enough context to confidently invoke actions like add, start, or status.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the parameter descriptions already document id, order, start, action, fields, filter, select, and confirm. The tool description adds no parameter-level meaning, but the schema carries the burden, 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.

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

The description names a specific resource (Bitrix24 CRM call lists) and enumerates the concrete operations: create, list, get, delete, start, status. It also identifies the underlying REST method family crm.calllist.*, making it clearly distinguishable from sibling CRM tools.

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

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

The description lists operations but provides no guidance on when to choose this tool over alternatives such as bx24_call or bx24_telephony. It does not state prerequisites, exclusions, or scenarios where a different tool would be more appropriate.

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

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

With no annotations, the description carries the full burden of disclosing behavior. It mentions 'CRUD' generically, which implies mutation/deletion, but provides no details on destructive consequences, confirmation requirements, permissions, or side effects. The schema's action enum adds some destructive flags, but the description itself is insufficient.

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

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

The description is compact, using three short sentences. The first sentence establishes scope, the second maps to REST method families, and the third adds multilingual aliases. There is minor redundancy between 'CRUD, contact bindings, user fields' and the method list, but no fluff.

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

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

This is a high-complexity tool with 13 parameters, 19 enum values, nested objects, and no output schema. The description omits the details_get/details_set/details_reset actions entirely, does not explain return values or pagination, and leaves the agent to discover the full action set from the schema. The schema is rich, but the description alone is incomplete for the tool's breadth.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema documents all 13 parameters, including the action enum details and field examples. The description adds nothing about parameter usage beyond categorizing the tool; the RU/EN aliases are search aids, not parameter semantics. A baseline of 3 is appropriate because the schema carries the burden.

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

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

The description names the target resource (Bitrix24 CRM companies) and enumerates its operation areas: CRUD, contact bindings, and user fields. This clearly distinguishes it from sibling tools like bx24_crm_deals or bx24_crm_contacts, though it lacks a single specific verb because it aggregates many operations.

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

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

The scope is unambiguous: this is the tool for crm.company.* operations, including contact bindings and user fields. It gives clear context that company-specific CRUD and associated sub-resources belong here, but it does not explicitly tell the agent when NOT to use it or which sibling to prefer for related entity actions.

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

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

With no annotations, the description carries the full behavioral burden, but it only offers the broad labels 'CRUD' and 'company bindings'. It does not disclose that delete/unbind/clear actions are irreversible, that destructive actions may require a confirm flag, or what side effects or response shapes to expect. The destructive labels in the input schema help, but the description itself stays silent on these traits.

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

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

The description front-loads the resource and core capabilities in one compact sentence, then adds method-group and locale hints. The RU/EN keyword fragment adds modest value for multilingual queries but is slightly tangential; overall the text is efficient and appropriately sized.

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

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

The 13-parameter/18-action surface is complex, and the high-level description alone would not be enough. The rich input schema compensates for most gaps, but with no output schema and no return-value description, an agent must infer response shapes from action names and the fields object. That leaves a noticeable but not critical gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema coverage is 100%, so the baseline of 3 applies; the description contributes no parameter-level detail. The schema's action enum and field descriptions carry the semantics, which is adequate.

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

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

The description names the exact Bitrix24 resource ('CRM contacts') and lists the operation families it covers: CRUD, company bindings, and user fields. This distinguishes it from siblings like bx24_crm_deals and bx24_crm_companies and maps directly to the crm.contact.* REST method groups.

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

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

Usage is implied by the resource name and operation families: it is the tool for contact-related actions. However, it never explicitly states when to use it versus sibling tools or which sibling covers adjacent entities (e.g., bx24_crm_companies for company-only operations), so the guidance is implicit rather than prescriptive.

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

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

With no annotations provided, the description must carry the full behavioral disclosure burden. It only says 'CRUD, base currency, localizations' and lists REST method groups, but does not disclose consequences of destructive operations, permission requirements, side effects of setting the base currency, or typical response behavior. The confirm parameter and destructive hints live only in the schema, not in the tool description.

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

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

The description is compact, front-loaded with the resource and capability set, and avoids excessive detail. The RU/EN translation line adds mild redundancy but does not seriously bloat the text. It earns high marks for being brief and scannable.

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

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

For a tool with 9 parameters, no output schema, no annotations, and multiple operation families, the description is too sparse to be fully actionable. It does not explain how actions relate to each other, what the base currency/localization operations return, or how pagination and confirm work. The schema covers parameter semantics, but the higher-level workflow context is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the input schema already documents all parameters, including a detailed action enum. The description adds no param-level meaning beyond naming the method groups, which is acceptable given the schema's completeness. A baseline of 3 is appropriate.

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

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

The description names the resource (Bitrix24 CRM currencies) and the main capabilities: CRUD, base currency, and localizations. It also references the corresponding REST method groups, which distinguishes it from sibling tools focused on other CRM entities. However, it doesn't provide a crisp single-verb statement of what the tool does or how these operations behave.

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

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

The description implies the tool is for currency management but gives no explicit guidance about when to use it versus other tools, nor when to choose specific actions like get versus list or localizations versus base currency. It lacks any context about prerequisites or scenarios where an alternative approach would be preferable.

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

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

No annotations are present, so the description carries the full burden. It only labels operations as 'CRUD' and lists feature areas; it does not disclose that many bundled actions (delete, setProductRows, contact_items_delete, category_delete, etc.) are destructive or that some actions overwrite data. The agent cannot predict side effects or confirmation requirements from the description alone.

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

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

Two dense sentences with the resource front-loaded and the capability list kept compact. The RU/EN trigger list is useful for matching user intent rather than filler, though the long comma-separated lists make it slightly less scannable than it could be.

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

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

For a 35-action, 18-parameter tool with no annotations and no output schema, this is a minimal-but-adequate orientation: it names the domain, method families, and sample intents while leaving action semantics to the detailed schema. Gaps remain around destructive behavior, output shape, and the relationship between categories and stages, but the rich schema compensates substantially.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All 18 parameters have schema descriptions (100% coverage), so the description is not required to repeat them. It adds high-level domain context (product rows, contact bindings) and multilingual task vocabulary, but no parameter-level detail beyond what the schema already provides.

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

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

The description names the specific resource ('Bitrix24 CRM deals') and enumerates capability areas: CRUD, funnels/categories, product rows, contact bindings, timeline. The method-family list and multilingual task phrases make it easy to distinguish from siblings like bx24_crm_contacts or bx24_crm_products.

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

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

The trigger phrases ('create deal, find deals, move stage, close deal, product rows') imply common use cases, but there is no explicit when-to-use vs alternatives or when-not-to-use guidance. An agent must infer deal-related usage from the name and domain list rather than being told when this tool beats a sibling.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions REST versions and the general domain but does not disclose destructive behavior, authentication/token requirements, rate limits, or side effects. Some destructive actions are labeled in the schema's action enum, but the description itself adds little behavioral transparency.

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

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

The description is short and front-loaded with the core purpose. The bilingual RU/EN note is useful for matching Russian user language and does not add excessive length. Some repetition of 'document' occurs, but the overall structure is compact and scannable.

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

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

This is a large, multi-action tool with 14 parameters and no output schema, yet the description provides only a high-level summary. It lacks guidance on how parameters combine, which actions require tokens, expected return shapes, or common workflows. The schema's action descriptions help, but the description itself is not complete enough for such a complex tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description does not add parameter-level meaning beyond the schema, but it does provide a high-level vocabulary that maps to parameter groups (templates, documents, numerators, bindings, providers). The schema already documents each parameter, including the detailed action enum.

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

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

The description clearly identifies the tool as a Bitrix24 CRM document generator and enumerates its main object groups: templates, documents, numerators, bindings, providers. It also ties it to the crm.documentgenerator.* method namespace. However, it does not explicitly distinguish itself from sibling tools like bx24_crm_invoices or bx24_crm_workflows.

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

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 such as bx24_crm_invoices or bx24_disk. The description implies the domain (document generation) but provides no conditions, prerequisites, or exclusions. The action enum in the schema contains operation details, but the description itself offers no usage direction.

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

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.

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.

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.

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.

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.

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.

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the method families (crm.item.*, crm.status.*), the injected entityTypeId=31, and the REST versions, which gives useful operational context. It does not reveal side effects, permissions, reversibility, or what happens on destructive actions, though the schema's 'confirm' parameter partially covers destructive actions.

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

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

The description is compact and front-loaded with the entity and capability summary. Each sentence provides distinct value: domain, operations, technical method mapping, and multilingual search terms. The RU/EN list adds a bit of redundancy but is short and useful for Bitrix24's user base.

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

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

For a complex 10-parameter, 10-action tool with no output schema, the description provides a good orientation but not full operational completeness. It covers the main operation categories and technical context, yet lacks examples, response/return behavior, error conditions, and explicit guidance on combining actions like fields and product-rows operations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already explains all parameters. The description adds some higher-level context about underlying API methods and REST versions, but it does not meaningfully clarify individual parameter semantics beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description clearly identifies the resource (Bitrix24 CRM invoices / SMART_INVOICE) and the scope of operations: CRUD, stages, and product rows. It distinguishes the tool from other CRM siblings by naming the invoice entity and the underlying methods crm.item.*. However, it is a multi-action wrapper rather than a single specific verb, so it does not define one crisp operation.

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

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

The description implies this tool is for invoice-related operations, product rows, and stage handling, and it provides Russian/English terms that help route queries. It does not explicitly state when to prefer this tool over alternatives or when not to use it, so the guidance is mostly inferred from the tool name and entity type.

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

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

No annotations are provided, so the description carries the full behavioral-transparency burden. It only states API method families and REST versions, without disclosing auth needs, rate limits, irreversibility, or confirmation behavior. The schema's action enum marks some actions as 'destructive', but the description itself adds no such context.

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

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

The description is compact and front-loaded with the resource and scope. The RU/EN synonym list adds length but serves multilingual query matching. No redundant filler, though the synonym list is slightly more than strictly necessary.

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

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

The description provides a broad overview but omits several action families present in the schema, such as productrows_*, details_*, and convert. With 14 parameters and 21 actions, the top-level description is thin. However, the schema itself is extensively detailed with 100% coverage, so the combination is mostly adequate for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description itself adds no parameter-level meaning; it merely lists categories. The detailed action and parameter descriptions reside in the schema, which already documents all parameters thoroughly.

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

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

The description clearly identifies the resource ('Bitrix24 CRM leads') and the main capability areas ('CRUD, fields, contacts, user fields'). This distinguishes it from sibling CRM tools at a glance, though it is an umbrella for many actions rather than a single specific operation.

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

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

The description gives no explicit when-to-use guidance or alternative tool exclusions. It does not reference sibling tools such as bx24_crm_deals or bx24_crm_contacts. The only usage hint ('call first when unsure') lives inside the schema's action enum for 'fields', not in the description.

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

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

No annotations are provided, so the description itself carries the behavioral disclosure burden. The top-level description only lists entity domains and REST versions; it does not state that operations range from reads to destructive deletes, that document conduct/cancel changes inventory state, or that confirmations may be required. Some destructive cues exist inside the action enum descriptions in the schema, but the tool description itself does not provide this transparency.

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

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

The description is a fairly dense list of trade-catalog entities and RU/EN keyword synonyms, followed by the method-family note. It front-loads the domain but reads more like a tag cloud than a concise behavioral summary; the keyword block, while useful for search, adds length without operational guidance.

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

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

This is a high-complexity, multi-action tool with 24 parameters, over 100 possible actions, nested objects, and no output schema or annotations. The description identifies what domain it covers but does not explain the action-selection pattern, shared parameter behavior, return shapes, error conditions, or side-effect semantics. The schema helps, but the tool-level description is not complete enough for an agent to invoke it confidently across its many actions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so every parameter has some documentation, and the `action` enum includes unusually detailed per-operation descriptions, including destructive flags and required fields like 'NAME required' for product_add. The main description adds no extra parameter-level meaning beyond naming the domain, so the baseline score of 3 is appropriate.

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

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

The description clearly identifies the resource domain: 'Bitrix24 trade catalog' and enumerates the managed entity types (products, sections, prices, stores, offers, SKUs, etc.). It also names the API family, 'Methods catalog.*', which distinguishes it from CRM modules like leads, deals, and contacts, though it does not explicitly name a sibling alternative.

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

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

The description implies when to use the tool: any trade-catalog operation involving the listed entities and catalog.* REST methods. However, it does not explicitly state when not to use it, how it relates to siblings, or prerequisites such as catalog setup or permissions.

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

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

With no annotations, the description carries the full behavioral disclosure burden, but it only lists operation categories like 'CRUD' and product rows. It does not mention that quotes can be deleted, that product rows may be fully overwritten, or that contact unbinding is destructive; the schema's action enum flags some actions as destructive, but the top-level description itself lacks this transparency.

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

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

The description is a single dense sentence with no filler. It front-loads the resource and operation families, then adds API method names and multilingual terms, all of which are useful for an agent; every element earns its place.

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

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

This is a complex 13-parameter, 16-action tool with no annotations and no output schema, yet the description only summarizes scope. It omits return-value expectations, prerequisites for actions, side-effect ordering, and how to choose among the many embedded actions, leaving substantial context for the agent to infer from the schema alone.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema description coverage is 100%, so the baseline is 3; every parameter already has a meaningful description. The tool description adds only high-level domain context and does not enhance parameter semantics beyond what the schema provides.

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

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

The description clearly identifies a specific resource (Bitrix24 CRM quotes) and enumerates the operation families: CRUD, product rows, contact bindings, and user fields. It also names the corresponding API method groups, making the tool's scope unmistakable and distinct from sibling CRM tools like deals, contacts, or invoices.

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

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

The description provides no guidance on when to use this tool versus the many sibling CRM tools, such as bx24_crm_deals or bx24_crm_invoices. Usage context is only implied through the word 'quotes' and the listed method families; there are no exclusions or alternative tool references.

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

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.

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.

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.

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.

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.

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.

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

With no annotations, the description carries the full behavioral burden, but it only names methods and REST versions. It does not disclose read-only behavior, pagination semantics, required entity context, response characteristics, or differences between REST 1.0 and 3.0.

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

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

The description is compact and front-loaded with the tool's purpose and method namespace. However, the final RU/EN synonym list is largely redundant, repeating 'stage history' and adding terms that do not materially help an agent select or invoke the tool.

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

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

This is a multi-action tool with nested objects, no output schema, and no annotations, so the description is under-specified. An agent can infer the basic domain but gets no guidance on return shapes, filtering prerequisites, action-specific parameter relationships, or API-version behavioral differences.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already documents all 8 parameters with 100% coverage, so the baseline of 3 applies. The description adds no parameter-level meaning beyond what is already in the schema and action enum.

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

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

Clearly identifies the resource as Bitrix24 CRM stage history and enumerates supported operations (list, get, fields), which aligns with the action enum. It does not explicitly contrast with sibling tools like crm_deals or crm_automation, but the resource scope is specific enough.

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

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

No explicit guidance on when to use this tool versus alternatives such as crm_deals or crm_automation. The bilingual labels ('funnel movement, deal history') imply stage-history use cases, but there are no clear conditions, exclusions, or routing hints.

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

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

With no annotations provided, the description carries the full behavioral disclosure burden. It transparently reveals that the tool performs aggregation across multiple CRM entities and returns counts, lead statuses, and deal funnels in a single call, including the REST version support. However, it does not disclose response format details, whether counts are live or approximate, or any limits, which are relevant for a zero-parameter aggregate tool.

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

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

The opening sentence is clear and front-loaded with the essential behavior: aggregate CRM counts plus statuses and funnels. However, the RU/EN bilingual section largely repeats the same information, adding length without new substance for an English-language agent. It is not egregiously verbose, but the redundancy prevents a higher score.

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

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

For a zero-parameter summary tool with no output schema, the description covers the essential contextual information: what data is summarized, that it includes statuses and funnels, and that it is a one-call operation. Sibling tools make the alternative paths obvious. It does not document exact response fields, but that is less critical given the simple, self-contained nature of the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has zero parameters with 100% schema description coverage, so there are no parameter semantics to document. The description appropriately explains what the no-parameter call returns, which is sufficient. A baseline of 4 is appropriate here because the description compensates for the lack of any parameter detail by defining the tool's output focus.

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

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

The description states a clear resource ('Bitrix24 CRM summary') and specifies what it provides: total counts of leads, deals, contacts, companies, plus lead statuses and deal funnels. It is distinguishable from sibling entity-specific tools like bx24_crm_leads or bx24_crm_deals because it explicitly emphasizes aggregate summary data. It lacks a strong imperative verb like 'gets' or 'returns', but the intent is unmistakable.

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

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

The description implies this tool is for high-level CRM overviews ('total counts', 'summary', 'in one call'), which suggests using it instead of querying individual CRM entity tools. However, it does not explicitly state when to use it versus alternatives such as bx24_crm_leads or bx24_crm_deals, nor does it mention exclusions like 'for detailed lists use the entity-specific tools'. Usage context is implied but not fully articulated.

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

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

With no annotations, the description carries the full burden of behavioral disclosure, but it only lists resource categories and REST versions. It does not mention mutation risks, reverseability, pagination behavior, authentication requirements, side effects, or result shapes; destructive operations are only hinted at in the input schema's action descriptions, not in the main description.

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

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

The description is short and front-loaded with the main scope, but the RU/EN keyword list near the end adds repetitive filler rather than substantive structure. It is concise but not every token earns its place.

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

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

This is a complex multi-action tool with ten actions, nested object parameters, no output schema, and no annotations, yet the description provides only a general scope and method names. It lacks an overview of the entities' relationships, operation grouping, or any usage context that would let an agent select and invoke actions correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 nine parameters and the action enum. The description adds no parameter-level meaning beyond what is available in the schema, which matches the baseline of 3.

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

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

The description clearly identifies the CRM tracking domain (traces, sources, channels) and lists the resource method groups crm.tracking.trace.*, crm.tracking.source.*, and crm.tracking.channel.*, making the tool's scope understandable. It is not a tautology and is distinguishable from the sibling tools by its tracking focus, though it lacks a single strong verb-and-resource statement.

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

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, no exclusions, and no mention of what situations require this tool instead of, say, bx24_crm_deals or bx24_crm_contacts. The method list implies coverage but does not help an agent decide which operation is appropriate.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. The term 'CRUD' hints at mutations and deletion, but the description does not disclose destructive side effects, permissions, irreversibility, or other behavioral traits. It leaves important safety context to the action enum descriptions rather than the tool description.

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

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

The description is compact and front-loads the core resource and operation families. The RU/EN synonym list adds some redundancy but may help match user intent in different languages. Overall, it is concise without being underspecified at the topic level.

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

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

Despite having a rich action enum and full schema coverage, the tool lacks an output schema and annotations. The description does not explain return values, pagination behavior, destructive-action confirmation, or the REST 1.0 vs 3.0 implications. For a tool with this many operation families, the description alone is not enough for confident invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3 even though the tool description itself adds no parameter-level meaning. The inline action descriptions in the schema effectively document the 16 operations, so the agent has enough parameter context, but the top-level description contributes nothing extra.

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

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

The description clearly identifies the resource as Bitrix24 CRM webforms plus their results and options, and names the API method families (crm.webform.*, crm.webform.result.*, crm.webform.option.*). It is specific enough to distinguish from sibling CRM entity tools, though it does not explicitly contrast itself with any sibling.

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

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

The description states what the tool covers but provides no guidance on when to choose it over alternatives, nor when not to use it. There is no mention of prerequisites, preferred use cases, or exclusions that would help an agent decide between this tool and the many sibling CRM tools.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure, but it only labels the tool as CRUD + IM info. It does not mention that delete is destructive, what pagination/start implies, permission requirements, REST version differences, or what responses look like. The destructive nature of 'delete' is only visible in the schema, not the description.

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

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

The description is compact and front-loaded with the core purpose, then adds the method namespaces and useful RU/EN search terms. Every part contributes either scoping or retrieval value, though the string of slash-separated terms at the end feels slightly terse rather than fully structured.

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

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

With 8 parameters, nested objects, no annotations, and no output schema, this description is only a high-level stub. It does not explain operation-specific caveats, response shapes, destructive-action confirmations, or how REST 1.0 and 3.0 differ, leaving an agent undersupplied for reliable invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3; the description adds no parameter-level meaning beyond what the schema already provides. The action enum gives useful semantics for most actions, though 'get_all' is confusingly described as 'Describe department fields' in the schema, and the description does not resolve this ambiguity.

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

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

The description clearly identifies Bitrix24 departments/org structure as the resource and states the operation family (CRUD + IM department info). It also gives the relevant method namespaces (department.*, im.department.*), which helps distinguish it from the many CRM/task/user siblings, though it doesn't explicitly contrast it with related tools like bx24_users or bx24_hr.

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

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, nor when to choose one action over another (e.g., get vs list vs get_all). The only usage signal is implicit in the action enum, and the description does not state conditions, prerequisites, or exclusions.

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

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

No annotations are provided, so the description carries the behavioral disclosure burden, but it does not mention side effects, reversibility, permissions, rate limits, or response behavior. The RU/EN keyword list hints at operations like upload, download, and external links, but it gives no warning about destructive actions such as folder/file deletion; the schema's own '(destructive)' labels are structured data, not description credit.

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

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

The description is compact and starts with the core domain, but the method-family list and the RU/EN keyword dump are somewhat redundant and unstructured. It is not bloated, yet the trailing bilingual list does not earn its place as clearly as the opening scope sentence.

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

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

For a large multi-operation tool with 38 actions, 15 parameters, no annotations, and no output schema, the description is too thin. It omits cross-cutting operational context such as return-value expectations, authentication or permission considerations, and explicit guidance on destructive operations. The schema compensates for per-action detail, but the description alone leaves significant top-level gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline of 3 applies; all 15 parameters already have meaningful descriptions. The description's RU/EN vocabulary adds high-level search terms but no parameter-specific semantics beyond what the schema provides.

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

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

The description clearly identifies the Bitrix24 Disk domain and lists the entity types it covers: storages, folders, files, versions, and external links. It also names the method families (disk.storage.*, disk.folder.*, disk.file.*, etc.), which distinguishes this from sibling CRM, tasks, and IM tools, though it lacks a single direct verb like 'manage' or 'access'.

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

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

There is no explicit statement of when to use this tool versus alternatives, but the method-family listing makes the intended scope reasonably clear: any Bitrix24 Disk storage/folder/file/version operation belongs here. The guidance is implied rather than stated, and no sibling disk tool is mentioned for exclusion.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it does not address destructive actions, confirmation requirements, authentication needs, rate limits, or side effects. It only lists method names and REST versions. The schema action descriptions mention destructive operations, but the natural-language description itself is behaviorally thin.

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

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

The first sentence is compact and front-loaded with the core purpose. However, the second sentence is a redundant RU/EN keyword list that repeats information already present in the first sentence, adding noise without meaningful guidance. It is not badly structured, but it is not maximally efficient.

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

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

This is a broad multi-action tool with 9 parameters, nested objects, no output schema, and no annotations, so the description alone is insufficient for an agent to call it correctly. It does not enumerate the full set of possible actions, explain destructive confirmations, or clarify return/offline-queue behavior. The agent must rely heavily on the schema to fill the gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, so the parameter semantics are already well documented. The description adds no parameter-level detail beyond listing method names, which mirrors the action enum. A baseline of 3 is appropriate because the schema does the heavy lifting.

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

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

The description clearly identifies the tool's domain: Bitrix24 event subscriptions and the offline queue. It names the concrete methods (event.bind, event.get, event.unbind, event.offline.*) and therefore gives an agent an immediate, specific sense of what the tool does. This also distinguishes it from the many CRM/module siblings.

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

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

The description implies that this tool is for event subscription management and offline queue operations, but it gives no explicit when-to-use guidance or exclusions relative to alternatives. Sibling tools are not event-focused, so there is no direct replacement to contrast, but the description still does not state conditions for choosing one action over another.

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

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

With no annotations, the description carries the behavioral burden. It discloses that the tool verifies connectivity, credentials, and response time, and mentions the REST versions involved. As a no-parameter health check, this is sufficient behavioral transparency, though it does not describe the exact response format.

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

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

The description is compact and front-loaded with the core purpose. The bilingual RU/EN aliases are useful for matching varied user intent without adding verbosity.

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

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

For a no-parameter health-check tool, the description provides enough context for an agent to invoke it correctly. It does not detail the return structure, but the absence of an output schema and parameters lowers the need for that detail.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters and the schema is empty, so there are no parameter semantics for the description to clarify. The baseline of 4 applies because there is nothing for the description to compensate for.

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

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

The description names a specific verb and resource: 'verify API connectivity, credentials, and measure response time.' It clearly differentiates this health-check tool from all the CRM, task, and communication sibling tools, which operate on specific Bitrix24 entities.

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

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

The description provides clear context for when to use the tool: to check connection, API status, credentials, or ping. It does not explicitly mention when not to use it, but the diagnostic intent is unambiguous and no alternative tool is a plausible substitute.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, but it only lists methods and bilingual keywords. It does not mention that actions like dismiss or transfer are mutating, that confirmations may be required, or what side effects these operations have.

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

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

The description is compact and front-loaded with the tool's domain: 'Bitrix24 HR: employees + invitations.' The RU/EN keyword list adds useful multilingual searchability with only modest overhead, though the fragment style is slightly informal.

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

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

For a tool with 9 parameters, nested objects, no annotations, and no output schema, this description is too thin. It does not explain prerequisites, response shapes, or the operational differences between actions sufficiently, leaving the agent dependent on the schema for most invocation decisions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% parameter coverage, including detailed descriptions of each action in the enum, so the description need not repeat parameter-level semantics. The main description adds no additional parameter meaning, which is acceptable given the schema's completeness.

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

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

The description states a clear scope: Bitrix24 HR, employees, and invitations, and names the underlying methods (humanresources.employee.*, user.add/update). However, it does not explicitly distinguish itself from sibling tools like bx24_users, and the overlap with user.add/update makes the boundary less sharp.

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

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 such as bx24_users or bx24_departments. The phrase 'employees + invitations' implies a context, but the description never states exclusions, prerequisites, or when a sibling tool would be more appropriate.

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

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

No annotations are provided, so the description carries the full burden of disclosing side effects, authentication needs, and destructive behavior. The tool description only lists categories and method groups; it never mentions that some actions are destructive, that confirmation may be required, or what side effects occur. The schema's action enum contains some 'destructive' labels, but the description itself provides no behavioral transparency.

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

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

The description is compact, front-loads the core domain ('Bitrix24 messenger'), and then lists the method groups and multilingual keywords. It avoids excessive prose. The RU/EN translation block is somewhat redundant but does not significantly harm conciseness.

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

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

This is a high-complexity tool with 19 parameters, 50+ action enum values, nested objects, and no output schema, but the description provides only a broad category list and method group names. It lacks return-value expectations, usage context, destructive-action warnings, authentication notes, or any guidance that would help an agent safely invoke the right action.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so parameters are already documented in the input schema. The tool description adds no per-parameter meaning beyond the schema, but because the schema is thorough, the baseline score of 3 is appropriate.

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

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

The description clearly identifies the resource as the Bitrix24 messenger and enumerates its domains: messages, notifications, user info, search, counters, recent. It is specific enough to separate this tool from CRM, tasks, and disk siblings, though it does not explicitly differentiate from the closely related bx24_im_chat sibling.

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

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

The description implies use for Bitrix24 IM operations by naming message, notify, user, search, counters, and recent methods, but it gives no explicit guidance about when to prefer this tool over bx24_im_chat, bx24_bots, bx24_users, or bx24_departments. There are no exclusions or alternative-routing hints.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only lists capabilities and API method families, without mentioning that some actions are destructive, require confirmation, or have other side effects. The schema's action enum flags destructive actions, but the description itself does not reinforce this.

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

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

The description is a single compact sentence that front-loads the main feature areas and API method families. The RU/EN search-alias tail adds some redundancy but does not substantially hurt readability.

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

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

This is a complex multi-action tool with 15 parameters, nested objects, no annotations, and no output schema. The description is too thin to fully orient an agent: it omits when to use the tool, how destructive actions are handled, and what callers should expect in return.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the input schema already documents all 15 parameters. The description adds no new parameter-level meaning beyond the action list, which matches the schema's action enum descriptions. Baseline 3 is appropriate.

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

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

The description clearly identifies the tool as managing Bitrix24 chats and lists the major operations: create, members, owner, title/color/avatar, mute, messages, and counters. It is distinguishable from siblings like bx24_im by focusing specifically on chat operations, though it lacks a single explicit verb phrase like 'Manage Bitrix24 chats.'

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

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

The description provides no guidance on when to use this tool versus alternatives such as bx24_im or bx24_openlines. It does not state exclusions, prerequisites, or conditions that would route an agent to a sibling tool.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses only REST 1.0 + 3.0 support and domain terminology; it does not mention destructive operations (four of the twenty actions delete data), side effects, authentication needs, or pagination/limit behavior. The destructive flags and the confirm mechanism appear only in the schema's action enum, not in the description — so the description itself fails to convey the tool's safety profile.

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

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

The description is compact — two substantive sentences plus a bilingual glossary — with the domain and method families front-loaded. The 'REST 1.0 + 3.0' note is valuable context, and the RU/EN term mapping earns its place given Bitrix24's bilingual user base. It loses one point because the glossary line is slightly redundant with the first sentence and could be tightened, but overall there is no wasted prose.

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

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

This is a high-complexity tool — 14 parameters, 20 actions, nested objects, no output schema, and no annotations — yet the description only names the domain and REST versions. The rich action enum in the schema compensates substantially, but the description leaves unaddressed: what the operations return, how lists relate to fields/elements/sections, and any practical call patterns. It is minimally viable for an agent to select the tool, thanks largely to the schema, but not complete on its own.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3; the schema already documents all 14 parameters, including per-action semantics in the action enum and the purpose of confirm, filter, order, and select. The description itself adds no parameter-level meaning — it only names resource families. It neither compensates for gaps (there are none) nor elevates understanding beyond the schema, so the baseline 3 is appropriate.

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

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

The description identifies the resource domain precisely: Bitrix24 universal lists (infoblocks) with their sub-entities — lists, fields, elements, sections — and names the method families (lists.*, lists.element.*, lists.field.*, lists.section.*). This clearly distinguishes it from the CRM-entity siblings (bx24_crm_leads, bx24_crm_deals, etc.). It stops short of a 5 because it enumerates resources rather than stating a crisp verb+resource action, and the RU/EN glossary, while helpful, is not a purpose statement.

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

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

Usage context is implied by the domain wording: an agent facing a request about Bitrix24 lists/infoblocks should select this tool, while CRM-entity requests route to the bx24_crm_* siblings. However, there is no explicit when-to-use guidance, no named alternatives, and no exclusions such as 'for CRM entities use bx24_crm_* instead.' The guidance is adequate but left entirely to inference.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention side effects, destructive actions, permission requirements, rate limits, or response behavior. Some destructive actions are marked in the input schema's action enum, but the tool description itself adds little behavioral transparency beyond listing methods.

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

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

The description is short and front-loaded with the mail domain, then lists method families and useful RU/EN keywords. It avoids verbose prose and is appropriately sized for a tool that delegates specifics to the action enum. The method list is slightly redundant with the schema but not harmful.

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

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

This is a complex tool with 13 parameters, 39 enumerated actions, nested objects, and no output schema or annotations. The description only names the domain and method families; it does not explain common workflows, prerequisites, destructive-operation confirmation, or response/return expectations. An agent would need to rely heavily on the schema to use it safely and correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 adequately. The description adds no parameter-level meaning beyond naming the method families. Baseline 3 is appropriate because the description does not need to compensate for schema gaps.

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

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

The description identifies the Bitrix24 mail domain and the resource families it covers (mailboxes, messages, recipients, mail services, filters) and lists core operations like send, reply, and forward. It is less a single verb+resource statement and more a domain label, but it clearly distinguishes bx24_mail from CRM, tasks, disk, and IM sibling tools.

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

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

The description establishes clear context: use this tool for Bitrix24 mail operations such as mailboxes, messages, sending, replying, forwarding, filters, and recipients. It does not explicitly state when not to use it or name alternatives, but the sibling set is strongly domain-separated, so the mail scope is sufficient for tool selection.

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

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

With no annotations, the description carries the full behavioral burden, yet it only lists method names and resources. It does not disclose side effects such as email sending, potential destructive segment operations, or confirmation/authorization requirements.

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

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

The description is reasonably short but reads as a keyword dump rather than structured prose, and the bilingual RU/EN list adds length without much operational value. The core capabilities are front-loaded, so it is still serviceable.

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

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

This is a multi-action tool with 10 parameters and no output schema or annotations, but the description does not map actions to their relevant parameters, prerequisites, or return behavior. The schema's enum explanations help, but the description leaves important invocation context to be reverse-engineered.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the input schema already documents all 10 parameters and the action enum. The tool description adds no parameter-level meaning, keeping this at the baseline for well-covered schemas.

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

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

The description clearly enumerates the tool's domain and capabilities: segments from CRM, broadcast send, lead filtering, and trade platforms, and it names the underlying Bitrix24 REST methods. It is more than a tautology, though it does not explicitly distinguish itself from overlapping siblings such as bx24_mail or bx24_crm_leads.

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

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

The phrase 'Bitrix24 marketing' and the listed operations imply when the tool is appropriate, but there are no explicit when/when-not statements or alternatives. An agent must infer that this is the marketing-focused counterpart to general mail and CRM lead tools.

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

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

There are no annotations, so the description carries the full burden of behavioral disclosure. It does not mention side effects, write operations, permissions, rate limits, or state changes, even though actions like config_add, config_update, network_join, and crm_lead_create are clearly mutating. The phrase 'Methods imopenlines.*' identifies an API family but not the behavioral consequences.

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

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

The description is short and front-loads the core domain. The RU/EN terminology mapping adds marginal value but is not excessive. It reads as a compact overview rather than an explanation, though no sentence is wasted.

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

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

This is a 12-action tool with nested objects and no output schema, yet the description offers no workflow context, return-value hints, or operation-specific guidance. The input schema documents each parameter, but the description does not help an agent reason about how actions differ, which parameters apply to which action, or what results to expect.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and every parameter already has a meaningful description, so the baseline is 3. The tool description itself adds no parameter-level detail beyond what the schema already provides. There is no need for the description to compensate here.

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

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

The description identifies the Bitrix24 IM open lines subsystem and lists its main subdomains (configs, sessions, dialogs, operators, CRM links, network), which is clear and distinct from general IM or CRM tools. It lacks a single specific verb+resource, but the action enum provides concrete operation names. It does not explicitly contrast itself with siblings like bx24_im or bx24_im_chat, though the domain is reasonably clear.

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

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

No guidance is given about when to use this tool versus related alternatives such as bx24_im, bx24_im_chat, or the CRM tools. The domain label 'IM open lines' implies a particular context, but there are no stated exclusions, prerequisites, or selection criteria. The action enum lists operations, but the description does not explain which scenario maps to which tool.

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

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

There are no annotations, so the description carries the full burden of behavioral disclosure, but it only lists capabilities and REST namespaces. It does not mention that some actions are destructive, that deletes remove groups/members, that confirm may be required, or what side effects or permission requirements exist. The schema hints at destructive actions, but the description itself is thin.

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

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

The description is compact and front-loads the main resource and capabilities before adding REST method namespaces and RU/EN search keywords. It is not bloated, though the RU/EN keyword list is somewhat scattershot rather than a crisp one-line definition.

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

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

This is a complex tool with 14 parameters, 17 enum actions, nested objects, and no output schema, yet the description only gives a high-level capability summary and method families. Important context is missing: which actions are destructive, how to interpret responses, relationship between groups and projects, and when member/subject/feature actions apply.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and each parameter has a clear description, so the schema already does the heavy lifting. The description adds little parameter-level meaning beyond saying 'members, owner, features', which is enough to set context but not required given the strong schema.

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

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

The description names the resource (Bitrix24 groups/projects) and the broad capabilities (CRUD, members, owner, features), so an agent can tell this tool is for project/group management rather than CRM or tasks. It is not a single verb+object sentence, but it conveys the domain and scope clearly.

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

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

The description provides no guidance on when to use this tool versus alternatives, no exclusions, and no selection criteria among the many actions. It mentions underlying REST method families but does not explain how an agent should choose among create/get/list/update/delete or member/feature operations.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It does mention underlying REST methods and aggregations, which hints at read-style behavior, but it does not explicitly state that the tool is read-only, how results are grouped/returned, whether destructive actions are possible, or any rate-limit/error behavior. This is insufficient for a tool with no annotation support.

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

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

The description is compact and front-loaded with the core purpose, followed by report types, underlying methods, and multilingual keywords. The RU/EN keyword list adds some value for multilingual user queries, though it is slightly repetitive; overall it is concise and not padded.

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

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

This is a multi-action reporting tool with seven parameters, no annotations, and no output schema, yet the description does not explain return shapes, pagination behavior, or how to choose among the six actions beyond what the schema already says. An agent would still face significant uncertainty about what to expect from a call, especially for aggregation results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 seven parameters, including the action enum and filter/order/select examples. The description adds little beyond naming the report categories that map to action values, so the baseline 3 is appropriate.

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

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

The description opens with 'Bitrix24 analytics & reports' and enumerates six concrete report types (deal pipeline, lead sources, user activity, task completion, deal conversion, funnel stages), making the tool's purpose clear. It distinguishes itself from generic CRM/task sibling tools by emphasizing analytics and aggregation, though it does not explicitly name a sibling.

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

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

Usage is implied through the report-type vocabulary: an agent can infer this tool is for analytical/reporting questions rather than raw CRUD operations. However, there is no explicit guidance about when to use this tool over siblings like bx24_crm_deals or bx24_tasks, nor any 'when not to use' or alternative selection criteria.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states that the tool supports CRUD operations, which implies mutation, but it does not warn about destructive actions like deletes, does not mention permissions or authentication needs, and provides no information about rate limits or side effects. The mention of REST 1.0 + 3.0 adds technical context but not behavioral transparency.

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

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

The description is compact and front-loaded, immediately stating the tool's scope and operation families. The bilingual keyword list is useful for retrieval and does not introduce fluff or redundancy. Every part of the description earns its place.

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

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

Given that the tool is complex (10 parameters, nested objects, 10 actions) and has no output schema or annotations, the description is adequate at a high level but not fully complete. It covers the core scope and action families, and the schema covers all parameters, but there is no guidance on expected responses, error behavior, or operational workflows such as needing confirm for deletes. The input schema fills some gaps, so this is a solid but not exceptional definition.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds meaningful semantics by explaining that type_* actions manage types while item_* actions manage items, and by noting that item operations require entityTypeId equal to the type id. It also provides bilingual aliases that help clarify the conceptual domain, which is valuable beyond the bare schema.

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

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

The description clearly identifies the tool as handling Bitrix24 smart processes (произвольные CRM-сущности) with 'types + items CRUD' and explicitly names the method families crm.type.* and crm.item.*. This distinguishes it from the sibling CRM tools, which target standard entities like deals, leads, or contacts.

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

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

The description implies usage for custom CRM entities through phrases like 'smart process' and 'custom entity', which helps an agent choose this over standard CRM tools. However, it does not explicitly state when NOT to use it, nor does it provide alternative tool routing or conditions for choosing type_* vs item_* operations beyond what the schema already says.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. The top-level description mentions method families and RU/EN aliases but does not disclose side effects, destructive action warnings, permission requirements, rate limits, or response behavior. The schema's action enumerations label some actions as destructive, but that is structured data, not top-level description content.

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

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

The description is compact, with the main scope front-loaded and a clear second sentence listing method families and language aliases. It avoids filler and communicates a large amount of coverage in two sentences. The dense method list is somewhat hard to scan but is still efficient.

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

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

For a tool with 22 parameters, 66 actions, and no output schema or annotations, the definition is only moderately complete. The input schema's action descriptions compensate significantly, but the top-level description provides no examples, no expected return shape, and no guidance for multi-step workflows. It is adequate for basic selection and invocation, but not comprehensive for such a large aggregate tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.