Bitrix24 Tasks, CRM & Lists MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Most tools are clearly separated by resource and action (tasks, deals, contacts, users, projects, calendar, Lists). The main boundary risks are bitrix_create_activity overlapping semantically with bitrix_schedule_meeting and bitrix_create_task, but the descriptions clarify the module context well.
Naming Consistency4/5
The bitrix_ prefix with snake_case verb_noun naming is consistent throughout, e.g. bitrix_list_tasks, bitrix_get_task, bitrix_create_deal. Minor deviations like bitrix_lists_search_letters and bitrix_find_contact are still readable and do not break the overall pattern.
Tool Count2/5
With 46 tools, the server exceeds the 25+ threshold and feels heavy even though it covers three domains. The large surface creates selection overhead and could be better scoped or split into separate servers.
Completeness3/5
Core create/read/update flows exist for tasks, deals, contacts, and projects, plus useful extras like calendar scheduling and time reports. However, there are no delete or archive tools for any entity, activities lack update/delete, and meetings cannot be updated or cancelled.
Average 3.5/5 across 46 of 46 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. It only says 'list contacts with search by name' and omits return shape, default ordering, limit behavior, assignedId filtering, and the fact that search actually matches name or comment rather than only name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is appropriately short, though the brevity comes at the cost of useful detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with four optional parameters and no output schema, this description is too incomplete. It does not explain what the function returns, how pagination works, how filtering behaves, or when to prefer this over sibling contact tools. Only the basic purpose is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%; limit and order have no descriptions. The tool description adds no new parameter-level meaning and even narrows the search behavior to 'by name', while the schema says the search parameter matches 'name or comment'. This is unhelpful and slightly misleading.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action and resource: listing Bitrix24 CRM contacts, with search capability. This is enough to distinguish it from single-contact tools like bitrix_get_contact, though it does not explicitly differentiate it from the sibling bitrix_find_contact.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as bitrix_find_contact, bitrix_get_contact, or bitrix_list_users. The agent must infer usage entirely from the tool name and the one-line description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description alone must disclose behavior. It only states that the tool lists deal timeline comments and gives no information about read-only semantics, pagination, ordering, response shape, or access requirements. The list operation's side effects are left to inference.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no filler, and the key resource/operation is front-loaded. It is concise, but this conciseness comes at the expense of necessary behavioral and parameter context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter list tool with no annotations and no output schema, the definition is minimally usable but incomplete: it relies on the schema for dealId and does not mention returned data, pagination behavior, or the meaning of limit. An agent would have to guess at common list-tool conventions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%: only dealId has a description ('ID сделки.'), and the limit parameter has only type/default/min/max. The tool description adds no parameter-level meaning, does not explain what limit controls, and does not compensate for the undocumented parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the operation as 'list comments of deal timeline' and names the Bitrix24 deal context. It distinguishes the read/list purpose from sibling bitrix_add_deal_comment, though it does not explicitly name alternatives. The resource and operation are clear enough for an agent to know 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to choose this tool over alternatives such as bitrix_add_deal_comment or bitrix_get_deal. The intended use is only implied by the operation name; there are no exclusions, prerequisites, or context cues. This falls short of the explicit when-to-use standard.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full disclosure burden, but it only restates the search-by-name/email behavior already present in the schema. It does not mention that this is a read-only list operation, how activeOnly and limit affect results, or what happens when no search query is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that communicates the tool's resource and filtering capability with no fluff. It is concise and readable, though the phrase 'по имени, фамилии или email' partially duplicates the existing 'search' parameter description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and several closely related sibling tools (get_user, list_contacts, find_contact), the description is too thin to fully orient an agent. It lacks expected return shape, alternative-selection guidance, and behavioral defaults, making it only minimally usable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents 'search' and 'activeOnly', while 'limit' and 'order' are left without schema descriptions. The description does not add any meaning for limit or order, nor does it explain defaults or ordering behavior, so it fails to compensate for the 50% schema coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: searching and listing Bitrix24 employees by name, surname, or email. The resource and filter scope are immediately apparent, and the tool is clearly distinct from task/deal/project tools. However, it does not explicitly differentiate itself from sibling tools like bitrix_get_user or bitrix_list_contacts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as bitrix_get_user, bitrix_list_contacts, or bitrix_find_contact. The agent is left to infer the right choice from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does mention the confirm=true requirement, which signals a write operation requiring explicit confirmation, but it does not explain side effects, visibility of the message, permissions, or whether the operation is reversible. The confirm requirement is already documented in the schema, so the description adds little extra behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two short sentences with no fluff. The core action is front-loaded, and the confirm requirement is a concise, relevant addition. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutating tool with no annotations and no output schema. The description explains the basic action and confirm guard but omits important context for safe invocation: what happens after sending, whether the message is editable/deletable, any permission expectations, and when to use sibling tools instead. With three required parameters and a write operation, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with descriptions, so the baseline is 3. The description does not add any meaning beyond the schema; the confirm=true mention is already present in the parameter description. No additional parameter context is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'send a message' to the 'Bitrix24 task chat' – a specific verb and resource. It implicitly distinguishes itself from siblings like bitrix_send_direct_message (direct message) and bitrix_list_task_messages (listing messages), but it does not explicitly name any alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only usage guideline is 'Требует confirm=true', which is a prerequisite rather than guidance on when to use this tool versus alternatives. It does not state when to prefer this over bitrix_send_direct_message or how it relates to bitrix_create_task/bitrix_update_task.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 restates the confirm requirement already present in the schema. It does not disclose side effects, whether the operation can be undone, required permissions, or how the result record relates to task completion.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence with the action front-loaded and no filler. It is efficient, though the confirm clause is redundant with the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the schema fully documents its parameters, so an agent can form a valid call. However, with no output schema and no annotations, the description omits return behavior, side effects, and usage context, making it minimally viable rather than complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter already has a meaningful description, so the description adds little beyond baseline. The mention of confirm=true duplicates the schema's own 'must be true' semantics rather than providing new parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Зафиксировать') and resource ('результат работы по задаче') and identifies the underlying API method tasks.task.result.add. It clearly states what the tool does, though it does not explicitly differentiate it from sibling tools like bitrix_add_task_message or bitrix_complete_task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternative task-related operations such as adding a message or completing a task. The confirm=true note is a parameter prerequisite, not tool-selection guidance, so an agent still has to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only restates the operation implied by the tool name; it does not mention ordering, pagination semantics, what change types are included, or whether the response is an array.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no fluff and the core purpose is front-loaded. It is concise, though it sacrifices useful behavioral and usage detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is too thin. It does not explain what kind of entries appear in the history, the default ordering, or how this relates to sibling task tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters (taskId and limit). The description adds no additional meaning beyond what the schema provides, which warrants the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Получить' / get) and a specific resource ('историю изменений задачи' / task change history). This clearly differentiates it from related tools like bitrix_get_task or bitrix_list_task_messages, though it does not explicitly name those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance about when to use this tool versus alternatives, no exclusions, and no context such as 'use this when you need the change log rather than current state'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that messages and comments are retrieved, but does not mention ordering, pagination behavior, potential side effects, permissions, or what the response structure looks like. For a read operation this is a minor omission, but with zero annotation support the description is still thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no wasted words. It is appropriately front-loaded with the verb and resource, though it is terse and does not add supporting detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with a fully documented schema, the description is minimally viable: it names the resource being retrieved. But without an output schema, it does not explain return format, ordering, or how pagination/limit behaves in practice, leaving some gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both taskId and limit already documented clearly. The description adds no additional parameter semantics beyond what the schema provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Получить'/'get') and a clear resource ('сообщения и комментарии задачи'/'task messages and comments'), so an agent can understand the tool's purpose. However, it does not explicitly distinguish itself from siblings like bitrix_get_task_history or bitrix_add_task_message, leaving some differentiation to inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as bitrix_get_task_history or bitrix_add_task_message. The description simply states what the tool does without any context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden. It states that the tool retrieves full task information, which suggests a read-only operation, but it does not describe permissions, output shape, or what 'full information' actually includes. It adds little beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short, well-structured sentence with no filler. Everything present earns its place and the key resource and operation are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, so a short description is acceptable. However, because there are no annotations and no output schema, the description could have explained what fields 'full information' includes or how the response is structured. It is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully documents taskId with type, description, bounds, and requirement. The description adds only a generic 'by ID' reference, which repeats the schema. Baseline 3 is appropriate because schema coverage is 100% and no additional parameter semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('get full information') and the resource ('task by ID'). It is specific enough to distinguish from list-type tools, though it does not explicitly name sibling alternatives or explain how it differs from bitrix_get_task_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the many sibling tools. It only implies usage when a task ID is known, but does not state exclusions, alternatives, or prerequisites, which is especially important given the large task-related sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 the tool returns 'полную информацию' (full information) but does not say what fields that includes, how errors or nonexistent user IDs are handled, or whether the operation is read-only. For an unannotated tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with zero filler, front-loaded with the action, resource, and lookup key. The length is ideally matched to the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For the simplest possible signature — one fully documented integer parameter and no output schema — the required inputs are completely specified and the ans agent can call it correctly. The main gaps are the unstated return structure and not-found/error behavior, which the agent must infer or discover at runtime.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the sole parameter userId is already documented with its type, bounds, and description 'IDпоьзователя'. The description only echoes this with 'по ID' and adds no additional semantic meaning, warranting the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Получить' — get), a resource (Bitrix24 user), and a retrieval method ('по ID' — by ID), and claims to return full user information. It clearly describes the action and scope, though it does not explicitly name or distinguish sibling tools such as bitrix_list_users, relying on 'по ID' to imply single-record retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like bitrix_list_users for listing users or bitrix_find_contact for searching by attributes. There are no exclusions, prerequisites, or context rules beyond the bare one-sentence description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states that a list is produced and the filter scope; it does not disclose how dealId and contactId combine, whether at least one filter is required, pagination/limit behavior, or the structure of returned activities.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short phrase with no filler and puts the core resource first. It is appropriately concise, though it sacrifices operational detail that other dimensions penalize.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description alone is insufficient for reliable invocation. It leaves ambiguous the relation to bitrix_list_tasks, the required parameter combination, the meaning of the optional limit, and the returned data. A more complete definition should state whether dealId or contactId must be provided and what the response contains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents dealId and contactId as IDs (67% coverage), and the description adds the meaning that these parameters are the deal/contact by which activities are filtered. It does not add semantics for the undocumented limit parameter, though its default/min/max constraints are present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The phrase 'Список дел (активностей) по сделке или контакту' clearly identifies the resource (activities) and the scope (deal or contact). It is more than a tautology, though it lacks an explicit verb and does not clearly distinguish the tool from the closely named sibling bitrix_list_tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when activities associated with a deal or contact are needed. However, it gives no explicit guidance about alternative tools, such as bitrix_list_tasks or bitrix_create_activity, and does not state whether one of dealId or contactId is required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'list' implies a read operation, the description does not state whether authentication is required, what the response looks like, whether pagination exists, or any other behavioral details. It plainly restates the tool's function without enriching the agent's understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase with no filler. It conveys the core purpose immediately and is appropriately sized for a tool with no parameters and no complex configuration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though the tool is simple and has no parameters, there is no output schema and no annotation, so the description is the only source of context. It fails to explain what the returned deal-funnel data includes, how it might be used afterward, or any prerequisites. A minimal viable description for this simple tool would still mention the returned entity type and provide some usage framing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema has no properties, so there is no parameter semantics gap to compensate for. The baseline for a zero-parameter tool is 4, and the description does not need to add parameter detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific resource ('воронок сделок' / deal funnels) and the action of listing them, so an agent can tell this tool is about retrieving deal categories. However, it does not explicitly distinguish itself from siblings like bitrix_list_deals or bitrix_list_deal_stages beyond the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus the other list/get/deal tools. It does not mention that this should be used to enumerate available deal funnels before working with deals or stages, nor does it name any alternative tools or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states this is a list operation, which implies a read, but it doesn't reveal default exclusions (completed tasks/done stage), sorting, or response shape, and it may overstate the need to specify project when the schema marks it optional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence that immediately states what the tool does, then gives the two most important usage hints. There is no wasted wording or redundant restating of the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 7 parameters are fully documented in the schema and this is a simple read/list operation, the description is adequate. However, with no output schema and no annotations, the description doesn't cover default behavior (e.g., completed tasks excluded) or optionality of project, leaving some gaps for an agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds minimal value beyond the schema by telling the agent to use project name and stages rather than IDs, but it doesn't explain parameters like limit, order, search, or the include flags, which are already well-covered by the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool lists Bitrix24 tasks, and adds the key scoping dimensions (project name and kanban stages). It distinguishes itself from get/update tools by noting 'ID не нужны', but doesn't name a sibling directly, so it's clear but not fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides parameter-level guidance ('Указывайте project и stages') but no explicit when-to-use versus alternatives, no exclusions, and no mention of the many list vs. detail vs. action siblings. The only differentiation hint is 'ID не нужны', which is not enough to route an agent confidently.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 discloses that confirm=true is required, but does not mention that removal is destructive/irreversible, what confirmation gate behavior occurs when confirm=false, or whether groupId or project must be supplied to identify the target project.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler or redundant content. However, its brevity comes at the cost of important usage context, so it is concise but slightly under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations, no output schema, and the semantic ambiguity around groupId/project selection, the description is incomplete. It does not explain how to identify the project, what happens if neither groupId nor project is provided, or what side effects occur on member removal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents confirm, groupId, project, and userIds. The description adds only the confirm=true requirement, which is also partially in the schema, so it provides minimal additional semantic value beyond the high-coverage baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('удалить участников') and the resource ('из проекта (воркгруппы)'). It also names Bitrix24, and the verb distinguishes it from sibling tools like add, update, and list project members.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only usage guidance is 'Требует confirm=true', which is an operational requirement, not a when-to-use instruction. The description does not explain when to choose this tool over alternatives like bitrix_update_project_member_role or bitrix_add_project_members, nor does it mention the need to specify groupId or project.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions the confirm=true requirement, but this is already documented in the input schema, so it adds no new behavioral information. With no annotations provided, the description does not disclose response behavior, auth needs, side effects, or reversibility beyond the obvious fact that it creates a deal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler. The core action is front-loaded, and the confirm requirement is presented as a compact secondary note.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 9 parameters, no output schema, and no annotations, the description provides almost no contextual information. It does not explain what the tool returns, what prerequisites exist, or how it relates to sibling deal tools beyond the obvious creation action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all 9 parameters with 100% description coverage, so the baseline is 3. The description itself does not add parameter-level meaning beyond repeating the confirm requirement, which is already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Создать' (create) with a clear resource 'сделку в Bitrix24 CRM' (deal in Bitrix24 CRM). This clearly distinguishes the tool from siblings like bitrix_update_deal, bitrix_list_deals, and bitrix_get_deal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as bitrix_update_deal or bitrix_list_deals. No conditions, prerequisites, or exclusions are stated, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the behavioral disclosure burden. It does indicate a write operation and that confirm=true is mandatory, but the confirmation requirement merely repeats the schema property description. Important behavioral context such as permissions, side effects, idempotency, and response behavior is absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with the action and object front-loaded, and the confirmation requirement is useful. The parenthetical '(доску)' is slightly redundant or ambiguous, but overall there is no padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple creation tool, the schema documents all parameters and the description states the operation and confirmation requirement. However, with no annotations and no output schema, an agent still lacks context about return values, side effects, and how this operation relates to listing or moving stages; the definition is minimally viable but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and all parameters already have descriptions, including the confirm guard and projectId reference to bitrix_list_projects. The description itself adds no parameter-level meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific action ('Создать' = create) and clearly identifies the resource as a new kanban column/stage inside a project, which separates it from project/task creation tools. The parenthetical '(доску)' creates slight ambiguity between a board and a column, and it does not explicitly name a sibling to distinguish from.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys the core use case—creating a project stage—and adds the invocation requirement 'Требует confirm=true.' It does not state when to prefer this over related tools such as bitrix_list_project_stages or bitrix_move_task_stage, nor does it list exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions that category and stages are matched by name but says nothing about read-only semantics, pagination, default limit, ordering, or response shape. For a tool with eight parameters, this is a substantial 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and then gives a focused filtering instruction. There is no filler, redundancy, or unnecessary detail. It is appropriately sized for a straightforward list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With eight parameters, no output schema, and no annotations, a two-clause description is not enough. It omits pagination behavior, default limits, how filters combine, what the returned object looks like, and whether the operation is read-only. A caller would need to inspect the schema and still lack operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%, and the schema already documents that category and stages are 'название' (names), so the description's by-name guidance largely restates existing schema information. It adds little beyond the structured fields, and limit/order have no added explanation. The baseline 3 fits because the schema carries most of the semantic weight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource and action: listing Bitrix24 deals. It also adds a useful qualifier that category and stages are specified by name, which helps distinguish this tool from lower-level deal operations. It does not explicitly contrast with sibling get_deal, but the name and phrasing are unambiguous enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The instruction to specify category and stages by name provides a clear, actionable usage hint for filtering. However, it does not state when this tool should be preferred over alternatives like get_deal, create_deal, or list_deal_comments, nor does it give exclusions. Usage context is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing side effects. It does state that this is a write operation, limited to certain fields, and gated by confirm=true. However, it does not clarify whether updating replaces the entire field set or merges with existing values, nor does it mention permissions, reversibility, or response behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one compact sentence with the action, target fields, and confirmation requirement all front-loaded. It is concise and free of filler, though the incomplete field list and lack of alternative routing make it slightly less sharp than a top-tier description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a three-parameter update tool with a nested fields object and no annotations or output schema, this is minimally viable: the agent knows what to modify and that confirm must be true. Gaps remain around SECOND_NAME, merge-vs-replace semantics, and what the tool returns after a successful update, so it is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents contactId and confirm with descriptions and gives a detailed nested structure for fields. The description adds a practical list of editable fields and the confirmation requirement, but the list is incomplete because SECOND_NAME is absent, and it does not explain how the fields object should be composed for a partial update.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb, 'Изменить', identifies the resource as a contact, and lists the editable fields, which distinguishes it from contact creation, retrieval, and listing tools. However, the field list omits SECOND_NAME even though the schema allows it, so the scope is slightly inaccurate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance about when to use this tool versus bitrix_create_contact, bitrix_find_contact, or other update tools. It only states the confirm=true requirement, which is an invocation constraint rather than usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only restates the confirm requirement already present in the schema and does not mention side effects, irreversibility, permissions, or what happens if the task is already completed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single tight sentence with no fluff. It front-loads the core action and API method, and every word earns its place for a simple two-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and all parameters are documented, but the description lacks usage context and behavioral side effects. Since there is no output schema and no annotations, the description is minimally adequate rather than fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both taskId and confirm. The description's confirm=true note adds no meaning beyond the schema's 'Должно быть true для выполнения операции записи.'
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Завершить задачу' ('Complete the task'), backed by the explicit API method 'tasks.task.complete'. This clearly distinguishes it from sibling tools like bitrix_start_task and bitrix_update_task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as start_task, update_task, or move_task_stage. The only extra instruction, 'Требует confirm=true', is a parameter requirement rather than usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral disclosure burden. It only states that IDs are not needed, omitting important traits like read-only nature, whether the category is required, return format, or error behavior. This is insufficient for a tool with zero 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two short sentences with no redundant wording. The core purpose is front-loaded, and every word contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool this is mostly adequate, but key gaps remain: the description does not clarify whether the category parameter is required despite having no required parameters, and without an output schema or return description the agent is left guessing about the response structure. The explicit 'IDs not needed' note helps slightly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes both parameters, and the description adds meaningful guidance by emphasizing the category name as the primary input and explicitly stating that IDs are not needed. This goes beyond the schema's basic field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists deal funnel stages by category name, using a specific verb and resource. It also differentiates by saying IDs are not needed, but it does not explicitly name sibling tools to distinguish from them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies the agent should use the category name rather than the ID, which is a useful parameter selection guideline. However, it does not explicitly state when to use this tool versus alternative stage- or deal-related tools, nor provide any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It conveys that lookup is by project name and that IDs are unnecessary, which implies a read-only list operation. However, return format, error behavior, and authentication needs are not addressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no wasted words. The core purpose is front-loaded and the 'ID не нужны' note is a useful, compact clarification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter list tool, the description and schema together are sufficient for basic invocation. It does not describe the output shape or edge cases, but those are not critical for selecting or calling this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter description already explains the project name and its optionality. The phrase 'ID не нужны' adds minor clarification but does not provide substantive meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('list') and resource ('project kanban columns'), and explicitly notes that IDs are not needed. It is distinguishable from deal-stage tools like bitrix_list_deal_stages, but it does not explicitly name any alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance about when to use this tool versus alternatives. The only usage hint is in the parameter description (optional when only one project exists), but no when-not or sibling comparison is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The description conveys only the basic lookup purpose and API method; it does not disclose whether the operation is read-only, how matching works, what happens with multiple matches, or what the response format is. The method name hints at duplicate search behavior, but this is not made explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that states the operation, the accepted parameter types, and the underlying API method. There is no fluff or redundant repetition of schema information. It is appropriately sized for a simple two-parameter lookup tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two optional schema-documented parameters, the description is mostly adequate. However, it does not explicitly state that at least one of the two parameters should be provided, nor does it describe the return value when no contacts or multiple contacts are found. Since there is no output schema, a note about the result shape would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and each parameter has a basic description. The tool description adds meaning by explicitly stating 'и/или' (and/or), clarifying that the phone and email parameters can be used individually or together. This relationship is not fully expressed in the schema, which only lists both as optional strings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the exact function: finding a contact by phone and/or email. It names the underlying CRM API method, crm.duplicate.findbycomm, and the verb 'найти' plus resource 'контакт' makes the purpose unambiguous. This also differentiates it from sibling tools like bitrix_list_contacts and bitrix_get_contact.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool instead of bitrix_list_contacts or bitrix_get_contact. The description does not mention that this is a duplicate-finding or precise-communication lookup, nor does it state any prerequisites or alternatives. The agent must infer the appropriate context from the tool name and method identifier alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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. 'Получить' indicates a read operation, and the acceptance-criteria framing adds useful semantic context. Still, the description does not mention error behavior, permissions, what happens when the checklist is absent, or output shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler. It states the action and the resource efficiently, and the acceptance-criteria qualifier earns its place by clarifying the intended interpretation of the returned checklist.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read operation, the description covers the core purpose and context. However, since there is no output schema, the description could have briefly noted the expected return structure or edge cases, such as an empty or missing checklist. This leaves a noticeable but minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the single taskId parameter is already described as 'ID задачи.' The tool description adds no additional parameter detail beyond confirming the checklist belongs to a Bitrix24 task, so the schema remains the primary source of parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Получить') and resource ('чек-лист задачи Bitrix24'), adding the semantic framing 'как критерии приёмки' to clarify the checklist's role. It is distinguishable from the sibling bitrix_get_task because it targets the checklist specifically, though it does not explicitly contrast itself with that sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'как критерии приёмки' implies the tool should be used when acceptance criteria for a task are needed, providing some usage context. However, there is no explicit guidance about when to use this tool versus alternatives like bitrix_get_task, and no stated exclusions or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It mentions that confirm=true is required, but that is already in the schema. It does not disclose side effects, reversibility, permission requirements, or failure behavior of the move operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short, front-loaded clauses: the action first, then the critical confirm requirement. Every word earns its place, and there is no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation with complete schema coverage, the description is minimally viable. But because there are no annotations and no output schema, it would benefit from noting how to obtain valid stage names or what happens after a successful move.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% description coverage for all three parameters, including taskId origin and valid stageName examples. The description adds only the 'by name' nuance, which is useful but does not materially extend schema semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Переместить задачу') and resource ('колонку канбана'), with the key mechanism 'по названию'. It distinguishes this tool from siblings like bitrix_move_deal_stage by targeting tasks and kanban columns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: use this to move a task between kanban columns by stage name. However, there is no explicit guidance about when to prefer it over alternatives such as bitrix_update_task or bitrix_move_deal_stage, nor any mention of prerequisites like fetching valid stage names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full transparency burden. It does disclose that the operation is a write that requires confirm=true and that one of dealId/contactId is needed, which is safety-relevant. It does not describe return shape, permissions, or downstream effects such as activity history or notifications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short, purposeful sentences with the purpose first, followed by the two critical constraints. There is no filler or unnecessary repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 9-parameter tool with no annotations and no output schema, the description is somewhat sparse. The schema covers parameter meanings and the description adds confirm and identifier preconditions, but it does not address type-specific behaviors such as whether a meeting or call needs startTime/endTime, nor what the API returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all nine parameters, so the baseline is 3. The description adds value beyond the schema by encoding a disjunctive dependency not present in the JSON Schema: dealId or contactId should be supplied. It also reinforces that confirm must be true, which is important for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action and resource: create an activity in CRM, explicitly listing the three subtypes (call, meeting, task). It does not explicitly contrast itself with sibling tools like bitrix_create_task or bitrix_schedule_meeting, so it misses the full differentiation standard.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives practical call prerequisites: 'Требует confirm=true' and 'Укажите dealId или contactId'. However, it does not explain when to prefer this tool over related alternatives such as bitrix_create_task or bitrix_schedule_meeting, so alternative-selection guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 noun 'Список' implies a read-only retrieval operation with no side effects, but the description does not state the output shape, whether all accessible projects are returned, or how the optional name filter behaves exactly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that states the core purpose and the optional filter without any filler. The essential information is front-loaded and every word contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description covers the core operation adequately. The only meaningful gap is that it does not describe the return format, such as whether the result is a list of project names, objects, or includes IDs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes the only parameter as a filter by project name, and the description's 'по названию' merely echoes that. With 100% schema description coverage, the description adds no additional meaning about parameter syntax, format, or edge cases.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (listing), the resource (available Bitrix24 projects), and an optional scope (by name). This distinguishes it from sibling tools that list other resources, such as bitrix_list_project_stages or bitrix_list_project_members, and from creation tools like bitrix_create_project.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. There is no mention of when to call it, what prerequisites exist, or why it should be preferred over related tools such as bitrix_list_tasks or bitrix_list_deals.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions that confirm=true is required, which is useful, but it does not disclose permissions needed, side effects on existing members, whether the operation is idempotent, or what happens on success/failure. For a write operation this is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two compact clauses with no wasted words. The core action and target resource are front-loaded, and the key requirement (confirm=true) is included at the end, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward mutation with strong schema coverage, the description plus schema is mostly sufficient for invocation. However, there is no output schema and the description does not explain return values, error behavior, or how to identify the project beyond what the schema references (group ID or project name). It is adequate but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents every parameter, including role enum and the confirm flag. The description adds no parameter-level meaning beyond what the schema provides, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Добавить участников') with a clear resource ('уже существующий проект (воркгруппу) Bitrix24'). It distinguishes itself from project creation and member-removal tools by explicitly targeting existing projects. The 'без похода в интерфейс' note adds operational context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'в уже существующий проект' clearly sets the context: this tool is for adding members to an existing project, not for creating one. It does not explicitly name alternatives like bitrix_remove_project_members or bitrix_create_project, but the intent is unambiguous enough for an agent to route correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. 'Get' signals a read-only retrieval with no side effects, and 'full information' suggests a complete contact record is returned. However, it does not disclose error behavior, permissions, response format, or what 'full information' concretely includes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence containing the operation, target resource, and input criterion. There is no redundant filler; every word contributes to understanding what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter lookup, the description is minimally viable: it names the input (ID) and the broad output scope (full information). Yet there is no output schema and no description of response shape, not-found behavior, or how this differs from related lookup tools like bitrix_find_contact or bitrix_list_contacts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the contactId parameter is already described as 'ID контакта.' The tool description only restates this with 'по ID' and adds no additional semantic detail, so the schema carries the parameter documentation weight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Получить полную информацию о контакте Bitrix24 по ID' clearly states a specific verb (get), resource (Bitrix24 contact), and identifier (by ID). This unambiguously distinguishes it from sibling tools like bitrix_list_contacts, bitrix_find_contact, and bitrix_update_contact.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'по ID' implies the intended use: when a contact ID is already known and full contact details are needed. However, it does not explicitly mention alternatives or when not to use this tool, such as using bitrix_find_contact when the ID is unknown.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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. It reveals that the tool returns file content base64-encoded and downloads a single attachment. It doesn't address error cases, size limits, or read-only status, but the return format is a worthwhile behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no filler: the first states the action and resource, the second the return format. Everything is front-loaded and necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description is the only source of context. It defines the ID source and the base64 return encoding, but leaves the required direction parameter ambiguous, so an agent cannot reliably know what to pass for 'incoming' vs 'outgoing'. This is a significant gap for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for both parameters. It explains attachedObjectId by pointing to bitrix_lists_search_letters, but the required direction parameter (incoming/outgoing) is not explained at all; the schema enum only lists possible values without conveying their meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Скачать' / download), a specific resource (content of one email attachment from the 'Lists' registry), and the lookup key (attachedObjectId obtained from bitrix_lists_search_letters). This clearly distinguishes the operation from its sibling bitrix_lists_search_letters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It names the upstream tool that produces the required attachedObjectId, making the intended workflow 'search first, then download' explicit. It doesn't state explicit when-not-to-use cases, but the sequencing is clear enough for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It discloses a key behavioral requirement: confirm=true is mandatory for the write operation. This adds some safety-relevant transparency. However, it does not mention side effects, reversibility, permission needs, or behavior when the stage name is invalid or the category is omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. The core action is stated first, followed by the critical confirmation requirement. This is optimally concise for a tool with four already-documented parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description plus fully documented schema covers the basic invocation needs: required dealId, stageName, confirm, and optional category. However, with no annotations, no output schema, and no guidance on expected return values or failure behavior, the context is adequate but not complete for an agent that needs to decide when and how to invoke this safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description reinforces that stageName is used by name and confirm must be true, which aligns with the schema descriptions. It does not add substantial meaning beyond the schema, but no parameter is left undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (move), a specific resource (deal), and the target (pipeline stage by name). This clearly differentiates it from bitrix_move_task_stage and other deal management tools such as bitrix_update_deal, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The wording implies the tool is used when a deal needs to be moved to a named funnel stage, and the confirm=true requirement signals that this is an intentional write operation. However, it does not explicitly state when to prefer this over alternatives like bitrix_update_deal or bitrix_move_task_stage, so the usage guidance remains implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states what is checked but does not disclose whether the operation is non-destructive, what a successful or failed result looks like, or whether it performs any actual API call beyond a health check.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, tightly scoped sentence with no filler. The main verb and resource are front-loaded, and every word contributes to the tool's meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter connectivity check, the description is largely sufficient: it says what connection is being tested and which APIs are checked. However, without annotations or an output schema, it would benefit from at least a note about expected behavior or return format to be fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema already covers everything. The description adds useful context about what the connection test validates, which is appropriate for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('проверить' — check), a specific resource (Bitrix24 connection via incoming webhook), and the exact scope (availability of Tasks and CRM REST APIs). It is clearly distinguishable from the sibling tools, none of which are connectivity tests.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose implies the obvious use case: verify Bitrix24 connectivity before relying on other Bitrix tools. However, there is no explicit guidance about when to use it versus alternatives, no prerequisites, and no statement about when it is not needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 that confirm=true is required, which is already visible in the schema. It does not explain whether unspecified fields are preserved, what permissions are needed, whether the operation is reversible, or what the response looks like. This is a significant gap for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler. The core action and allowed fields are front-loaded, and the mandatory confirm requirement is stated clearly. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description plus schema covers the essential purpose and parameters, but for a mutation tool with no annotations and no output schema it lacks usage guidance and behavioral side effects. A more complete definition would mention when to use this vs. other deal tools and what happens after the update.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67%, so the schema already documents dealId and confirm. The description adds value by explicitly naming the acceptable fields (TITLE, COMMENTS, OPPORTUNITY, CURRENCY_ID), clarifying that the nested fields object is intentionally limited to these, which the schema alone does not convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Изменить' - modify) with a clear resource ('сделки' - deal) and enumerates the exact fields allowed: TITLE, COMMENTS, OPPORTUNITY, CURRENCY_ID. This clearly distinguishes it from sibling deal tools like bitrix_move_deal_stage or bitrix_add_deal_comment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'ограниченный набор полей' implies this tool is only for certain fields, but it does not explicitly state when to use this tool versus alternatives like bitrix_update_task, bitrix_move_deal_stage, or bitrix_create_deal. No concrete when/when-not guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that the operation requires confirm=true, which is useful confirmation-related behavior. It does not disclose side effects such as overwriting the previous role, permission requirements, or restrictions on changing an owner role.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences: the first clearly states the purpose, and the second adds the critical confirm=true prerequisite. There is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple role-update operation, and the schema fully documents parameter meanings. However, with no annotations or output schema, it does not explain how to choose between the optional groupId and project parameters, nor does it describe what happens after a successful update or what the tool returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds little beyond the schema; 'Требует confirm=true' restates what the confirm parameter already documents. It does not clarify the relationship between optional groupId and project, which could be ambiguous when calling the tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action: changing the role of an existing Bitrix24 project/workgroup member. It names the resource (project member), the operation (update role), and the qualifier 'existing' helps distinguish it from adding or removing members. No sibling tool updates member roles, so there is minimal ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by saying 'existing participant' and 'role', which indicates it is not for adding/removing members and is for role changes. However, it does not explicitly name sibling alternatives like add/remove member tools, nor does it describe when-not-to-use conditions beyond the word 'existing'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden. It surfaces the confirm=true confirmation gate and frames the operation as safe/restricted, which is useful for a write tool. However, it does not disclose postconditions (e.g., whether unspecified fields are preserved), error behavior, permissions, or what the tool returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with zero filler. The field whitelist is front-loaded, followed immediately by the confirm requirement. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter write tool with a nested fields object and no output schema or annotations, the description covers the core safety gate and scope but omits the response/return behavior, any field format expectations (e.g., DEADLINE), and what happens on partial updates. Adequate, but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents taskId, fields, and confirm. The description's enumeration of the four allowed fields mirrors the schema's field properties rather than adding new meaning. The restated confirm requirement adds no information beyond the schema's own description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb (изменить/update), the resource (task), and scopes the operation to a limited whitelist of fields (TITLE, DESCRIPTION, DEADLINE, PRIORITY). This clearly distinguishes it from siblings like bitrix_create_task, bitrix_start_task, and bitrix_move_task_stage, which perform different lifecycle operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'limited set of fields' phrasing conveys that the tool is for safe, scoped edits rather than general task mutation, but no alternative is named and no when-to-use/when-not-to-use conditions are stated. The agent must infer the usage context from the field whitelist and the confirm=true requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It clearly discloses that this is a write operation and that confirm=true is required to execute, which is important behavioral context. But it omits side effects, return behavior, permissions, or failure conditions, so transparency is only partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with the core action front-loaded and the key prerequisite immediately after. There is no filler or redundant elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter tool, the description plus fully described schema gives an agent enough to invoke it correctly: action, target, and confirmation gate are all clear. It stops short of 5 because there is no output schema and no mention of return behavior, though that is not critical for making a correct call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so dealId, text, and confirm are already well documented. The description adds no new parameter meaning beyond restating the confirm requirement, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Добавить комментарий') and a specific resource ('timeline сделки'), making the purpose unambiguous. It naturally distinguishes this tool from siblings like bitrix_add_task_message or bitrix_list_deal_comments without needing to open the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended usage is implied by the action and resource: add a comment to a deal timeline. However, the description provides no explicit when-to-use or when-not-to-use guidance, nor does it name alternative tools for similar operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the behavioral disclosure burden. It does disclose that this is a write operation requiring confirm=true, which is valuable. However, it does not mention permissions, reversibility, side effects such as project visibility/membership, or what happens on success or failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. The main action and resource are front-loaded, and the critical confirm=true requirement is called out separately and clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create operation with a fully documented schema, the description provides enough context: it names the feature area, clarifies the write nature, and highlights the mandatory confirmation flag. The absence of an output schema means return-value information is not guaranteed, but this is a minor gap for invoking the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all six parameters. The description adds no parameter-specific meaning beyond confirming that confirm must be true, which is already stated in the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific verb 'Создать' (create) and the specific resource 'проект (воркгруппу)' (project/workgroup), anchoring it to the Bitrix24 tasks/projects section. This distinguishes it from sibling operations like listing projects, creating project stages, or adding members.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for creating a new Bitrix24 project, and it explicitly states a required precondition: confirm=true. However, it does not explicitly compare against alternatives such as bitrix_create_task or bitrix_create_deal, nor does it state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral disclosure burden. 'Получить полную информацию' clearly indicates a read operation returning deal data, but it does not describe behavior such as error handling, authorization requirements, or what 'full' information includes. The description is adequate but does not go beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the verb, resource, and identifier. There is no filler, and every part of the sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with one fully documented parameter and no nested objects, the description adequately conveys purpose and scope. It does not provide the return structure, but no output schema exists and the tool is low-complexity, so the gap is minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — the schema already documents dealId as 'ID сделки.' The description only restates that the tool works by ID and adds no extra meaning, format detail, or behavioral nuance beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific action ('get full information') on a specific resource ('deal') by a specific key ('ID'). It is clearly differentiated from siblings like bitrix_list_deals, bitrix_create_deal, and bitrix_update_deal, so an agent can tell what this tool is for without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'по ID' implies the tool is for fetching a single deal when its ID is known, which provides implied usage context. However, it does not explicitly mention alternatives (e.g., bitrix_list_deals) or state when-not to use the tool, so usage guidance is only implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it declares read-only behavior, required access scopes, and notes that the timeman part only applies when userIds are specified. This meaningfully discloses auth needs and conditional behavior beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but efficient: it front-loads the read-only nature, states the aggregation structure, lists optional filters, and closes with the authorization nuance. Every clause earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only summary tool with no output schema, the description conveys the output shape (hours by user and by task), the period semantics, optional filters, and permission needs. It is slightly incomplete only in not clarifying behavior when no data matches or how it relates to the overlapping worktime-report sibling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well documented and the description adds little beyond restating the filtering intent. The baseline of 3 applies 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a read-only summary of work-time tracking, with hours aggregated by users and tasks over a date range. It names the resource and scope, but does not explicitly distinguish it from the sibling bitrix_get_worktime_report, so it falls short of full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides practical usage context: date range, optional user/project filtering, and the access-scope requirement. However, it does not state when to prefer this tool over bitrix_get_worktime_report or mention any exclusion criteria, leaving the choice between similar tools implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the transparency burden. It does indicate a read-only list operation and names the output fields (ID, role, name), but it does not mention authentication needs, error behavior, membership filtering, pagination, or response structure beyond the implied list.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence that front-loads the action and object and ends with the useful output summary. There is no filler, repetition, or unnecessary content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity read-only list tool, the description plus schema is sufficient to make a call: schema explains the optional parameters, and the description explains the purpose and returned fields. Some extra detail about error cases or response shape could improve it, but these are not critical for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both groupId and project clearly, including the cross-reference to bitrix_list_projects and the condition for omitting project. The tool description adds no additional parameter-level meaning, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Список' — list), the resource ('участников проекта/воркгруппы'), and the returned fields (ID, role, name). This distinguishes it from sibling membership-mutation tools like bitrix_add_project_members, bitrix_remove_project_members, and bitrix_update_project_member_role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description itself gives no explicit when-to-use guidance or alternatives. The nearest usage context comes from the schema: 'см. bitrix_list_projects' for obtaining the group ID and the note that project can be omitted if unique. That is helpful but is parameter-oriented rather than a clear selection policy among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 add a useful non-obvious requirement: 'Требует confirm=true.' However, it does not describe side effects, response format, permissions, or behavior on duplicate contacts, which would be valuable for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short, purposeful sentences. It front-loads the action and object, then states the essential confirmation constraint. There is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter tool with no output schema and no annotations, the description covers the core operation and the confirmation gate. Still, it omits return value expectations and any additional behavioral context such as whether arrays are restricted or whether the operation creates a permanent record. It is adequate but not rich enough for a higher score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and every parameter has a Russian description, so the baseline is 3. The description adds semantic value beyond the schema by stating that the confirm parameter must be true, not merely present, which is critical for a successful call.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Создать') and resource ('контакт в Bitrix24 CRM'), clearly indicating a create operation. It differentiates this tool from sibling contact tools like bitrix_update_contact, bitrix_list_contacts, bitrix_get_contact, and bitrix_find_contact.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended usage is implied by the verb 'create': use this when a new contact needs to be created. However, the description does not explicitly state when to use it versus alternatives, nor does it mention any exclusions or prerequisites beyond confirm=true.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It does disclose the write operation and the confirm=true requirement, but it omits details about side effects, permissions, reversibility, or error behavior. Adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence followed by a short requirement clause. It front-loads the verb and target status, contains no filler, and every word contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, the description is nearly complete: it names the action, target status, API method, and confirmation requirement. Minor caveats such as restrictions on already-completed tasks are absent but not essential for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description adds only the confirm=true requirement, which is already stated in the schema, so no significant semantic value is added beyond the structured definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a concrete action ('Перевести задачу в статус «Выполняется»'), names the underlying API method tasks.task.start, and clearly distinguishes this from siblings like bitrix_complete_task or bitrix_update_task by specifying the target status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use case is clear: move a task into the 'In progress' status. It does not explicitly list alternatives or exclusions, but the target status and API method provide enough context to select this tool over related task tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It explicitly states this is a write operation requiring confirm=true, and explains that Bitrix24 rejects the task without responsibleId. It does not cover return values or error cases, but the core behavioral requirements are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the main purpose, followed by critical constraints (responsibleId, confirm). No fluff or redundant elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-param create tool with no output schema and no annotations, the description covers the essential invocation contract: what is created, project vs standalone, required responsibleId, and confirm flag. Optional params are left to the schema, which is reasonable given their descriptions. Missing permission/error context is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 10000%, so the schema already documents all seven parametes. The description adds emphasis on responsibleId and confirm requirements and clarifies projectId semantics, but does not materially extend beyond the schema's own descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Создать новую задачу' (create a new task), and distinguishes between project-bound and standalone tasks. This clearly separates it from siblings like bitrix_update_task, bitrix_start_task, and bitrix_complete_task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context for when to use the tool (creating a new task) and how to choose between a project task and a standalone task via projectIdparameter presence. It does not explicitly name alternative sibling tools, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral disclosure burden. It explicitly states the operation is read-only, creates nothing, returns at most maxCandidates slots, uses a specific output format, and requires the calendar scope. It does not cover timezone handling or result ordering, but the core side-effect and access requirements are transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: purpose and safety, return format and downstream compatibility, and required access scope. The most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description adequately covers return shape, format, result cap, side effects, and permission requirements. Parameter details are fully handled by the schema. Minor gaps such as timezone behavior and exact output structure could improve completeness, but nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds marginal semantic value by mentioning maxCandidates and connecting the output format to bitrix_schedule_meeting's from/to fields, but most parameter meaning is already fully documented in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: finding a common free calendar slot for multiple participants. It clearly distinguishes itself from bitrix_schedule_meeting by framing itself as the read-only availability search that produces the meeting's from/to inputs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a clear workflow: find a free slot first, then pass the returned values to bitrix_schedule_meeting. It does not explicitly state when not to use this tool or list alternatives, so it stops short of a perfect 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 explains important side effects: participants receive notifications and the meeting appears as busy time in their calendars. It also discloses that the webhook owner becomes the organizer and that confirm=true plus the 'calendar' scope are required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three compact sentences with no filler. It front-loads the primary purpose, then adds format, organizer identity, and requirements, each earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create-operation tool with no output schema, the description covers the core purpose, participant effects, organizer attribution, required confirmation flag, and access scope. It could mention what the tool returns (e.g., meeting ID), but the essential invocation context is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3 even though the description adds little parameter-specific information. The description usefully reinforces the from/to format and references bitrix_find_free_slot, but most parameter meaning is already fully documented in the input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: "Создать полноценную встречу в календаре Bitrix24 с приглашением участников". It clearly distinguishes itself from sibling tools by focusing on calendar meeting creation with participant invitations, unlike task, deal, contact, and free-slot tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when this tool is appropriate: creating a full calendar meeting with invited participants. It also implicitly links to bitrix_find_free_slot by referencing its date format, which helps the agent understand the intended workflow. However, it does not explicitly state when not to use it or name an alternative for similar operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It discloses that confirm=true is mandatory, that the 'im' access scope must be enabled, and that without it the tool returns a user-friendly error with instructions rather than a raw Bitrix error. This is useful behavioral context, though it could go further by describing the actual success/failure result format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two focused sentences with no filler. The core purpose and scope are front-loaded, followed by the key exclusion and the operational requirements. Every sentence contributes distinct information: purpose, alternative, and prerequisites/error behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the relative simplicity of a send-message tool, the description covers the essential context: target recipient, alternative for task chats, required confirm flag, and webhook scope prerequisite. A minor gap is that it does not explicitly mention what happens on success or whether the response contains an ID, but this is not critical for a message-sending tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all four parameters, including mutual exclusivity of userId and dialogId. The description adds marginal context by reinforcing that dialogId targets an existing chat/dialog and that the message is a personal message, but it does not substantially enhance parameter meaning 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Отправить' — send), a clear resource (personal message to a Bitrix24 user or existing chat/dialog by dialogId), and explicitly distinguishes it from task chat messages by naming bitrix_add_task_message as the alternative. This makes the tool's purpose unambiguous and differentiates it from the most easily confused sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides when-not-to-use guidance: 'не сообщение в чат задачи — для этого используйте bitrix_add_task_message'. It also states the required precondition of confirm=true and the required 'im' webhook scope, giving the agent clear preconditions for invoking the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explicitly declares read-only, identifies the underlying module, warns about the access scope, and states that at least one of departmentId/userIds is needed. It does not describe the response format or edge cases, but for a read-only summary tool the disclosed behavior is substantial and accurate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences with no filler: the first defines the output and underlying module, the second disambiguates from the sibling tool, the third gives scope and permission. All information is front-loaded and every clause contributes to correct tool selection or invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only query with no output schema, the description covers purpose, data fields, scope, permissions, and the distinguishing alternative. It omits details like exact response shape and how results are aggregated per user, but the named metrics and period make the tool usable. Given the absence of annotations and output schema, this is strong but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaningful semantics beyond the schema by explaining the relationship between departmentId and userIds, the at-least-one requirement, and the date range scope. This is extra value not present in the structured parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific output (workday summary with hours, idle time, and worked days) over a date range, and explicitly contrasts itself with bitrix_get_timesheet_summary. It is immediately clear what resource this tool reads and how it differs from its closest sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It names the alternative tool, states the exact semantic difference (task elapsed time vs. actual workday opening/closing), and clarifies the scope requirement: departmentId and/or userIds with at least one required. It also mentions the required 'timeman' access scope, giving the agent concrete selection and invocation guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so well. It discloses substring matching behavior, how projectQuery restricts the result set, robustness of letterNumber matching to historical field changes, the file reference structure in results, and a known limitation with legacy CFile-based fields for outgoing letters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph that front-loads the core purpose, then explains each search mode, the result-to-file-download handoff, and the known limitation. Every sentence contributes useful information without redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema and no annotations, the description covers the essential search modes, result file linkage, and a specific limitation. It is slightly incomplete because it does not describe the broader result shape or limit/pagination behavior, but the critical usage path is well-covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaningful semantics for projectQuery, letterNumber, and query, and indirectly covers direction via 'входящие/исходящие'. However, the limit parameter is not explained at all, leaving one parameter under-documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Найти письма') on a specific resource (Bitrix Lists registry, incoming/outgoing) and lists concrete search dimensions: project, subject, or letter number. It also distinguishes itself from the sibling bitrix_lists_get_letter_file by explaining that result files are passed to that tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: search letters in the Bitrix Lists registry by project, subject, or number, and then feed result file references into bitrix_lists_get_letter_file. It does not explicitly state when not to use it or name alternatives, but no other letter-search sibling exists, so the guidance is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![Bitrix24 Tasks, CRM & Lists MCP Server MCP server — quality and maintenance score on Glama](https://glama.ai/mcp/servers/Parallel-Solutions/bitrix_mcp_free/badges/card.svg)](https://glama.ai/mcp/servers/Parallel-Solutions/bitrix_mcp_free)

Score Badge

Copy to your README.md:

[![Bitrix24 Tasks, CRM & Lists MCP Server MCP server — quality and maintenance score on Glama](https://glama.ai/mcp/servers/Parallel-Solutions/bitrix_mcp_free/badges/score.svg)](https://glama.ai/mcp/servers/Parallel-Solutions/bitrix_mcp_free)

shields.io Endpoint

For READMEs with an existing badge row. Append &style=flat-square (or any other shields.io style) to match the rest, and &metric=tools, &metric=maintenance or &metric=claim to badge a different dimension.

[![Bitrix24 Tasks, CRM & Lists MCP Server MCP server — quality and maintenance score on Glama](https://img.shields.io/endpoint?url=https%3A%2F%2Fglama.ai%2Fmcp%2Fservers%2FParallel-Solutions%2Fbitrix_mcp_free%2Fbadges%2Fshields.json)](https://glama.ai/mcp/servers/Parallel-Solutions/bitrix_mcp_free)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Parallel-Solutions/bitrix_mcp_free'

If you have feedback or need assistance with the MCP directory API, please join our Discord server