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

Annotations declare readOnlyHint=true and openWorldHint=true, so the safety profile is already covered. Beyond that, the description adds only the 'ALL bonds' scope note and says nothing about output format, pagination, or the inline-vs-CSV behavior. It contradicts nothing but also barely enriches the annotation baseline.

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 short sentence, front-loaded and waste-free. It is appropriately sized for a simple calendar endpoint, though the brevity leaves capability gaps noted elsewhere.

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 and no annotation-derived behavioral detail beyond safety, the description does not explain what an event record contains, how coupons/redemptions/offers are differentiated, or when results spill to CSV. For a six-parameter tool with an inline/CSV threshold, this is incomplete.

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 six parameters are documented in the schema itself. The description adds no parameter syntax, defaults, or format details beyond what the schema provides. Baseline 3 applies because 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?

The description states a clear resource (calendar of coupons/redemptions/offers for ALL bonds) and scope (per period), and distinguishes itself from siblings like moex_bondization and moex_bond_yields_history by being a date-range event calendar. However, it does not name a sibling tool it is not, which caps it below the 5 benchmark.

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 when-NOT-to-use, and no alternative tool named. An agent must infer usage purely from the resource type; sibling routing (e.g. vs moex_bondization) is left unaddressed.

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=true, so the safety profile is covered. The description adds useful context about the returned structure (e.g. value in rubles, None when undetermined, valueprc as percent), but discloses nothing about sourcing, pagination, or limitations beyond that. With annotations carrying the safety profile, 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 dense sentence that front-loads the resource and then enumerates return fields with their types. No wasted words, though the parenthetical detail is tightly packed.

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 usefully documents the three returned collections and their key fields, which is exactly what an agent needs to interpret results. The only gap is the absence of usage/routing context against the overlapping moex_bond_events sibling.

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 80%, with columns, filename, save_csv, and max_inline_rows all documented in the schema; only secid is undocumented but self-evident. The description adds no parameter detail at all, so the schema does the heavy lifting — 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?

The description states the resource clearly ('График платежей облигации' — bond payment schedule) and enumerates what it returns (coupons, amortizations, offers). It is distinguishable as a bondization/schedule fetch, but it never distinguishes itself from the sibling moex_bond_events, which plausibly overlaps with offers/amortizations. Clear resource, no sibling differentiation.

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 prerequisites, and no mention of alternatives such as moex_bond_events or moex_security. The agent must infer that this fetches a payment schedule purely from 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 declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the set of returned analytical fields (EFFECTIVEYIELD, DURATION, ZSPREADBP, GSPREADBP), which is genuine output context beyond the annotations, but it says nothing about pagination, row limits, or CSV side effects.

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 resource ('bond yield history') before the field list. No filler, though the column enumeration is dense and largely output-oriented.

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 7 parameters, no output schema, and only annotations covering safety, the description partially compensates by listing returned columns. But it omits usage routing against the many sibling tools and any behavioral notes on the CSV/max_inline_rows mechanics, leaving gaps for a data-export 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 86%, so the schema already documents nearly all parameters (date formats, columns filter, CSV options). The description adds no parameter-level meaning beyond the schema; its field list describes outputs, not inputs. 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?

The description names a specific resource (bond yield history) and enumerates the exact fields returned (TRADEDATE, PRICE, EFFECTIVEYIELD, DURATION, spreads), so an agent knows precisely what this tool produces. However, it does not distinguish itself from close siblings such as moex_history, moex_bondization, or moex_zcyc, which may also touch bond data.

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 or when-not-to-use guidance. The agent is not told to prefer this over moex_history for bond yield series, nor are any prerequisites (valid secid, date ordering) stated. Usage must be inferred entirely from the 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 declare readOnlyHint and openWorldHint, so the safety profile is covered. Beyond that, the description adds genuinely useful behavior: MSK timezone for all timestamps, the meaning of each interval code, and the non-obvious rule that weekend candles sit on Saturday/Sunday calendar dates. It omits pagination/limits, but for a read-only endpoint this is solid added 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?

Four short telegraphic sentences, each carrying a distinct fact (output columns, interval codes, timezone, weekend-date quirk) with zero filler and the most load-bearing info 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?

With 9 params and no output schema, the description usefully enumerates the returned OHLCV columns and explains interval and time semantics. It is nearly complete for calling the tool, though it says nothing about how secid/board identify a security or about result-size/CSV behavior beyond what the schema already states.

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 only 67%, and the biggest hole is interval, which the schema leaves as a bare integer with no description. The description fully compensates by decoding 1/10/60/24/7/31/4 into minute/hour/day/week/month/quarter, which is essential to call the tool correctly. Other params (secid, board, columns, filename) remain undocumented in prose, so it is not a full 5.

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 the exact resource (OHLCV candles) and enumerates the returned fields plus the interval units, so an agent knows precisely what data this yields. It stops short of an explicit verb and never contrasts itself with siblings like moex_trades or moex_quote, so differentiation is left to inference.

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 prefer this tool over the other 14 siblings (e.g., candles vs tick trades vs quotes vs history). Usage is only implied by the resource name, with no conditions, prerequisites, or exclusions given.

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=true, so the safety profile is covered. The description adds real behavioral context beyond that: data freshness (only up to the previous day), the special weekend-session-volume-merges-into-Monday rule, the extra bond fields (ACCINT, YIELDCLOSE, DURATION, COUPONPERCENT), and index support. It does not disclose pagination or the CSV-vs-inline cutoff 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?

The purpose is front-loaded and the dense enumeration of output columns and special cases (weekend aggregation, bond fields, indices) all carry information. It is a single, information-rich passage with little waste, though the long column list is somewhat heavy 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 9 parameters, no output schema, and 67% schema coverage, the description does well by explaining the returned columns, which compensates for the missing output schema. However it does not clarify the roles of undocumented params (board, all_boards, secid) nor route between the near-identical moex_history_by_date sibling, leaving meaningful gaps for a tool of this complexity.

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 67%, so most parameters (start, end, columns, filename, save_csv, max_inline_rows) are already documented in the schema. The description adds no parameter-level meaning — it enumerates return columns, not inputs — so the baseline of 3 is appropriate for the partially-documented 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 states a specific verb+resource: daily trading results (TRADEDATE/OPEN/HIGH/LOW/CLOSE/VOLUME etc.) for a security, with a clear scope of 'up to yesterday'. It is clearly distinguishable from moex_candles and moex_quote by the daily-bar granularity, but it never names the very similar sibling moex_history_by_date, leaving that distinction to inference.

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 rather than stated: 'up to yesterday' signals a historical daily-series use case and it notes it also works for indices (IMOEX, RGBI). However there is no explicit when-to-use vs moex_history_by_date/moex_candles, and no exclusions or prerequisites are given.

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=true, so the safety profile is covered. The description adds no behavioral context beyond that — nothing about the CSV fallback (save_csv/filename/max_inline_rows), inline-vs-file threshold, pagination, or response shape, all of which matter for a data-dump 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?

A single front-loaded sentence with no filler or repetition. It is efficient, though the brevity is part of why other dimensions are thin rather than a virtue in itself.

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 7-parameter query tool with no output schema, the description covers only the core scope. It omits the CSV output behavior and inline-row threshold that the schema parameters imply, leaving the agent to reconstruct the tool's output contract from parameter descriptions alone.

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 71% with 7 parameters. The description meaningfully ties the 'режим' concept to the market/board pair via the OFZ example (market=bonds, board=TQOB), which the bare schema does not explain. It says nothing about date format or columns, which the schema already documents.

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+resource: trading results (Итоги торгов) for all securities of a mode on a single date. The phrase 'всех бумаг ... за одну дату' implicitly separates it from moex_history (per-security history) and moex_market_snapshot, but it never names a sibling explicitly, so differentiation is left to inference.

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 gives one concrete worked example ('все ОФЗ: market=bonds, board=TQOB'), which shows an intended usage pattern and links the 'режим' concept to the market/board parameters. However, there is no explicit when-to-use / when-not-to-use guidance and no named alternative among the many sibling history/quote 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 and openWorldHint=true, so safety is covered. The description adds nothing behavioral: it says nothing about output shape (SECID/WEIGHT columns), CSV side effects, or the inline-row cap that the schema parameters imply. Given the lower bar with annotations, this is thin rather than contradictory.

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 line with the key information (composition + weights + supported indices) front-loaded and no filler. It is terse to the point of being a fragment, which slightly limits readability, but 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 six optional parameters and no output schema, the description should say more about what is returned (membership rows with weights) and how the CSV/inline-row options behave. It covers which indices are supported but leaves the return content 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 coverage is 83%, so the schema carries most parameter meaning. Crucially, the one undocumented parameter (indexid) is compensated for by the description enumerating the valid index identifiers (IMOEX, MOEXBC, RTSI, RGBI, sectoral), which is genuine added 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?

The description names the resource (index composition) and the payload (weights in %), and enumerates the covered indices (IMOEX, MOEXBC, RTSI, RGBI, sectoral), which cleanly separates it from siblings like moex_security or moex_quote. It is a noun phrase rather than a verb+resource sentence, and it never contrasts itself with those siblings, 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?

There is no explicit when-to-use guidance, no prerequisites, and no named alternative among the 14 sibling tools. The agent must infer that this tool is for index membership rather than for quotes or security metadata, so usage is only implied.

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=true, so the safety profile is covered; the description adds genuinely new behavioral facts: one row per security, that large results are spilled to CSV, and the ~3000-row / ~7s cost of the corporate-bond case. It does not explain pagination or exact CSV trigger semantics beyond the default, but the added context is meaningful.

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 core scope, then packed with concrete asset-class mappings and cost figures in a few dense sentences. Every clause carries information; the density is slightly at the expense of readability but 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 no output schema and 7 parameters, the description still covers the shape of the result (one row per security), the CSV fallback for large outputs, and the required market/board combinations. Return column semantics are left to the schema's columns parameter, which is acceptable given the ISS naming note.

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 only 57%, and market/board are bare strings in the schema, so the description does real work by supplying valid value pairs and the meaning of the index parameter (only the index base). The remaining params (columns, filename, save_csv, max_inline_rows) are already documented in 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+resource: it returns all securities in a trading mode with quotes, one row per security. The concrete market/board mappings (shares/TQBR, bonds/TQOB, bonds/TQCB) make the scope unambiguous, though it never explicitly names the siblings it differs from (e.g. moex_quote for a single security).

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 actionable routing guidance: which market/board combination to pick for stocks, OFZ, and corporate bonds, including the index=IMOEX caveat. It stops short of stating when NOT to use it or naming the better alternative for single-security lookups, so it is strong context rather than 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 readOnlyHint and openWorldHint, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the ~15-min delay (and the exception for indices), plus the distinct field sets returned for stocks versus bonds. It does not discuss rate limits or error 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-loaded with the core purpose and delay caveat, then a compact enumeration of returned fields. The field lists are dense but earn their place by telling the agent what comes back in the absence of an output schema. No filler 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 burden of describing returns, and it does so for both stocks and bonds, plus the delay caveat. It lacks guidance on choosing among sibling tools, which is the main remaining gap for a tool with 14 siblings.

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 every parameter is already documented in the schema. The description adds no syntax or format detail about secids, board, columns or the CSV-save options, 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 and resource: current quotes for one or more securities, and the fact that stocks, bonds and indices can be mixed. It does not explicitly differentiate itself from close siblings like moex_market_snapshot or moex_security, 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 implies when the tool is relevant (live-ish quotes) and discloses the ~15-minute delay, which shapes expectation. However it never names an alternative or a condition that routes the agent to moex_security, moex_market_snapshot or moex_candles instead.

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=true, so safety is covered. The description adds real behavioral context: all_block collects every page of a block, and the path must omit the /iss prefix and .json suffix. It still says nothing about auth, rate limits, or the response 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?

Three short, front-loaded fragments with no filler; the path rule and the all_block semantics are stated immediately. Nothing extraneous, though it is arguably too terse for a 7-param open-world 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?

With no output schema, 7 parameters, a nested params object, and openWorldHint=true, the description should say more about the return shape and what keys the params object accepts. It covers the hardest parameter (path) but leaves the response contract and the generic params bag unexplained.

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 only 57%, and the description compensates well for the critical undocumented path parameter by specifying the format and giving a worked example, plus explaining what all_block does. The remaining params (params object, columns, filename, save_csv, max_inline_rows) are left to 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 states a concrete verb+resource: fetch any ISS route, with the required path format and an example. It implicitly positions itself as the generic/raw escape hatch, though it never explicitly contrasts itself with the many specialized siblings (moex_quote, moex_candles, etc.).

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 — 'any ISS route' signals a general-purpose fallback — and the path format rule plus all_block example are actionable. However, with 14 siblings it gives no explicit when-to-use-this-vs-alternative guidance, which is the main gap for this kind of generic tool.

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 establish readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds non-obvious behavioral context beyond that: the search is fuzzy and results may contain multiple non-trading rows, with an explicit disambiguation rule. It does not mention rate limits 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?

Three dense sentences, front-loaded with purpose, then return shape, then the disambiguation rule. Every sentence earns its place, though the return-field list could be trimmed since it is partially derivable from the columns parameter.

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 correctly compensates by listing the returned columns, and it explains the fuzzy-match semantics. For a 9-parameter tool it leaves some parameter behavior (limit, only_trading, CSV routing) to the schema, but the core contract an agent needs is 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 coverage is 67%, and the description adds real value for the query parameter by enumerating the accepted identifier formats (ticker, name, ISIN, issue number, INN). It also relates to the columns parameter by naming default returned fields, but it says nothing about group, market, limit, or only_trading, leaving part of the surface unexplained.

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 identifier types accepted (ticker, name, ISIN, issue number, issuer INN) and the returned fields. This is clearly a lookup/discovery tool, distinct from moex_quote or moex_candles, though it never names a sibling to sharpen the contrast.

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 gives operational guidance on interpreting fuzzy results ("выбирай строку с is_traded=1 и совпадающим shortname/isin"), which is genuinely useful. However, it never says when to use this tool versus moex_security or moex_quote, so the routing guidance is only implied.

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=true, covering the safety profile. The description adds content scope (fields returned and boards/is_primary), but does not disclose pagination, rate limits, error behavior, or response format, so it only partially extends 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?

One compact sentence plus a short input clause. The security-card fields are front-loaded before the trading-modes detail, and every element serves a purpose.

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, open-world lookup with no output schema and five parameters, the description identifies the returned entity and its trading modes and clarifies the accepted identifier types. It omits CSV output behavior, but that is already covered by the schema's save_csv, filename, and max_inline_rows descriptions.

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 80%, with columns, filename, save_csv, and max_inline_rows documented in the schema. The description adds meaningful semantics for the required secid parameter by stating it accepts either SECID or ISIN, which the schema does not say.

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 what it returns: the security card (with ISIN, nominal, issue/maturity dates, coupon, bond type, listing level) and its trading modes (boards, is_primary). It does not explicitly contrast with siblings like moex_quote or moex_bondization, 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?

No explicit when-to-use, prerequisites, or alternative routing is provided. The input note 'Принимает SECID или ISIN' describes accepted keys but does not say when this tool should be chosen over moex_quote, moex_search, or moex_bondization.

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=true, so safety and external-network behavior are covered. The description adds meaningful context beyond that: a ~30s runtime estimate and the four diagnostic categories performed, which helps an agent decide whether the cost is worth paying.

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, front-loaded with the action and the diagnostic checklist, followed by the trigger condition. No filler; every clause 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 read-only diagnostic with four optional params and no output schema, the description explains what is checked and when to run it, but never says what the result looks like (a pass/fail report, a table, per-check status). Since no output schema exists, that gap falls on 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%, so the four optional params (columns, filename, save_csv, max_inline_rows) are already fully documented in the schema. The description adds nothing about them, 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 action (Самопроверка) and enumerates exactly what is verified: свежесть данных, согласованность роутов, полнота пагинации, пересчёт НКД и доходности. This clearly distinguishes it from the data-fetching siblings (moex_quote, moex_candles, etc.), which an agent can grasp 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 explicit when-to-use guidance: 'Запускай перед массовой выгрузкой или при сомнениях в данных.' Clear triggering conditions, but it names no alternative tool or when-not-to-use case, so it stops short of a 5.

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=true, covering the safety profile. The description adds nothing behavioral beyond that — no rate limits, no delay/data-freshness caveats for a live tape, no note on empty-session behavior. "newest first" is a return-ordering detail, not behavioral transparency.

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, purpose front-loaded, no filler. It is terse rather than padded, though the brevity also reflects under-specification.

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 an 8-parameter tool with no output schema and only 50% parameter documentation, the description is thin: it does not explain how the table/CSV split behaves, what board means, or what an empty current session returns. Adequate minimum but with clear gaps.

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 ~50%. The description supplies the semantics for latest ("N последних, новые первыми"), which the schema leaves undocumented, but board, secid and max_rows remain unexplained in both places. Baseline 3 is appropriate given partial schema coverage plus one genuinely useful parameter clarification.

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 resource (trades) with a scope qualifier (current session), which implicitly contrasts with moex_history/moex_history_by_date. However it never names a sibling tool to route the agent 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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as moex_candles or moex_history. The agent must infer that this is for intraday/current-session tape rather than historical data.

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 and openWorldHint, so the safety profile is covered. The description adds the returned shape (yearyields/params/securities) and date basis, but omits authentication, rate limits, and behavior when date is omitted.

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?

It is a single telegraphic sentence with the resource front-loaded. The colon-separated output hints make it feel fragmentary rather than fully structured for quick parsing.

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 must carry return context. It names three output sections but does not explain their structure, and usage/prerequisite context is absent, leaving meaningful gaps.

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 all five parameters are documented in the schema. The description only echoes the date concept and output field mapping; it adds no parameter-level meaning 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 the specific resource: zero-coupon OFZ yield curve (G-curve) and date scope. It does not differentiate from sibling endpoints such as moex_bond_yields_history or moex_history, but the resource itself is unambiguous.

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 guidance on when to choose this over moex_bond_yields_history or other yield-curve tools. There are no usage conditions, exclusions, or prerequisites.

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