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

Annotations carry only readOnlyHint=true, and the description adds substantial behavioral context beyond it: tiered quota limits (anonymous 20/50, free key krsp_ 100/200, paid unlimited), the exact error signal on quota exceedance ('вернёт isError с инструкцией'), and auth acquisition details. Even with annotations lowering the bar, this disclosure of rate limits, auth needs, and failure behavior exceeds the minimum.

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?

The definition is dense but organized: core purpose and field list lead, followed by the exclusion, the use case, and the quota/error contract at the end. Every sentence conveys needed information, though the field enumeration is long and the quota section is verbose; it earns its place but is not maximally lean.

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 read-only lookup with no output schema, the description compensates well by enumerating return data, exclusions, quotas, and error behavior — an agent can decide to call it and anticipate the response. It remains short of 5 because the absence of an output schema leaves the exact response structure and any pagination/format of 'свежие извещения' undescribed.

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 100%: the inn parameter already carries a pattern (10 or 12 digits) and a Russian explanation of legal-entity vs individual-entrepreneur. The description reinforces 'по ИНН' but does not add any formatting, syntax, or validation detail beyond the schema, so the baseline of 3 is appropriate.

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+resource ('Публичный профиль заказчика по ИНН') and enumerates the concrete data fields (name, KPP, registration number, notice counts, contract sums, OKPD2 structure, fresh notices). It further differentiates from siblings with the explicit exclusion 'Поставщиков не отдаёт' and a clear positioning as a quick-overview tool, so an agent can distinguish it from the many search_* and get_* siblings.

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 states its intended use case ('Подходит для быстрой оценки «кто это и сколько закупает»') and provides a when-not/negative constraint ('Поставщиков не отдаёт'), which signals when to look elsewhere. It falls short of a 5 because no alternative sibling is explicitly named with a routing condition, leaving the agent to infer which sibling covers supplier data.

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