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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, so the safety profile is covered. The description's qualifier 'потенциально аффилированных' adds a useful uncertainty caveat, but nothing about result size, confidence, or data freshness. With annotations carrying the main load, a 3 is appropriate.

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?

Single compact sentence with the resource front-loaded and qualifiers appended. No waste, though the nested parenthetical and dash clause make it slightly dense.

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-param read tool with annotations and no output schema, the description covers the core purpose adequately. However, it does not state return format (list of INNs only? names? relationship types?), scope limits, or result count caps, leaving some ambiguity for the agent.

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 100% and the single param 'inn' has a rich schema description (pattern, 10/12-digit meaning, disclaimer). The description adds no param-level detail. Baseline 3 when the schema does the work.

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 resource (связанные ИНН) and clarifies the relationship type (совместное владение/руководство), plus the parenthetical explains it returns potentially affiliated persons/entities. Distinguishable from siblings like org_lookup, though it doesn't name a rival tool directly.

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?

Implied usage: given an INN, find affiliated IDs. But no explicit when-to-use vs alternatives like org_lookup or check_* tools, and no exclusions. Adequate but assumes the agent infers the scenario.

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