advisor_weights

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

With no annotations, the description carries the full burden. It usefully discloses the Laplace-smoothed default (neutral weight when data is absent), which is real behavioral context. However, it says nothing about persistence of the updated weights, idempotency, permissions, or what the call returns, leaving meaningful gaps for a mutation-style calibration tool.

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?

Very compact and front-loaded: purpose first, then the record shape, then the default-behavior caveat. The telegraphic arrow notation ('→') and jargon ('петля U1') cost some clarity but nothing 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 single-parameter calibration tool with no output schema and no annotations, the description covers the input shape and the no-data fallback but omits the return value and any indication of side effects on stored weights. Adequate but not complete.

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 0% and the schema only declares 'records' as an untyped array, so the description must compensate. It does by giving the item shape: records=[{advisor,outcome,endorsed}], which names the three expected fields. It still does not define value types, allowed outcome/endorsed values, or how they are interpreted, so it is not fully self-sufficient.

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: it calibrates ('Калибровка') the council ('совета') using outcome data, and identifies the mechanism (loop U1, who was right for you → voice weight). This distinguishes it from generic siblings like calibrate or prediction_calibration. It does not explicitly name or exclude a sibling, so it falls short of a 5.

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 phrase 'кто был прав ДЛЯ ТЕБЯ' and the 'loop U1' label imply this runs after outcomes are known, but the description never states when to use it versus calibrate / prediction_calibration / pending_outcomes. It does note the fallback case (no data → neutral), which is useful but is behavior rather than usage routing.

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