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

Annotations already cover read-only, idempotent, non-destructive behavior, so the bar is lower. The description adds source attribution (bik-info.ru based on the CBR database) and confirms no token/auth required, which are useful operational details 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?

Four compact sentences, front-loaded with what is returned, then use case, data source, and access mode. 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 single-parameter read-only lookup with rich annotations and a fully documented schema, the description covers what, why, source, and access mode. It does not describe the return shape, but with no output schema an agent gets only a partial picture of the response structure.

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 documents the 9-digit BIK pattern, so the description adds no parameter syntax, format, or domain detail beyond what the schema provides. 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+resource (returns bank details by BIK) and enumerates the exact returned fields (full/short name, correspondent account, city, address, ЦБ registration number). This clearly distinguishes it from siblings like validate_requisites or company_check, which deal with counterparty validation rather than bank directory lookup.

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 purpose context ('needed for filling payment orders and contracts') but offers no explicit when-to-use vs alternatives, no exclusions, and no routing to validate_requisites for BIK validation. Usage is implied rather than spelled out.

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 read-only, idempotent, open-world behavior, yet the description adds genuinely new facts: source is the CBR key-rate table on cbr.ru, no token required, one-hour cache, and that 'changes' contains only dates when the rate actually changed. That is substantive disclosure 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?

Front-loaded with the resource and its return fields, then usage routing, then provenance — logical order with little waste. Three clause-heavy sentences are dense but each carries information; slight redundancy in re-explaining the 2-year default.

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's enumeration of return fields (current_pct, as_of, since, changes) is essential and largely sufficient. Source, caching, and auth facts round it out; the only missing piece is how it differs from the other CBR rate 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 coverage is 100%, so from/to are fully documented in the schema, and the description's 'по умолчанию последние 2 года' simply echoes the documented default. The field enumeration describes outputs rather than inputs, so it adds no input-side semantics; 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 resource (ключевая ставка Банка России) and enumerates the returned fields (current_pct, as_of, since, changes), so the agent knows exactly what it gets. It does not, however, differentiate itself from the near-identical siblings cbr_rates and cbr_rate_history, which is the main clarity gap.

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 when-to-use (questions about the rate and its dynamics) and routes penalty/interest calculations to late_payment_penalty, explaining why that sibling is preferred. It omits any guidance against cbr_rates / cbr_rate_history, leaving the most likely sibling confusion unresolved.

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 the read-only/idempotent profile, and the description layers on non-obvious behavior: default 30-day window, business-day-only publishing so points < days, unknown-code error returning the available list, source cbr.ru, no token, one-hour cache. This is context the annotations cannot convey.

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?

Dense but well ordered: purpose, return shape, usage/alternatives, defaults, edge cases, provenance. Every sentence contributes, though the return-field enumeration and provenance clause make it longer than strictly necessary for selection.

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 return contract (points and summary fields) itself, and it covers defaults, error behavior, and data-source caveats. An agent has everything needed to call it correctly and interpret the result.

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 both optional parameters carry their own format/default docs, so the schema does the heavy lifting. The description restates the default-window behavior but adds no new syntax or constraint beyond it, 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 precise verb+resource: how the official CBR rate of one currency changed over a period, and even enumerates the return shape (points: date, per_unit_rub; summary first_rub/last_rub/min_rub/max_rub/change_pct). It explicitly contrasts with cbr_rates and currency_convert, so the agent can route without opening schemas.

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 concrete triggering questions ('как вырос доллар за месяц', graphs, picking a conversion date) and names the two alternatives with the condition that selects each: cbr_rates for a single date, currency_convert for amount conversion. No inference required.

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, idempotent and openWorld, so safety is covered. The description still adds real operational context: source cbr.ru, no token required, one-hour response caching, and the weekend/holiday behavior (date falls back to the last working day). However, it does not describe error or rate-limit behavior.

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-loads purpose, then alternatives, then return shape and operational notes in a logical order. Dense and information-rich, though slightly run-on with several clauses packed into single sentences.

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 return-value burden and does so: it enumerates date, rates (code, name, nominal, value_rub, per_unit_rub) and missing. Combined with the usage routing, an agent has everything needed to call it 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 coverage is 100%, so the baseline is 3. The description goes beyond the schema by explaining that omitting codes returns all ~50 currencies and that passing explicit codes is preferred, plus the per_unit_rub vs value_rub distinction for calculations.

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+scope: official CBR exchange rates for a single date. It explicitly names the two siblings it is not (cbr_rate_history for dynamics, currency_convert for conversion), so an agent can disambiguate without opening any 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 concrete when-to-use triggers (invoice, posting, report needing a rate for one specific day) and names the alternatives with the condition that selects them. Both exclusions and routing are explicit.

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, idempotent, openWorld and non-destructive, so the safety bar is low. The description adds real value beyond them: the no-token auth model and the fact that the number is checksum-validated before the call. It does not discuss rate limits or failure behavior on an invalid number, keeping it below 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?

Front-loaded with the returned dataset, then usage, then constraints. Dense but every sentence carries information; slightly overlong for a single-parameter tool 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 carries the return-value burden alone and does so thoroughly by listing the full field set. Combined with usage triggers, the ID constraint and the auth note, an agent has everything it needs to call the tool.

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 pattern already encodes accepted lengths, so baseline is 3. The description goes further by explaining the checksum pre-validation and clarifying that a name cannot substitute for the ID, which meaningfully reinforces the single parameter's semantics.

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 lookup key (ИНН or ОГРН), and enumerates the returned fields (name, ИНН, ОГРН, КПП, status, director, region, PDF link), so the agent knows exactly what it does. It does not, however, explicitly contrast itself with the closest sibling validate_requisites, so it falls short of the sibling-differentiation needed for 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 concrete trigger scenarios (before a deal, filling contract/invoice details) and a hard constraint that name search is unsupported, so only ИНН or ОГРН will work. It stops short of naming an alternative tool or stating when NOT to use it, so no explicit routing to a sibling.

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, idempotent, openWorld), yet the description still adds substantive behavior: the returned fields (rate as units-of-to-per-from, result rounded to kopecks, rate_date), the weekend/holiday fallback to the previous business day, and the fact that no token is required and the source is cbr.ru.

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 action and direction, then alternatives, then return values, then caveats. Dense but each sentence carries non-redundant information; 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 present, the description correctly absorbs the return-value explanation (rate/result/rate_date) plus rounding and weekend semantics. An agent has everything needed to call and interpret this tool.

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 goes slightly beyond the schema by explaining the cross-rate mechanism (через рубль) and the semantic meaning of the returned rate direction, though the date default ('по умолчанию сегодня') merely restates 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 opening clause states a specific verb and resource (пересчитывает сумму по курсу ЦБ) and immediately delimits scope: RUB↔валюта and cross-rate через рубль. It is trivially distinguishable from cbr_rates (rate only) and cbr_rate_history (dynamics), both of which it names 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?

Names the target use cases (счета, инвойсы, акты, отчёты), routes the agent to two alternatives by condition (нужен только курс → cbr_rates; динамика → cbr_rate_history), and states an exclusion (коммерческие курсы банков не учитываются). Nothing 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, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds that it gives a total plus a breakdown by rate period and that it is not a legal substitute, but says nothing about defaults behavior or rate-source assumptions beyond what is implied.

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 computation before the qualifying detail, plus a short disclaimer. Every clause earns its place, though the packing of legal sub-cases makes it heavy for one sentence.

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 calculator with no output schema, the description covers the algorithm, the method variants, and the return shape (total plus per-period breakdown), which is enough to call it correctly. Only minor gaps around default rate sourcing remain.

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 parameters are already documented. The description does add interpretive context for method and fraction (what art395 vs fraction mean, example denominators), but adds nothing about from/to/amount beyond the schema, so 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 and resource ('Считает неустойку за просрочку оплаты по ключевой ставке ЦБ') and pins the exact legal bases (ст. 395 ГК, доли ставки 1/300, 1/150), so an agent can distinguish it from the rate-lookup siblings like cbr_key_rate or cbr_rate_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?

Explains which method applies in which situation (art395 for statutory interest, fraction for utility/tax penalties for individuals at 1/300, organizations at 1/150 after 30 days) and adds a scope disclaimer ('Не заменяет юриста'). It does not explicitly route against sibling tools, but the usage context is concrete.

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 openWorldHint=false; the description reinforces this with 'офлайн-проверка' and 'не обращается к сети', and clarifies it validates checksums/format rather than existence. It does not describe the return shape, but for a boolean-style validator that is a minor gap.

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-loads what is checked, then the practical benefit, then the no-network caveat and the sibling routing. Every sentence earns its place with no 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 4-param validation tool with no output schema, the description is nearly complete: it covers inputs, offline behavior, and routing. It could mention that the result reports which requisite failed, but the expected valid/invalid outcome is largely implied.

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 format constraints beyond the schema (INN 10 and 12 digits, OGRN 13, OGRNIP 15, BIK 9 digits) and notes the account is checked jointly with BIK, which the bare param descriptions do not convey.

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 (проверка/validate) with the exact resources: ИНН, ОГРН/ОГРНИП, БИК, расчётный счёт, including digit-length scoping. An agent can immediately tell this is offline structural validation, distinct from company_check.

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?

Explicitly states the use case ('поймать опечатку до запроса в ФНС или отправки платежа') and names the alternative with its condition: 'чтобы узнать, существует ли компания, используйте company_check'. Nothing 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?

Beyond the annotations (readOnly/idempotent/non-destructive), it discloses non-obvious behavior: data source isdayoff.ru, no token required, one-day cache, and the failure mode when the next year's transfer decree hasn't been issued (typically autumn). These are exactly the operational traits an agent can't infer from 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?

The first sentence front-loads the resource and the mode split, then usage, then operational caveats. It is dense and somewhat long, but nearly every clause carries information; only the enumerated return-field list borders on verbose for a description.

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 must carry return-shape information, and it does for both modes. Combined with source, cache, auth, and error behavior, an agent has everything needed to call this correctly and interpret the result.

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, but the description adds real meaning: it enumerates what month produces (work_days, days_off, hours_40h_week, short_days, holidays_on_weekdays, working_weekends) versus what omitting it produces (year totals plus a 12-month table). That goes beyond the schema's terse 'Месяц 1–12' labels.

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 (Производственный календарь РФ) with scope qualifiers (федеральный, с переносами по постановлению Правительства) and the two modes (месяц/год). It explicitly names the sibling work_days_calc as the different tool, so an agent can distinguish them 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 concrete use cases (норма часов, зарплата, отпускные, графики) and names the alternative explicitly: to add N working days or count working days between dates, use work_days_calc. It also states the when-not condition — if next year's calendar isn't published yet, an error is returned.

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 readOnly/idempotent/destructive/openWorld, so the bar is lower, yet the description adds real context: holiday and transfer handling, the caveat that next year's calendar only exists after a Government decree, and that no token is required. It omits return-format/pagination behavior, but for a pure calculation tool 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?

Dense and front-loaded: the two operations are stated first, then the caveats and the read-only note. Every clause carries information; the only slight redundancy is restating the read-only trait that annotations already provide.

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-mode calculator with a fully documented schema and no output schema, the description covers the mechanics, the calendar data source, and its freshness limitation. What is missing is only the shape of the result, which matters less given the tool's simplicity.

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 baseline is 3 and the schema already explains every parameter, including the exclusion of the start day and the meaning of the operation enum. The description adds only the negative-N direction hint, which is largely implied by the -1000 minimum, so no lift above 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 states a specific resource (расчёт сроков в рабочих днях) and enumerates both operations, add and between, with their inputs. It is clear what the tool does, but it never differentiates itself from the sibling work_calendar, which is the most obvious overlapping alternative.

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?

Concrete use cases are given (срок оплаты, поставки, ответа на претензию; negative N to go backwards) plus a clear split between the add and between modes. There is no explicit exclusion or pointer to a sibling tool, so an agent gets context but no routing guidance.

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