utilization_summary

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

With no annotations provided, the description carries the full burden and meets it: it discloses that the tool aggregates across the entire team ('всей команды'), produces three specific metrics, and implies a non-destructive read/aggregation operation. For a 0-parameter summary tool there are no hidden side effects left undisclosed.

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?

Two compact sentences with no filler: the first front-loads the function and output metrics, the second adds usage boundaries. Every word earns its place.

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?

Given an output schema exists (so return values are covered structurally), 0 parameters, and the sibling context, the description is complete for correct selection and invocation: it states scope, outputs, usage context, and exclusion. Nothing an agent needs to call this tool 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?

The tool has 0 parameters and an empty schema, so the baseline is 4 per the rubric. There is nothing for the description to clarify about parameters; the schema trivially covers 100% of them.

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 uses a specific verb ('Посчитать' / calculate) with a clear resource (team workload summary) and enumerates concrete outputs: overloaded count, idle count, and average load. It also distinguishes itself from sibling search tools by stating it is not for finding a specific person.

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 description explicitly states when to use the tool ('для отчётов и обзоров' / for reports and reviews) and provides a clear when-not ('не для поиска конкретного человека' / not for finding a specific person), implying find_people as the alternative. It stops short of naming the sibling tool explicitly, which keeps it from a 5.

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