egrul.org

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so safety is fully covered. The description adds useful context about the data source (CBR daily ED807 directory) but does not describe rate limits, authentication needs, or what happens on failed lookups.

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?

A single sentence front-loads what the tool is (BIK directory) and then states its capabilities (search by BIK or name). Every element earns its place with zero redundancy or filler.

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 simple two-parameter lookup tool with no required arguments, full annotation coverage, and no output schema, the description adequately conveys the source and search options. It could mention what fields are returned, but an agent can reasonably infer bank details and the omission is minor for this complexity level.

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%: both bik and name have clear descriptions that state format and matching behavior. The tool description only restates that search can be by BIK or name, adding no new meaning beyond what the schema already provides, so the baseline of 3 applies.

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 names a specific resource (BIK directory of Russian banks) and a specific action (search by BIK or bank name), clearly distinguishing it from sibling tools that check sanctions, disqualified persons, etc. An agent can immediately tell what this tool does without opening the schema.

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 implies usage by stating the two search criteria (BIK or bank name), but it does not explicitly say when to use this tool versus alternatives such as org_lookup or get_reference. No when-not conditions or prerequisites are given, leaving the agent to infer context.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered by structured data. The description's addition of the external registry name (Федресурс) corroborates the open-world nature but adds little else — no mention of data latency, coverage limits, or result meaning. Adequate but thin against an already-annotated 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?

One compact sentence with the resource and lookup key front-loaded and zero filler. 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, read-only registry lookup with 100% schema coverage and no output schema, the description is largely sufficient. It could state what the check yields (bankruptcy presence/records) to be fully self-contained, but nothing needed to invoke it 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?

Schema description coverage is 100% and the single 'inn' parameter is fully documented in the schema (10 digits for organizations, 12 for individuals). The description only restates 'по ИНН', adding no format or edge-case detail. Baseline 3 is appropriate when the schema does the heavy lifting.

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 ('Проверка') plus the resource ('Единый федеральный реестр сведений о банкротстве / Федресурс') and the lookup key ('по ИНН'). That is enough to separate it from siblings like check_sanctions_org or check_disqualified, though it never names an alternative explicitly.

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?

Gives no when-to-use, when-not-to-use, or alternative guidance beyond the implied name. An agent gets no signal, for example, about whether this covers both legal entities and individuals or how it relates to the disqualified/sanctions checks in the sibling set.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, destructiveHint=false, so the safety profile is covered. The description adds that this is a registry check rather than a document verification, but says nothing about result semantics, latency, or rate limits, so it contributes only modest extra context.

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?

One dense sentence with the resource stated first and the input distinction last; nothing is wasted. It is slightly cramped by the dual org/person clause but remains readable.

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 check with full schema coverage and safety annotations, the definition is nearly sufficient — the only real gap is that the return value (disqualified or not) is not characterized and no output schema exists to cover it.

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 single inn parameter is fully documented in the schema, including the 10/12-digit meaning and the note that it is a public registry number. The description only restates the digit-count rule, adding no semantics beyond the schema.

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?

Names a specific verb (проверка) and resource (реестр дисквалифицированных лиц ФНС), and specifies the two INN forms it accepts, which implicitly separates it from the by-name and by-person siblings. However, it never explicitly distinguishes itself from check_disqualified_by_org_name or check_disqualified_by_person, leaving that inference to the reader.

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 implied by the input contract: use when you have a 10- or 12-digit INN. There is no explicit when-to-use/when-not-to-use statement and no pointer to the related sibling tools for name-only or person lookups.

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

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

The annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the useful behavioral detail that matching is exact-name rather than fuzzy, but says nothing about hit semantics, ambiguity handling, or rate limits beyond that.

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?

A single, front-loaded sentence with no filler; the purpose leads and the sibling disambiguation is parenthetical. It is appropriately sized, though it carries no formatting or structural aids.

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 one-parameter lookup with full schema coverage, annotations covering the safety profile, and no output schema, the description supplies purpose, exactness, and alternative-routing context. What an agent needs to invoke it correctly is essentially present.

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% and there is only one parameter, so the schema already documents org_name. The phrase 'по точному наименованию' reinforces the exact-match requirement, which is meaningful but adds little beyond the schema description 'Точное наименование организации'.

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 names a specific verb (Проверка = check), a specific resource (реестр дисквалифицированных лиц ФНС = FNS register of disqualified persons), and a precise scope (по точному наименованию организации = by exact organization name). It also explicitly positions itself as a variant of check_disqualified, so an agent can distinguish it from that sibling without opening a schema.

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?

It names the alternative (check_disqualified) and the exact condition that selects this tool over it — cases without ИНН. This is an explicit when-to-use rule tied to a named sibling, leaving the routing decision unambiguous.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds genuinely useful behavioral semantics beyond that: the match must be exact and the year only tightens the match. It says nothing about hit format or pagination, but for a registry lookup that is minor.

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?

One dense parenthetical sentence that leads with the resource and match key before the optional qualifier. No filler.

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?

A read-only lookup with four fully documented parameters and no output schema; the description supplies the matching semantics an agent needs. Nothing critical is missing, though spelling/case normalization for 'точное совпадение' is left unstated.

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%, so baseline is 3, but the description adds meaning the schema does not: all three name fields are matched exactly, and the year is a secondary refinement rather than a required filter. That changes the agent's expectation of results.

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 concrete verb (проверка), the exact resource (реестр дисквалифицированных лиц ФНС) and the matching key (по ФИО), which cleanly separates it from the sibling check_disqualified_by_org_name. An agent can pick it without opening a schema.

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 implied by the matching rule (exact ФИО match, optional birth year) but there is no explicit when-to-use or when-not-to-use guidance and no alternative is named. Adequate, not generous.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful context about the authoritative data source (Росфинмониторинг terrorist/extremist list), but says nothing about what a result looks like or how matches are reported, which is a real gap for a boolean-style check with no output schema.

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?

A single front-loaded sentence with zero filler; the resource and the key parameter are stated immediately.

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 simple one-parameter read-only lookup whose schema and annotations are complete, the description is minimally adequate. However, with no output schema it never explains what the check returns (hit/miss, match details), leaving a gap an agent would want filled.

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%: the single 'inn' parameter already carries type, required flag, a 10-digit pattern and a description. The description only restates "по ИНН" without adding format, normalization, or error-handling detail, so the baseline 3 applies.

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 names a specific verb (проверка) and resource (организация по перечню террористов и экстремистов Росфинмониторинга) plus the key input (ИНН), making the purpose unambiguous. It implicitly distinguishes itself from check_fedsfm_person via "организации", but never explicitly routes against the many other check_*_org siblings, 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 description provides no when-to-use guidance, no exclusions, and does not name any alternative (e.g., check_fedsfm_person, check_sanctions_org). The intended usage is only inferable from the tool name and its registry-specific wording.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description usefully adds that matching is by full name plus year of birth and is an exact match, but says nothing about what is returned or how a hit is represented.

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?

A single, front-loaded sentence with no padding; the list name and the matching rule are the only two facts given and both earn their place. It is slightly terse for a screening tool, keeping it from a 5.

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?

With safety covered by annotations and no output schema to explain, the description gives the essentials: what is checked and how matching works. It omits how negative versus positive results are surfaced, which would be the only remaining helpful addition.

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%, so individual parameters are already documented (baseline 3). The description adds meaning beyond the schema by stating that the four fields (ФИО + год рождения) are combined and that matching is exact, clarifying how the parameters must be supplied together.

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 (проверка/check), a specific resource (физлицо/individual), and the exact list (Росфинмониторинг terrorists/extremists). The word 'физлицо' implicitly separates it from check_fedsfm_org, but no sibling is named explicitly, 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 stated scope (individual + terrorist/extremist list) implies when the tool applies, but there is no explicit when-to-use, no exclusions, and no reference to alternative person-screen tools such as check_sanctions_person or check_mvd_wanted. Usage is left to inference.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description contributes only the point-in-time nature of the result ('на дату'); it says nothing about permissions, rate limits, or what the returned status values mean.

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?

A single front-loaded sentence with a clarifying parenthetical for 'самозанятого'; no filler or redundancy. Every element (subject, key, date scope) 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?

There is no output schema and no annotation describing the return, so the description could have stated what status outcomes to expect (e.g. is/is not registered as self-employed). For a two-parameter status lookup this is a noticeable but minor gap.

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 format of inn (12 digits) and date (yyyy-mm-dd, defaults to today) is fully documented in the schema. The description merely restates 'по ИНН физлица на дату', adding no syntax or interpretation beyond it, which is the expected baseline.

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 names a specific resource (статус плательщика НПД / самозанятого), the lookup key (ИНН физлица) and the temporal scope (на дату), so the agent knows exactly what is checked. It does not explicitly contrast itself with any sibling, but no other check_* tool covers the self-employment registry, so confusion risk is low.

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?

There is no statement of when to use this tool versus the many sibling check_* tools (налог, банкротство, санкции, дисквалификация) nor any prerequisite or exclusion. The agent must infer from the name alone that this is the self-employed-status check.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral fact — that the comparison is an exact match on full name plus birth year, so partial/fuzzy lookups will not hit — but says nothing about cost, rate limits, or result semantics.

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?

A single compact sentence with the query target front-loaded and no filler. It is efficient, though the parenthetical could have carried more routing value for the same length.

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 simple four-parameter read lookup with full annotation coverage and no output schema, the description is minimally sufficient. It nevertheless omits the one thing an agent most needs in this dense family of check_* tools: how this FSIN wanted-list differs from check_mvd_wanted and when each applies.

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%, with each of the four required fields documented in the schema itself, so the baseline is 3. The description only restates the parameter set ('ФИО + год рождения') and adds the exact-match qualifier, without contributing format or validation detail beyond the schema.

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 gives a specific verb ('Проверка') and a precise resource ('база розыска ФСИН России'), so the agent immediately knows what is being queried. It does not, however, explicitly distinguish itself from the very similar sibling check_mvd_wanted, which an agent could easily confuse it with.

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 by naming the database and stating the matching rule (ФИО + year of birth, exact match). There is no explicit when-to-use/when-not guidance and no pointer to check_mvd_wanted as the alternative wanted-list lookup, so the agent must infer the choice between the two.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is fully covered. The description adds only that the source is the Минюст foreign-agents register, which is useful context but discloses nothing beyond that (no result semantics, no rate/coverage caveats). With annotations carrying the behavioral 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?

A single front-loaded sentence with zero filler that conveys verb, resource, register and input method. 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?

For a one-parameter read-only lookup with full schema coverage and clear annotations, the definition is essentially sufficient, and no output schema means return values need not be explained. It only lacks an explicit pointer to check_inoagent_person for the person-register counterpart.

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% and the single parameter is documented with type, a 10-digit pattern, and a Russian description; the description merely restates 'по ИНН'. Baseline 3 applies since the schema does the heavy lifting and the description adds no format or syntax detail beyond it.

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 (организация) and the exact register (реестр иностранных агентов Минюста РФ), plus the key input (по ИНН). An agent can immediately distinguish it from the individual-lookup sibling check_inoagent_person without opening the schema.

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 scoping phrase 'по ИНН' and 'организация' implies this is the register lookup for organizations, which is adequate for a simple lookup tool. However, there is no explicit when-to-use guidance and no mention of the natural alternative, check_inoagent_person, for individuals, so routing is left to inference.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds one genuinely useful behavioral trait, 'точное совпадение' (exact match, no fuzzy matching), but says nothing about the result shape or how a match is reported.

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?

A single front-loaded sentence with no filler; the registry identity and match semantics come first. It is terse rather than padded, though it could afford one more clause about output.

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?

With no output schema, the description carries the burden of explaining what a check returns (found/not found, any associated data), and it does not. For a screening tool feeding compliance decisions, that is a noticeable gap, though the input contract is fully covered.

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%, so all four parameters are documented in the schema itself. The description restates the same input tuple (ФИО + год рождения) without adding format, normalization, or matching-rule detail beyond 'exact'. Baseline 3 applies.

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?

Names a specific verb (Проверка), resource (реестр иностранных агентов Минюста РФ), and entity type (физлица), which implicitly separates it from the sibling check_inoagent_org. It does not explicitly name that sibling, so it falls just 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 description gives no when-to-use guidance or alternatives; the exact-match requirement and the input combination are implied by the parenthetical. An agent can infer this is a name-based screening check, but routing versus check_sanctions_person or check_fedsfm_person is left to the tool name alone.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile and external-registry nature are covered. The description adds the specific source registry, but says nothing about what the check returns (e.g., presence/absence or attached details), which would be useful behavioral context.

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?

A single, front-loaded sentence that identifies the action and the exact registry used. No filler or redundancy.

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 one-parameter read-only check with annotations covering safety, the essentials are present. However, with no output schema, the description could state what a positive/negative result means, which would make it complete for an 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 description coverage is 100% and the single parameter already documents the 10-digit (organization) / 12-digit (individual) format and its meaning. The description adds no parameter-level detail beyond the schema, so the baseline of 3 applies.

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 names a specific verb (проверка/check) and resource (ИНН) against a clearly identified data source (реестры ФНС «Недействительные ИНН»). This distinguishes it reasonably from other INN-adjacent siblings like lookup_inn_by_passport or bik_lookup, though it does not explicitly contrast with them.

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 implied by the purpose: use it to validate whether an INN appears in the FNS invalid-INN registry. There is no explicit when-to-use/when-not guidance and no named alternative tool for related lookups, leaving routing to inference.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the meaningful data-source context (a corruption-liability register under Art. 19.28), but says nothing about result format or what a hit/miss means.

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?

A single compact sentence that front-loads the register's legal basis and ends with the lookup key. No filler, though the dense legal phrasing makes it slightly harder to scan than a two-part purpose/usage split.

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 one-parameter, fully documented read-only lookup with annotations carrying the safety profile, the description is sufficient to invoke it correctly. Only the shape of the returned result is unaddressed, and no output schema exists to cover that.

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 parameter's pattern and meaning (10 digits = organization, 12 = individual) are fully documented in the schema. The description only repeats 'по ИНН' and adds no format or validation detail beyond the schema, so baseline 3 applies.

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 names a specific action (проверка/check), a precisely identified resource (the register of legal entities held liable under Art. 19.28 КоАП РФ for corruption offenses), and the lookup key (ИНН). This clearly separates it from generic company lookups, though it does not explicitly contrast itself with neighbouring registers such as check_fedsfm_org or check_inoagent_org.

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: run a check against this specific register by INN. There is no statement of when this register is the right one versus the many other check_* registers, nor any prerequisite or exclusion guidance.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the exact-match requirement (full name + year), which is useful behavioral context, but it does not describe return values, authentication needs, or rate limits.

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 description is a single front-loaded sentence with no filler. It immediately states the operation, the database, and the exact matching rule.

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 simple read-only lookup with full schema coverage and annotations covering safety, the description is nearly complete for invocation. Its main omission is that it does not say what the check returns (e.g., found/not-found or record details), but without an output schema this is a minor gap.

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%, and all four required parameters (lastname, firstname, middlename, year) are documented in the schema. The description reinforces that these together form an exact-match query, but adds no syntax or format 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?

States a specific verb and resource: checking an individual against the Russian MVD wanted database, with the matching criteria (full name + year of birth, exact match). It is clear enough to separate from most generic lookups, but it does not explicitly distinguish itself from the sibling check_fsin_wanted, 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 description gives no when-to-use or when-not-to-use guidance and does not mention alternatives, even though a closely related sibling tool (check_fsin_wanted) exists. Usage is only implied by the tool's purpose, which is insufficient routing guidance.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that only active/current suspensions are returned, which is useful behavioral context, but it does not describe auth needs, rate limits, or return shape.

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?

A single front-loaded sentence with no wasted words; the scope ('действующие') and resource are stated before the input qualifier.

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 simple one-parameter check tool with annotations already covering safety, the description is adequate but does not explain what a return value looks like (e.g., whether empty means no blocks or what data fields are present). No output schema exists, so some return-shape guidance would improve completeness.

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 parameter (inn) is fully documented in the schema with pattern and meaning. The description only repeats 'по ИНН' without adding format or validation details beyond the schema.

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 (current suspensions of account operations / FNS account blocks) and scope (действующие) with the input (по ИНН). It is clear what the tool retrieves, though it does not explicitly contrast itself with sibling check_* tools.

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?

No indication of when to use this tool versus alternatives, no prerequisites, and no mention of related checks. The agent must infer usage entirely from the tool name and resource wording.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, covering the safety profile. The description adds only the data source (zakupki.gov.ru), which is identity context rather than behavior — nothing about auth needs, rate limits, or what a hit/miss looks like.

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?

A single front-loaded sentence with zero filler, and the register/purpose leads before the parameter. It is efficient, though its brevity borders on under-specification rather than true conciseness.

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 one-parameter, read-only lookup with annotations covering safety, the description is minimally adequate. With no output schema, it says nothing about the result shape (e.g. whether a supplier is listed), which is the main thing an agent would want to know before calling.

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 inn parameter's pattern and 10/12-digit meaning are documented in the schema itself. The description only echoes 'по ИНН', adding no syntax or format detail beyond the structured field, so the baseline 3 applies.

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 (Проверка — check) and a named resource (реестр недобросовестных поставщиков / РНП ЕИС at zakupki.gov.ru) plus the keying parameter (по ИНН). This is clearly distinguishable in kind from unrelated siblings like bik_lookup or currency_rate, but no sibling (e.g. check_zakupki_org, which is also zakupki-related) is explicitly differentiated.

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 function statement implies the use case (vetting a supplier against the RNP), but there is no explicit when-to-use, when-not-to-use, or routing to any alternative registry check (check_zakupki_org, check_sanctions_org, etc.). No guidance is given for when this register is the right one to consult.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description usefully clarifies what the registry actually contains (the kinds of interim measures and their legal basis), which is genuine added context, but says nothing about authorization, rate limits, or result shape.

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?

A single compact sentence with the resource front-loaded, followed by the enumerated measure types and statutory references. Nothing is wasted, though the legal citations have modest value for an agent choosing a tool.

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 one-parameter read-only lookup this is broadly sufficient, and the description does convey the domain of the returned data. It stops short of describing the response (e.g. presence/absence semantics or matched-record fields), which matters somewhat since no output schema exists.

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% and the single parameter is already fully documented (10 digits for organizations, 12 for individuals), so the schema carries the load. The description only echoes the lookup key via 'по ИНН' and adds no new constraint or format detail beyond it.

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 names a specific resource — the FNS register of interim measures (обеспечительные меры) keyed by ИНН — and enumerates its contents (pledge, seizure of property, prohibition on alienation) with legal citations. It is clearly a registry lookup, distinct in substance from the other check_* siblings, though it never explicitly contrasts itself with them.

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?

There is no explicit when-to-use guidance, no statement of preconditions, and no routing to any alternative sibling tool. The scope is only implied by the registry's subject matter, so the agent must infer that this tool answers 'are there tax-authority interim measures against this INN?'

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so safety and externality are covered structurally. The description adds that the search spans international lists (a useful data-source hint), but says nothing about match output, timeout/latency, or behavior when no hits are found. With annotations carrying the behavioral 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?

A single sentence, front-loaded with the action and scope, with the input key at the end. Nothing is redundant and no filler is present.

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 one-parameter read-only lookup with full schema coverage and annotations covering safety, the definition is nearly sufficient. It does not describe the shape of a result (hit/miss, matched list, entity details) and no output schema exists to fill that gap, which is the only real omission.

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% — 'inn' is documented as a 10-digit organization tax number with a regex pattern. The description's 'по ИНН' reinforces the required identifier but adds no format or validation detail beyond the schema, so the baseline 3 holds.

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 specific verb and resource ('Проверка организации по международным санкционным спискам') and enumerates the concrete sources covered (OFAC, EU, UK), which is real information beyond the tool name. The word 'организации' implicitly separates it from check_sanctions_person, but no sibling is named explicitly, so it stops 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?

Usage is only implied: an agent can infer this is the sanctions screen to run on a legal entity before counterparty onboarding. There is no explicit when-to-use, when-not-to-use, or routing to alternatives such as check_fedsfm_org or check_sanctions_person, so the minimum-viable level applies.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds real behavioral context — the listed data sources and that name matching is exact-by-alias — but says nothing about return format, confidence/matching threshold, or rate limits.

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?

A single dense sentence that is front-loaded with the core action, followed by the input alternatives. Efficient, though the parenthetical list of sources and repeated digit constraints make it heavier than strictly necessary.

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?

Covers scope, sources and accepted inputs, which is adequate given five optional parameters and no nested objects. However, with no output schema the description leaves the return shape and what counts as a hit (exact alias match only?) unexplained, which an agent would need.

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 schema already calls INN optional when name+year are supplied, so the baseline is 3. The description goes slightly beyond by laying out the OR relationship between the two input paths and stating the exact-alias matching rule that governs the name fields.

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?

Names a specific verb (проверка) and resource (физлицо по международным санкционным спискам), enumerates the covered lists (OFAC, EU, UK, ООН) and the two lookup keys. The 'физлицо' scoping cleanly distinguishes it from the sibling check_sanctions_org.

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?

Implies when to use it by describing the two accepted input modes (INN or name+year), but gives no explicit when/when-not guidance and names no alternative (e.g., check_sanctions_org for organizations). Usage must be inferred from the sibling list.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so safety is covered. The description adds genuine behavioral scope beyond that: a result cap (up to 100 latest notices) and the role condition (organization as customer OR participant). Return format and empty-result behavior remain undescribed, keeping it short of a 5.

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?

A single, front-loaded sentence that packs source, filter, result limit, and role scope with zero filler. 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?

With a single parameter, full annotation coverage, and no output schema, the description supplies the essential context: data source, filter, result cap, and role scope. It could note whether an empty list is possible or that the org must exist in EIS, but it is largely complete for this simple lookup.

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 single parameter has 100% schema description coverage, including the 10/12-digit format, so the schema carries the semantics. The description adds no syntax or format detail beyond what the schema provides, matching the baseline 3 for high-coverage cases.

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 names a specific resource and data source (procurement notices of EIS / zakupki.gov.ru) filtered by INN, and states the scope of the result set. The verb is implicit (retrieve/list) rather than explicit, but an agent can immediately tell what data this returns. No sibling covers procurement notices, so no sibling differentiation is required.

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 implied by the purpose (checking an organization's procurement activity via its INN) but there is no explicit when-to-use statement and no named alternatives or exclusions. Since no sibling overlaps with this data source, the gap is mild, but the description does not actively guide selection.

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

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

Annotations already declare readOnlyHint, openWorldHint and destructiveHint, so the safety profile is covered. The description adds real context beyond that: the data source is the Central Bank of Russia and the tool covers precious metals as well as currencies. It still omits things like date-boundary behaviour or weekends/holidays, so it stays adequate rather than rich.

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?

A single tight sentence that front-loads the resource and ends with the temporal scope. No filler, no repetition of the title.

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 two-parameter read tool with annotations and full schema coverage, the description is minimally sufficient. With no output schema, a brief note on the returned shape (rate value, nominal, date) would have helped, and the code vocabulary ('USD, EUR, XAU и т.п.') is only in the schema, not the description.

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% – both 'code' and 'date' are documented in the schema, including the yyyy-mm-dd format. The description adds nothing beyond the schema, so the baseline 3 applies.

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 (returns the rate) and resource (CBR currency/precious metal rate) scoped to a date. It is unambiguous which sibling it is versus the check_*/lookup_* family, though it never explicitly names an alternative. Clear purpose, but not differentiated as sharply as a top-tier 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?

Usage is only implicit: the name and the 'на указанную дату' phrase signal 'call this to fetch an official rate for a date'. There is no explicit when-to-use, when-not-to-use, or alternative guidance (e.g. live rate vs. historical, or which codes are valid).

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false. The description adds a useful behavioral warning that the response may be large because full classifiers are returned, which is valuable beyond the annotations.

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 sentences, both earning their place: the first states what is returned, and the second warns about response size. The description is compact and front-loaded.

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 simple one-parameter reference retrieval tool with rich schema coverage and annotations, the description covers the returned data and the large-response caveat. It lacks detailed output structure, but no output schema exists and the classifiers are well-known reference datasets.

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%, and the enum fully documents all valid values. The description largely repeats the enum list, though it does clarify that account_codes means financial statement line codes, adding slight value beyond the schema.

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-like operation (return/открытые справочники) and resource (classifiers), then enumerates the exact classifiers available. An agent can tell this apart from sibling lookup/check tools without opening the schema.

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?

Implies usage for retrieving static reference/classifier data, and the enum parameter makes the selection clear. However, it gives no explicit when-to-use vs alternatives or exclusions relative to sibling lookup tools.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds meaningful context beyond that: the external FNS dependency and a data-handling/consent constraint that annotations cannot express.

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 sentences, zero filler, with the core purpose front-loaded and the constraint following. Nothing extraneous and nothing important buried.

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 read-only external lookup with full schema coverage and no output schema, the description covers purpose, required inputs, source, and legal/ethical limits. It could briefly note what is returned (the INN) but is otherwise 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 100%, so every parameter (including formats and the 10-digit passport pattern) is already documented. The description only restates the same fields (ФИО, паспорт, дата рождения) without adding syntax or format detail, matching the baseline 3.

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: obtain an individual's INN from passport data via the FNS service. It clearly distinguishes this from the many sibling check_* tools, though it never names a sibling explicitly. Purpose is unambiguous to an agent.

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?

Gives explicit usage conditions: requires exact personal data and must be used only with the person's consent or on their behalf, and not for surveilling third parties. This covers when-to-use and when-not-to-use, but names no alternative tool for adjacent needs.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered structure-side. The description adds the meaningful scope constraint that only the caller's own account subscriptions are returned and identifies the notification fields exposed (notify_url, notify_email), which is useful context beyond the annotations but does not describe return shape or pagination.

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?

A single sentence that front-loads the resource (monitoring subscriptions) and then the secondary payload (notification settings). No filler, no repetition of the title.

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 parameterless read-only listing tool with no output schema, the description covers scope (own account) and the fields returned, which is sufficient for an agent to call it correctly. It could be slightly stronger by stating whether all subscriptions or only active ones are returned.

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 takes zero parameters, so the baseline is 4 per the rubric. The description correctly implies no filtering input is required, and there is no parameter documentation gap to compensate for.

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 names a specific verb (list) and resource (monitoring subscriptions plus notification delivery settings), so an agent knows this is the read-side counterpart to monitoring_subscribe/monitoring_unsubscribe/monitoring_set_notify. It does not explicitly name those siblings, but the read-only 'list' framing makes the distinction inferable.

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 implied by the phrase 'current subscriptions (own account)', which suggests this is for inspecting existing state rather than creating or modifying it. However, there is no explicit 'use this when... instead of monitoring_set_notify' guidance or mention of prerequisites.

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

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

Annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=false) cover only the safety profile; the description adds real behavior: empty string disables a channel and the first webhook enable returns notify_secret, the HMAC-SHA256 key for the X-Signature header. It does not state whether an existing secret is re-issued or how to rotate it, but the mutation and secret-generation semantics are well disclosed.

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?

Three dense sentences, front-loaded with the action and the two channels, then the disable convention, then the non-obvious side effect. No filler or repetition.

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?

With no output schema, the description compensates by naming the key return value (notify_secret on first webhook enable). It lacks detail on what happens when both fields are empty, whether the secret is retrievable later, and the exact response shape, but it is sufficient for an agent to invoke the tool correctly.

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%, so both parameters are already fully documented in the schema (URL format for POST, empty string to disable). The description adds only the webhook/email role mapping and the empty-string convention, matching the baseline 3 for schema-documented params. The returned notify_secret is a return value, not a parameter, so it does not lift this dimension.

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 specific verb and resource: configuring the monitoring notification delivery channel, with the two concrete mechanisms (webhook notify_url, email notify_email). It is clear what the tool does, but it never distinguishes itself from the related monitoring_subscribe / monitoring_unsubscribe / monitoring_list 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?

It explains the disabling convention ('пустая строка отключает канал'), which is useful operational guidance, but gives no when-to-use context relative to the other monitoring tools and no prerequisites for having a subscription first.

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

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

With readOnlyHint=false declared, the agent knows this is a write operation; the description adds material behavioral context beyond annotations: notification cadence (3x/day), the fact that notify_url/notify_email are configured elsewhere, and the quota rule (1 INN = 1 daily request). It stops short of describing reversibility, duplicate handling, or return payload.

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?

Front-loaded with the purpose and event list, then a second sentence carrying operational facts (notifications, quota). Dense and informative, though the long enumeration of event types and the parenthetical config note make it heavier than strictly necessary.

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 write tool with no output schema, the description covers purpose, tracked events, notification delivery, the config sibling, and the quota cost — enough to invoke it correctly. The main remaining gap is what the subscription returns or how failures/duplicates behave.

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%, so the schema already documents all three parameters (including the event and xml_tags value lists). The description adds no syntax or format detail beyond the schema, so the baseline 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?

States a specific verb ('Подписаться на мониторинг') plus the exact resource and enumerates the concrete event classes tracked (EGRUL/EGRIP extract changes, financial statements, FSSP proceedings, tax debts, etc.). It also names the configuration sibling monitoring_set_notify, so an agent can distinguish it from monitoring_list/unsubscribe without opening a schema.

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?

Implies the when-to-use context (ongoing change tracking) and explicitly routes notification setup to monitoring_set_notify, which is a useful alternative pointer. It does not state when to prefer this over monitoring_list or how it relates to monitoring_unsubscribe, so it stops short of full when/when-not guidance.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, but the description adds the crucial consequence beyond them: the action is irreversible and the filter settings of those subscriptions are permanently lost. That is precisely the 'what gets destroyed' information an agent needs before committing to a destructive call.

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?

A single sentence, front-loaded with the action and scope, with the destructive warning appended directly after. Every clause earns its place and nothing is padded.

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 one-parameter destructive mutation with no output schema, the description plus annotations cover the essentials: scope, bulk mode, and irreversibility. It stops short of noting error behavior for invalid or already-unsubscribed INNs, which is a minor but real gap.

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% and the single parameter's schema text already explains comma-separated INNs and the "all" sentinel. The description repeats the same "all" convention without adding syntax, limits, or failure semantics, so the baseline 3 applies.

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 (отписаться) and resource (мониторинг) plus the exact scope of operation: named INNs or everything via inn="all". The destructive inverse relationship to monitoring_subscribe is unambiguous from the name alone, so an agent can distinguish it from its monitoring siblings without opening the schema.

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 clearly establishes the two usage modes (specific INNs vs. "all" for a bulk unsubscribe), which is the decision an agent actually faces here. It does not, however, explicitly name monitoring_subscribe or monitoring_list as alternatives, nor state any when-not condition, so it falls short of full routing guidance.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the returned entity type (ИНН list) but says nothing about result volume or pagination — relevant for a daily nationwide registration listing that can be large — and adds no constraints beyond what annotations and schema provide.

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 short sentences with zero padding; the core scope (date-registered ИП INNs) is front-loaded and the optional region filter follows immediately.

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 read-only, two-parameter listing tool with a fully documented schema, the description is adequate in scope but omits practical context an agent would want: whether results are paginated, roughly how many records to expect, and any date-range limitation. No output schema exists, so the return shape rests entirely on the single phrase 'Список ИНН'.

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%, and the schema itself gives rich semantics, especially the region code explanation (КПП digits for organizations, ОГРНИП digits for ИП, not ИНН). The description only restates the region filter at a high level and contributes no additional parameter meaning, so baseline 3 is correct.

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 specific verb and resource: 'Список ИНН ИП, зарегистрированных в ЕГРИП за указанную дату' — the agent knows it retrieves INNs of sole proprietors registered on a date. It implicitly separates itself from new_organizations by naming ИП/ЕГРИП, but it never names any sibling (e.g. updated_entrepreneurs, new_organizations) to sharpen the distinction.

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 implied by the 'registered on the given date' scope, and the second sentence signals optional region filtering. However, there is no explicit when-to-use guidance and no routing against close siblings such as updated_entrepreneurs or new_organizations.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds only the scope of the result set (INN list per date) and adds nothing about result size, limits or freshness — adequate but thin.

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 short sentences, front-loaded with what is returned and then the optional filter — no wasted words.

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 two-parameter read-only list tool with full schema coverage and no output schema, the description is minimally sufficient, but it omits any indication of return volume, pagination or how INNs are ordered — relevant because a full-day EGRUL extract can be very large.

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%: both `date` (yyyy-mm-dd) and `region` (2-digit code, КПП/ОГРНИП semantics, all regions when omitted) are fully documented in the schema. The description only echoes the region filter, so baseline 3 applies.

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: the list of INN of organizations registered in EGRUL on a given date, plus an optional region filter. An agent can distinguish it from sibling check_* tools and from new_entrepreneurs/updated_organizations, though those siblings are never named.

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 implied by the phrasing ('registered on the specified date', 'can be filtered by region'), which conveys context but no when/when-not guidance and no explicit routing to siblings like updated_organizations or search_organizations.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so safety is covered. The description adds a non-obvious behavioral trait: the response is limited to file names, not file contents — an important expectation-setter beyond the structured fields.

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?

One front-loaded sentence with the core purpose first and the scope-limiting caveat in a compact parenthetical. No wasted words.

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?

With one fully documented parameter, no output schema, and annotations covering safety, the description is nearly complete — it even discloses the return shape (names, not contents). Minor gap: no mention of volume, ordering, or empty-result behavior.

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% and the single INN parameter is fully documented with a digit pattern in the schema. The description merely repeats the INN scoping without adding format or interpretation detail, so the baseline 3 applies.

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 (list) and resource (accounting-reporting files of an organization) scoped by INN, which cleanly separates it from data-returning siblings like org_financials. It does not, however, name any sibling it should be preferred over or paired with.

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 parenthetical explicitly sets a boundary: the tool returns file names only, and file contents must be fetched via the site's external file access rather than this tool. That is real when-not-to-use guidance, though no alternative MCP tool is named.

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

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

Annotations already declare readOnly/openWorld/non-destructive, so safety is covered. The description adds real behavioral context beyond them: results are paginated with one org having thousands of versions, and the response includes total and has_more. It stops short of describing ordering beyond the offset note, but it meaningfully enriches the annotation profile.

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?

A single dense paragraph, front-loaded with what the tool returns before the workflow advice. Every clause carries information, though the run-on structure could be split for faster scanning.

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?

No output schema exists, and the description compensates by naming the response fields (total, has_more) and the per-item content, plus the pagination strategy and the hand-off to org_filing_snapshot. Nothing an agent needs to call or chain it 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?

Schema description coverage is 100%, so limit, offset and inn_or_ogrn are already documented, including the oldest-version offset semantics. The description restates the pagination workflow but adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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 and resource: it lists historical versions of the ЕГРЮЛ/ЕГРИП extract for an org/ИП, and names exactly what each item carries (version date and xml_file_id). It also explicitly separates itself from the sibling org_filing_snapshot, so an agent can route without opening either schema.

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?

Gives an explicit trigger ('вопросы про историю изменений', e.g. all directors/founders over time) and a concrete workflow: fetch the version list here, page through with offset if needed, then inspect individual versions via org_filing_snapshot. When-to-use and the alternative are both stated.

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

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

Annotations already declare readOnlyHint/openWorldHint/destructiveHint=false, so safety is covered. The description adds real behavioral context beyond them: omitting section returns the entire filing and 'может быть большой', while section bounds the payload. Return shape details remain thin, but the safety profile is already carried by annotations.

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?

Front-loaded with what the tool returns, then mode semantics, then an actionable workflow hint. Every sentence earns its place; slightly dense and untranslated but no filler.

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?

No output schema exists, so the description should carry return-value information; it states the output is structured JSON and warns it can be large, and annotations cover the safety profile. Adequate, though the shape of the parsed JSON is only named, not characterized.

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%, so the baseline is 3; the description nonetheless adds meaning by naming concrete Cyrillic section tags (СвУчредит, СведДолжнФЛ, СвАдресЮЛ, СвОКВЭДОсн) and glossing what each contains, which goes beyond the schema's terse examples.

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?

Names a specific verb (returns parsed content) plus resource (one historical version of an EGRUL/EGRIP filing) and explicitly ties xml_file_id to the sibling org_filing_history, so an agent can distinguish it from the history-list tool without opening either schema.

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?

States the two modes (whole filing vs a single section) with the tradeoff noted, and gives an explicit multi-step workflow for the common goal of collecting all owners over time by iterating versions from org_filing_history with section=СвУчредит.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds value by disclosing the upstream source (FNS/Rosstat) and the nature of the data, but it says nothing about coverage limits, latency, or what happens when data is unavailable.

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?

A single well-formed sentence that front-loads the resource and follows with the scope and source. Nothing is wasted, though it is minimal enough that it could have carried one more clause of guidance without bloat.

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?

With no output schema, the description should ideally indicate the shape of the return (per-year financial fields). It gestures at this with '(revenue, taxes, etc.)' and the source, which is adequate for a read-only lookup, but the 'etc.' leaves the returned field set underspecified.

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%: both inn (10-digit pattern) and year (optional, all years if omitted) are fully documented in the schema. The description adds no parameter meaning beyond it, so the baseline of 3 applies.

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 names a specific resource (financial reporting of an organization by year) with clear examples of the fields returned (revenue, taxes) and the data source (FNS/Rosstat). This makes the tool's function clear without opening the schema. It does not, however, explicitly distinguish itself from overlapping siblings such as org_accounting_files or org_filing_history.

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?

There is no when-to-use guidance, no stated alternatives among the many org_* siblings, and no exclusions. The agent can infer this retrieves financials, but nothing tells it when to prefer this over org_accounting_files, org_filing_history, or org_rating.

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

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.

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

Annotations already declare readOnlyHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds value by specifying the returned data fields (including 'signs of unreliable information') and noting it is a brief card, which tells the agent this is a lightweight lookup rather than a full report.

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 description is a single, front-loaded sentence that states the tool's purpose, required input, and returned fields with no wasted words.

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 simple read-only lookup with full schema coverage and no output schema, the description is largely complete: it names the source registers, the identifier, and the returned fields. It could mention edge cases (e.g., invalid INN, not found), but those are handled by sibling tools.

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%, and the schema itself explains the INN (10/12 digits) and OGRN/OGRNIP (13/15 digits) formats in detail. The description only restates the identifier types without adding further semantic detail, so the baseline of 3 applies.

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 specific resource (organization or individual entrepreneur from EGRUL/EGRIP) and the identifier used to find it (INN or OGRN), plus the exact fields returned (name, address, status, signs of unreliable information). This clearly distinguishes it from specialized sibling checks like check_bankrot_org or org_financials, though it does not explicitly name an alternative tool.

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 gives no guidance on when to use this tool versus alternatives such as search_organizations or the many check_* tools. It only implies that an INN or OGRN is required, but offers no context on when this lookup is preferable.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safe-read profile is covered. The description usefully adds that the ranking is dimensional (industry/region, per-year), but says nothing about return shape or ranking source, which is left implicit.

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?

A single front-loaded sentence that defines the resource and its dimensions with essentially no waste. Only slightly terse given the terse-but-complete phrasing.

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 low-complexity two-parameter read tool with annotations covering safety, the description is adequate. With no output schema, it could clarify what a 'position' result contains (rank value, period, source), so it is complete enough to invoke but not fully explanatory.

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%, so both 'inn' (10-digit pattern) and the optional 'year' are fully documented in the schema. The description only echoes the year scoping ('по годам') without adding format or semantics beyond the schema, so the baseline 3 applies.

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 clearly: the organization's position in a turnover-based company ranking, scoped by industry/region and by year. An agent can tell it apart from financials or lookup siblings, though it does not explicitly name which sibling to prefer for adjacent needs.

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?

Gives no when-to-use guidance, no exclusions, and no alternative tools (e.g. org_financials for raw turnover figures). Usage is only implied by the resource name.

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

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

Annotations already cover the safety profile (readOnly, non-destructive, openWorld). The description adds genuinely non-structured behavior: anchor/prefix matching semantics, a hard cap of 20 results, and a cost model billed per record found with a minimum of 1, which an agent needs before calling.

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?

A single dense sentence-pair that front-loads the matching semantics, then the parameter requirement, then the result cap and cost. Every clause carries information an agent needs; no filler.

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?

With no output schema, the description still conveys cardinality (max 20) and cost, and annotations carry safety. Combined with 100% schema coverage, an agent has enough to invoke correctly; only explicit sibling routing 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?

Schema coverage is 100%, so baseline is 3; the description lifts this by clarifying that matching is from the start of the string, and reinforces the 'at least one param' rule that the schema does not enforce. It stops at 4 because it doesn't add per-parameter nuance beyond the already-detailed schema strings.

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 ('Поиск организаций') and the exact matching fields (name prefix, email, region), and explicitly rules out full-text search by specifying prefix/anchor matching. It does not name a sibling (e.g., org_lookup, new_organizations) to disambiguate, so it stops 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?

Gives a real usage constraint — at least one parameter is required and parameters can be combined — which is clear operating context. However, it never says when to prefer this over org_lookup or the check_* tools, so alternative-selection guidance is absent.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, destructiveHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral clarification (the date is the extract date, not the registration date), but says nothing about result size, pagination, or ordering of the returned INN list.

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?

A single tight sentence with the scope and the date-semantics caveat front-loaded; every clause carries information and nothing is padding.

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 simple read-only list endpoint with two fully documented parameters and no output schema, the description covers what the tool returns and the key date caveat. It is close to complete, with only the contrast against the 'new' siblings left to inference.

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% and the region semantics (2-digit code, КПП digits for orgs, ОГРНИП digits for ИП, default all regions) are fully documented in the schema. The description only restates that region filtering is optional, adding no meaning beyond the structured fields.

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 scope: a list of ИП INN whose ЕГРИП extract changed on a given date, and usefully clarifies that the date is the extract date, not the registration date. It never names the sibling it contrasts with (new_entrepreneurs, updated_organizations), so an agent must infer 'updated' vs 'new' from the wording alone.

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 mentions that results can be filtered by region, which implies how to narrow a call, but gives no explicit when-to-use / when-not-to-use guidance and does not route the agent to new_entrepreneurs or updated_organizations.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered structurally. The description adds the meaningful clarification that the date refers to the extract date rather than the registration date, but says nothing about result volume, pagination, or ordering for what can be an open-world, potentially large result set.

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 tight sentences with the core purpose front-loaded and the date-semantics caveat parenthetically attached; no filler. Slightly less than ideal only because the region mention is redundant with the schema.

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?

No output schema exists, but the description tells the agent the payload is a list of INNs, and annotations cover the read-only safety profile; for a 2-parameter read tool this is nearly sufficient, with pagination/volume being the only notable omission.

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% and the schema itself richly documents both parameters, including the region code semantics (КПП digits for organizations, ОГРНИП digits for ИП). The description only repeats that region filtering is possible and that date is the extract date, adding little beyond the schema, so the baseline 3 applies.

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: returns the list of INNs of organizations whose EGRUL extract changed on a given date. The word 'организаций' implicitly separates it from the entrepreneur-oriented siblings (updated_entrepreneurs, new_entrepreneurs), but no sibling is named explicitly, so an agent still has to infer the boundary versus new_organizations.

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 only usage-relevant sentence clarifies which date to pass ('дата выписки, не регистрации'), but there is no guidance on when to choose this tool over siblings such as new_organizations, search_organizations or updated_entrepreneurs, and no stated prerequisites or exclusions.

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