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

With only readOnlyHint=true in annotations, the description carries the behavioral burden and handles it well: it discloses the calculation steps, the month-multiplier source, the special Yandex Delivery path, the exact returned quantities (month, day, percent above city median), and the rounding behavior. There is no contradiction with 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?

Four dense sentences, each carrying non-redundant information: formula, exception case, return values, and rounding. The most identifying information is front-loaded and no sentence is wasted.

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

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

For a 7-parameter tool with no output schema, the description explains the core calculation, the return payload, and rounding. It is not fully complete because transport semantics and the exact meaning/units of 'month' and 'day' are left implicit, and the fallback when a service does not publish a month factor is ambiguous.

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 only 29%, but the description compensates substantially: the formula gives meaning to hours, days, and service; the Yandex Delivery clause explains weekdays as the sum of selected days; and city is tied to median salary. The one notable gap is transport, whose role is not explained in either the schema or description.

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

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

The description opens with a specific verb and resource ('Считает доход курьера') and goes beyond a label by spelling out the exact formula, special service-specific formula, return values, and rounding rule. This clearly differentiates it from sibling tools like compare_services or recommend_service, which do not compute income.

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

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

The usage context is implied by the action and the service-type branch for Yandex Delivery, but the description never states when to choose calculate_income over alternatives such as compare_services or get_city_rates, and it gives no explicit when-not-to-use guidance.

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