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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds useful context beyond that: tasks come from the user and previous session, and unfinished items 'всплывёт снова' (will resurface again), implying persistent open-task behavior. It does not cover pagination, authentication, or return format, but the output schema handles returns.

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 three short sentences, front-loaded with the core purpose and usage timing. The phrase 'хвосты «Осталось»' is cryptic and less clear than the rest, but there is no redundant filler.

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

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

With an output schema present, the description need not explain return values, and readOnlyHint covers safety. The main missing piece is parameter semantics: project_id is required but undocumented in both schema and description. The workflow guidance around complete_task partially compensates.

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

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

The schema has one required parameter, project_id, with 0% description coverage, and the description never explains it. The phrase 'в этом проекте' implies project scoping but does not specify that project_id is the required integer identifier. The description fails to compensate for the schema gap.

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

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

The description clearly states that the tool returns 'Поручения тебе в этом проекте' (tasks assigned to you in this project), with sources including the user and the previous session. This is a specific verb+resource, though it does not explicitly differentiate from every sibling read tool such as read_journal or get_project_context.

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?

It gives explicit timing: 'Зови в начале работы и когда ищешь, чем заняться дальше' (call at the start of work and when looking for what to do next). It also names complete_task as the way to close finished items, providing a clear workflow. No explicit exclusions or alternative sibling routing are given.

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