pob_check_build

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. Beyond that the description discloses the report's sections and an honest limitation (targets does not validate build legality), which is useful context. It says nothing about output format, size/verbosity despite calling itself 'подробный', or behavior on an invalid/empty build.

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, the content list is front-loaded and the caveat closes the definition, with no filler. Density comes at some cost of readability, since the noun stack ('камни/ошибки, предметы/неподдержанные строки') requires interpretation.

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 one optional parameter, no output schema and read-only annotations, the definition supplies the report's content inventory plus the key limitation, which is most of what an agent needs. Remaining gaps are how the target build is selected (no build identifier parameter is mentioned) and the return format.

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 description coverage is 0%, so the description must carry the parameter burden. It does add real meaning for `targets` (it compares numbers against goal values, and is not a legality check), which the bare `stat`/`min`/`max` schema does not convey. However, it never explains what valid `stat` keys/units look like or the 100-item cap, leaving the most error-prone part undocumented.

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 states a concrete verb+resource ('Подробный отчёт Lua') and enumerates the report's content areas (stats, conditions, gems/errors, items, slots, nodes, warnings), so an agent knows this is a read-only detailed dump rather than a mutation. It also scopes the `targets` feature ('сравнивает числа с целями, не доказывает легальность сборки'). It stops short of naming which build it reports on relative to siblings like pob_node_tooltip or pob_catalog.

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?

Usage is only implied: the shape of the description suggests 'call this to get a full diagnostic report of a build', and the closing clause sets a boundary (targets does not prove legality). There is no explicit 'use this instead of X when Y' and no statement of prerequisites, e.g. that a build must be loaded/imported first.

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