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

The description adds valuable behavioral context beyond the annotations: the step is 'ВСЕГДА выключенный' and 'до этого он ничего не делает', meaning it is created inert and only becomes active when the owner enables it in the dashboard. This is meaningful and not present in the annotations.

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

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

The description is dense and contains no filler, but it is structured as one long run-on paragraph with semicolon-separated clauses. This makes it harder to parse quickly. A structured list or clearer separation between event, action, and modifiers would improve readability.

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

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

The description covers most of the 13 parameters and the core behavior, but it omits lost_reason and does not describe what the tool returns or what happens after creation. With no output schema and no required parameters, the agent is left to infer some operational details.

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

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

Schema description coverage is 0%, so the description carries the burden of explaining parameters. It does well: it explains event choices (tag_id/stage_id), action choices (bot, tag_add, tag_remove, stage, task, goal), delay_minutes, skip_if_replied, and target fields, and even adds constraints like «Оплачено» нельзя. However, the lost_reason parameter is not mentioned at all.

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

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

The title "Собрать шаг правила продаж выключенным" and tool name create_sales_rule clearly indicate that the tool produces a sales-rule step, and the description emphasizes it is created in an always-disabled state. It is distinguishable from siblings like update_sales_rule and create_sales_stage, though the description itself never explicitly states a verb such as 'creates'.

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

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

No when-to-use guidance is provided. The description explains the structure of the rule but does not say when to use create_sales_rule versus update_sales_rule, list_sales_rules, or create_sales_stage, and it gives no exclusions or prerequisites.

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