Завершить задачу

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

Annotations only flag readOnlyHint=false, idempotentHint=true and destructiveHint=false; the description adds what they don't: the result becomes visible in the deal feed, the tool returns «completed», it requires AMOCRM_DOMAIN and AMOCRM_TOKEN, and the amoCRM 7 req/s limit is handled automatically. It further instructs the agent to show the user what will be written and obtain consent before mutating CRM data.

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?

Front-loaded with the core action, then id sourcing, the closure caveat, return value, auth/rate-limit facts, and the consent requirement — every clause carries information. It is slightly dense with several trailing operational clauses that could be tightened, keeping it just short of a 5.

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?

There is no output schema, so the description correctly supplies the return value («Возвращает completed») plus the auth prerequisites, rate-limit behavior, and the consent requirement for a mutation. Nothing an agent needs to invoke this correctly against the sibling set is missing.

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

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

Schema coverage is 100%, so the two parameters are already documented there and the baseline is 3. The description still adds value by specifying where the id must come from and by exemplifying the result text («Дозвонился, отправил КП»), which clarifies the expected content of the free-text result field.

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?

States a specific verb+resource: «Закрывает задачу по id с текстом результата», and immediately scopes it with an output example and the side effect («результат виден в ленте сделки»). An agent can distinguish it from siblings like crm_create_task or crm_tasks without opening any schema.

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?

Names the sources for the required id («id берите из crm_tasks или crm_get_lead») and states an explicit exclusion («Закрытую задачу этим инструментом не открыть»), so both when-to-use and when-not-to-use are covered. It also routes the agent toward a confirmation step before writing.

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