Server Quality Checklist

Tool Scores

• get_market_dataC
  2.9/5.0
  Behavior2/5

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

  With no annotations, the description carries full responsibility for behavioral disclosure. It adds only the default market behavior and the word 'current' to imply real-time data. It does not mention that omitting security returns all securities, whether the data is delayed, how bid/ask is populated, or any rate limits. This is minimal disclosure for a data-access tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, tight sentence that front-loads the primary purpose and key data fields, followed by the default market scoping. There is no filler or redundant repetition of schema details.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has four optional parameters, no output schema, and no annotations, placing a high burden on the description. The description fails to explain what happens when parameters are omitted, what the response shape looks like, or how to combine this with sibling tools. It is minimally viable but not complete enough for an agent to confidently handle edge cases.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already documents all four parameters with 100% coverage, so the baseline is 3. The description adds no parameter-specific meaning beyond echoing the default engine/market values, which are already present as defaults in the schema. It doesn't explain edge cases like omitting security or board, so it doesn't elevate above baseline.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get'), names the resource ('market data for securities'), and enumerates the data fields (price, volume, bid/ask, change). This makes it clear what the tool returns and helps distinguish it visually from more specialized siblings like get_orderbook or get_recent_trades, though it doesn't explicitly name a competing tool.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The only usage hint is 'Defaults to stock/shares market,' which conveys the default engine/market but does not explain when to prefer this tool over alternatives such as get_orderbook or get_recent_trades. There is no explicit 'use this when' or 'use that instead' guidance, leaving the agent to infer selection criteria.

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

• get_recent_tradesC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description is the only behavioral disclosure. It reveals only that trades are recent, implying chronological ordering, but does not mention sorting, pagination, result shape, or any caveats—a meaningful gap for a data retrieval tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Single sentence with no filler; the core operation and object are front-loaded. It is concise, though the brevity comes at the cost of usage and behavioral context.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Adequate for a simple retrieval when combined with the fully documented schema, but the absence of an output schema and annotations leaves return shape and ordering unstated. It is minimally complete rather than fully self-sufficient.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema fully documents all five parameters. The description adds no parameter details beyond identifying the security dimension, so the baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  States a specific verb and resource ('recent trades') plus the target ('a security'), making its core function clear. It does not explicitly contrast with sibling tools like get_market_data or get_history, but 'trades' is a distinct resource, so an agent can infer what it does.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance on when to prefer this over get_market_data, get_orderbook, or get_history, and no mention of alternatives or exclusions. The agent must infer the appropriate use case from 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.

• get_bond_yield_curveB
  3.1/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden. 'Get' implies a read operation, but the description does not disclose return shape, pagination, default behavior, side effects, or other behavioral traits beyond the verb.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no filler. Every word contributes to the tool's purpose, and it is appropriately sized for a simple data-retrieval operation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a two-parameter read-only tool, the description conveys the core resource, but without an output schema it omits return-shape hints and usage context. It is adequate but not rich enough to fully guide an agent in selecting and invoking the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the baseline for this dimension is 3. The description itself adds no parameter-level meaning beyond what the schema already provides for 'date' and 'engine'.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb and resource: 'Get zero-coupon yield curve (ZCYC) data for bonds.' This is clear and distinguishable from most siblings, though it does not explicitly position itself against get_coupons or other bond-related tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no guidance on when to use this tool versus alternatives. The description does not mention conditions, exclusions, or related tools, so an agent must infer the appropriate context from the name alone.

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

• get_currency_ratesB
  3.1/5.0
  Behavior2/5

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

  There are no annotations, so the description carries the full burden of behavioral disclosure. 'Get' implies a read operation, but the description does not mention default-date behavior, response format, data source caveats, or any limiting conditions. It mostly restates the parameter semantics rather than exposing runtime behavior.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single well-structured sentence with no filler. The core action and resource are front-loaded, and the three rate types are enumerated compactly. Every phrase contributes useful information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple two-parameter read tool with complete schema coverage, the description is mostly adequate. However, with no annotations and no output schema, it leaves the agent without any indication of the response shape or behavioral details such as how the optional date is resolved. This is a moderate gap, not a severe one.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the parameters are already fully documented. The description adds marginal meaning by pairing each rate type with its source ('Central Bank of Russia', 'futures'), but this largely mirrors the schema's own descriptions and adds no new formatting or syntax details.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb and resource — 'Get currency exchange rates' — and further specifies three distinct rate types (MOEX fixing, CBRF, indicative futures rates). This is clear and unlikely to be confused with the generic market-data siblings, though it does not explicitly name or distinguish itself from a sibling alternative.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is given about when to use this tool versus alternatives, when not to use it, or which sibling might be more appropriate for other rate-related needs. The description implies a scenario where currency rates are wanted, but provides no explicit selection criteria.

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

• get_historical_candlesB
  3.1/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It only mentions the source endpoint ('the history endpoint') and gives no information about side effects, return format, default behavior, pagination, or prerequisites. The agent must infer most behavioral traits from the schema and tool name.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no wasted words. It loses one point for minor redundancy: 'historical' in the name is echoed in the description, and 'history endpoint' overlaps with the tool's purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with 7 parameters, no output schema, and a large set of overlapping siblings (get_candles, get_history, get_history_date_range), a one-line description is insufficient. It does not explain return values, default parameter behaviors, when board is required, or how this tool differs from nearby alternatives.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with all 7 parameters documented (from, till, board, engine, market, interval, security). The description itself adds no parameter-specific information, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and names the resource ('historical OHLCV candles over a date range') and the source ('the history endpoint'). It is clear on what the tool does, but it does not distinguish it from sibling tools like get_candles or get_history_date_range, which may also return candle/time-series data.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The intended usage is implicitly conveyed by 'historical' and 'date range' — this tool is for historical candle data over a time period. However, the description provides no explicit guidance on when to choose it over alternatives, nor does it mention any exclusions or conditions such as board requirements.

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

• get_historyB
  3.1/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full responsibility for behavioral disclosure. It reveals that the tool returns historical end-of-day data and defaults to stock/shares, but does not mention timezone handling, date inclusivity, pagination behavior, API limits, or what happens when optional date parameters are omitted.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two short sentences with no filler. The core purpose is stated first and the meaningful default behavior is front-loaded. Every word contributes to understanding.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with seven parameters and no output schema or annotations, the description conveys the primary purpose and defaults but leaves gaps about return structure, date inclusivity, handling of missing optional parameters, and differentiation from similar historical/candle tools. It is adequate but not rich enough to fully guide an agent without additional inference.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, and each parameter already has a description and defaults. The description adds the context that data is end-of-day and defaults to stock/shares, but does not clarify parameter relationships such as whether from/till are required for meaningful results or how limit interacts with the date range.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a clear action and resource: retrieving historical end-of-day trading data for a security over a date range. It mentions the default stock/shares context, which helps distinguish it from broader market data tools, though it does not explicitly name a sibling it differs from.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives only a minimal hint that it defaults to stock/shares, but provides no guidance on when to use this tool versus the many siblings such as get_history_date_range, get_historical_candles, or get_market_data. No exclusions or alternative conditions are stated.

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

• get_history_date_rangeB
  3.1/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden, and it does convey the core behavior: retrieving an available date range for a security. However, it does not disclose details such as whether the range is inclusive, what format dates take, how errors are handled, or what the exact return shape is. This is adequate for a simple getter but not richly transparent.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single clear sentence with no filler or redundant text. It is front-loaded with the action and resource, which makes it easy to scan, though it is a bit minimal for the full context an agent might need.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has no output schema and no annotations, and the description does not explain the relationship to the many historical-data sibling tools. An agent would know what the tool roughly does but would lack context about when to call it, what the returned range looks like, and how it fits into a workflow involving get_history or get_historical_candles.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so every parameter already has a meaningful description, including defaults for engine and market. The tool description adds no additional parameter semantics, but the schema handles the burden, keeping this at the baseline.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the operation ('get') and the specific resource ('available date range for historical data of a security'), so an agent understands what the tool returns. It distinguishes this from data-fetching siblings like get_history or get_candles by emphasizing the date range rather than the data itself, though it does not explicitly name those alternatives.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided about when to use this tool versus siblings such as get_history, get_historical_candles, or get_candles. The description implies it relates to historical data but does not state that this should be used to discover the valid range before fetching history, nor does it mention any exclusions or alternatives.

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

• get_index_analyticsB
  3.1/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden of behavioral disclosure, yet it only names the action and an optional response component. It does not describe what 'analytics' includes, how date or omitted index affects results, or what the output looks like, so an agent gets little transparency beyond the basic purpose.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is one focused sentence, front-loads the main action ('Get MOEX index analytics'), and appends only the optional differentiator and examples. There is no redundant phrasing or wasted detail.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple with only optional parameters and a 100% documented schema, so the description is minimally adequate. However, the key output concept 'index analytics' is vague and there is no output schema or return-type description, leaving a notable gap in what an agent should expect the call to return.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema fully documents date, index, and tickers. The description adds example index IDs and restates the composition-with-weights behavior, but does not materially extend the parameter semantics, warranting the baseline 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb and resource: 'Get MOEX index analytics' and 'optionally index composition with weights,' with concrete index examples (IMOEX, RTSI). This makes the tool's focus clear and distinguishes it from get_security_indices, which concerns indices associated with a security, though it doesn't explicitly draw that contrast.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives no guidance on when to choose this tool over sibling tools or when to set tickers=true versus false. The examples imply use for index-level analytics, but there is no explicit context or exclusion, leaving an agent to infer selection from the name.

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

• get_market_turnoversB
  3.1/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action and scope; it does not mention default date behavior, market aggregation semantics, read-only nature, or response characteristics. The description adds minimal behavior beyond the name and schema.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence that directly states the tool's purpose. There is no redundant phrasing, excessive detail, or filler. It is appropriately front-loaded and easy to parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is relatively simple with fully documented optional parameters, so the schema covers invocation details. However, there is no output schema and the description does not clarify what 'summary turnover statistics' includes (e.g., volume, value, number of trades). Context is adequate but has clear gaps in expected return semantics.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, meaning all three parameters (date, engine, market) are already documented in the schema. The description itself adds no parameter-level meaning. With maximum schema coverage, a baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific verb and resource: 'Get summary turnover statistics across MOEX markets.' It identifies the tool's domain without ambiguity. However, it does not explicitly distinguish itself from siblings like get_market_data, so it doesn't fully earn a 5.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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 get_market_data or list_markets. There are no stated conditions, exclusions, or context cues beyond the basic function. The usage context is left entirely to inference.

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

• get_futures_open_positionsB
  3.2/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full behavioral disclosure burden. It only restates the data resource and does not mention read-only behavior, default date/asset/market behavior, result shape, limits, or any other runtime traits. The operation's behavior is largely left to the schema defaults.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no filler, making it easy to scan and parse. It loses the top score because the slash construction 'open interest / open positions' is slightly redundant and some usage context would have made the description more useful.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple getter with three optional, well-documented parameters, the one-line description plus schema is minimally viable for selecting and invoking the tool. However, with no output schema and no annotations, the description leaves return format and behavioral expectations unstated, so completeness is only adequate.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema covers 100% of the parameters with meaningful descriptions, including defaults for date and market and the 'all assets' behavior of asset. The description adds no parameter-level detail, but the structured schema already carries that burden, so the baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and identifies a concrete data resource ('open interest / open positions') scoped to futures markets, which distinguishes it from generic siblings like get_market_data or get_history. It falls short of 5 because it does not explicitly name what it is not, and 'open positions' is slightly ambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use the tool: whenever futures open interest or open position data is needed. However, it gives no explicit when-not-to-use guidance, prerequisites, or alternatives among the many market-data sibling tools, so the applicability must be inferred.

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

• get_orderbookB
  3.3/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of disclosing behavior. It states the output is an order book with bid/ask depth, but does not mention whether the order book is aggregated, how many levels are returned, whether it is a snapshot, or any data-source or latency characteristics. For a tool with no annotation coverage, this is a notable gap.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no filler. It names the operation, the resource, and the key concept (bid/ask depth) efficiently.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is relatively simple and the schema covers parameter details, but the description does not explain how the optional board/engine/market fields affect the query, nor does it clarify return-value expectations since there is no output schema. It is minimally viable but leaves the agent to infer important context from parameter names alone.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the input schema already documents all four parameters with examples and defaults. The description adds no additional meaning about the parameters, such as how board/engine/market interact with security. Baseline 3 is appropriate given the high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb and resource: 'Get current order book (bid/ask depth) for a security.' It clearly identifies what the tool returns and its target input, but it does not explicitly differentiate it from sibling tools like get_market_data or get_recent_trades, which could also provide market-related data.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The word 'current' implies this is for real-time snapshots rather than historical data, giving some contextual guidance. However, there is no explicit when-to-use or when-not-to-use guidance, and no mention of alternative tools for historical or trade-specific queries. Usage is implied rather than clearly stated.

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

• get_candlesB
  3.4/5.0
  Behavior3/5

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

  With no annotations, the description carries the behavioral burden. It does disclose the read-only nature and OHLCV output shape, but it does not mention default date range behavior, timezone, ordering, pagination, or response format. This is acceptable but has clear gaps.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two short sentences with no filler; the main purpose is front-loaded and the interval guidance is compact.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Adequate for a simple read tool, since the schema documents all parameters and required fields. However, with no output schema and multiple overlapping sibling tools, the description leaves out defaults for from/till, response shape, and when to prefer this tool over similar history/candles tools.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  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 adds value by mapping interval values to calendar units ('24 for daily, 60 for hourly, 10 or 1 for minutes'), going slightly beyond the schema's generic 'minutes' wording.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  States a specific action and object: 'Get OHLCV candlestick data for a security.' This clearly identifies the data type and resource, and the interval sentence clarifies the granularity options. It does not explicitly distinguish it from siblings like get_history or get_historical_candles, 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.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance on when to choose this tool over sibling tools such as get_historical_candles or get_history. The 'Use interval=...' sentence is parameter-level advice, not tool-selection guidance, and no exclusions or alternatives are mentioned.

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

• list_boardsB
  3.4/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the responsibility for behavioral disclosure. 'List' implies a read-only operation, which is transparent about the core behavior, but it does not mention any permissions, rate limits, output format, or other side effects. For a simple list operation this is minimally sufficient but not comprehensive.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single short sentence that front-loads the action and object. Every word contributes meaning, and there is no redundant or filler content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple with two optional parameters, no output schema, and no nested objects. The description tells the agent what it returns (trading boards) and the key context (engine and market). It is mostly complete for this low-complexity tool, though the exact structure of a board is not described.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides descriptions and defaults for both engine and market, yielding 100% schema coverage. The description's phrase 'given engine and market' merely echoes the schema without adding new meaning. Baseline 3 is appropriate because the schema handles the documentation burden.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('list') and resource ('trading boards') with qualifiers ('for a given engine and market'), making the purpose clear. It doesn't explicitly name sibling tools like list_markets, but the scope is distinct enough that an agent can infer what this tool does.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no guidance on when to use this tool versus alternatives such as list_markets or get_market_data. The description implies that engine and market are needed, but does not state conditions, exclusions, or relationships to sibling tools.

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

• list_marketsB
  3.4/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It only restates the core operation and does not mention read-only behavior, pagination, ordering, possible empty results, or whether the engine parameter accepts a specific format beyond the schema default.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, front-loaded sentence with no filler. It starts with the action verb, names the resource, and states the scope in an efficient way.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple tool with one optional parameter and no output schema, the one-sentence description combined with the schema is largely sufficient to understand what the tool does and how to invoke it. It could be more complete with an explicit note about what a 'market' is or what the returned data looks like, but those are minor given the tool's low complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% for the single 'engine' parameter, including a default value, so the baseline is 3. The description adds no parameter details beyond what the schema already states, but it does align naturally with the 'engine' field.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('List'), a clear resource ('markets'), and a scoping constraint ('for a given trading engine'). It distinguishes itself from list_engines by operating on markets rather than engines, though it does not explicitly differentiate from sibling list_boards.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'available for a given trading engine' implies the tool is used when a caller already has an engine and needs its markets. However, there is no explicit guidance about when to choose this tool over alternatives such as list_boards or list_engines, and no exclusions are mentioned.

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

• get_couponsA
  3.5/5.0
  Behavior2/5

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

  With no annotations, the description carries the full behavioral burden, but it only says 'Get' and names the resource. It does not disclose return format, pagination, authentication needs, rate limits, or side effects; the verb does imply a non-mutating lookup, but little else.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no wasted words. 'Get coupon payment schedule for a bond' conveys the purpose and object clearly and compacly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single-parameter tool with full schema coverage, the description gives enough to select and invoke it. It does not describe the return structure, which is more noticeable because there is no output schema, but the simple input and explicit object keep it minimally complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, and the 'security' parameter is documented with a ticker example. The tool description adds only the bond context and does not materially enrich the parameter semantics beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description names a specific verb and resource: 'Get coupon payment schedule for a bond.' This clearly distinguishes it from sibling tools like get_dividends or get_bond_yield_curve by identifying a unique bond-specific schedule.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The usage context is implied: an agent can infer get_coupons is for bond coupon schedules rather than for dividends or yield curves. However, the description provides no explicit when-to-use guidance, exclusions, or named alternatives.

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

• get_security_infoA
  3.6/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden. It adds context by listing the kinds of fields returned and implies a read-only lookup. It does not mention any edge cases, whether data is live/reference, or error behavior, so it provides only basic transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  One sentence, front-loaded with the core action and resource, followed by concrete examples. Every word earns its place; no filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter getter with no output schema, the description gives enough to select and invoke the tool: it names the required input type (ticker) and the nature of the output (full specification with example fields). It does not explain the return structure or update/historical behavior, but that is a minor omission given the tool's simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already documents the single 'security' parameter with a description and ticker examples (100% coverage). The tool description does not add parameter-specific meaning beyond what the schema provides, so a baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get'), a specific resource ('full specification of a security'), and concrete examples of contents (ISIN, face value, issue date, trading boards). It is clear what the tool does, but it does not explicitly distinguish itself from sibling tools like get_security_indices or search_securities, so it stops short of full 5.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool should be used when a full reference specification for a ticker is needed, and the input schema clarifies a security ticker is required. However, there is no explicit when-not or alternative tool guidance despite the large sibling set, so the agent must infer usage.

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

• get_dividendsA
  3.8/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the burden of behavioral disclosure. 'Get' clearly signals a read-only operation and 'history' implies past data, but the description does not mention return format, ordering, pagination, or empty-result behavior. For a simple read-only tool this is a moderate, not severe, gap.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, focused sentence with no filler. It states the action and the object directly, making it easy for an agent to parse quickly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with one fully documented parameter and no nested objects, the description is largely sufficient. The return shape is reasonably inferable from 'dividend payment history,' though a brief note about the returned fields would make it fully complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already provides 100% coverage of the single parameter, including an example. The description adds no additional parameter-level detail, 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and a specific resource ('dividend payment history'), scoped to a security. 'Dividend' makes it clearly distinct from sibling tools like get_coupons and generic history tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The intended usage is implied: use this when you need historical dividend payments for a security. However, it does not explicitly mention when not to use it or point to alternatives such as get_coupons for coupon payments.

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

• search_securitiesA
  3.8/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden of behavioral disclosure. It communicates a read-only search operation, but it does not disclose whether matching is partial or exact, whether results are ordered, or what the response shape looks like. No destructive or side-effecting behavior is implied, which 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no filler. It immediately conveys the action, target market, and query types, leaving parameter details to the schema. This is an appropriate size for a search tool.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The 100% schema coverage covers all inputs, and the tool's purpose is clear. The main gaps are the lack of explicit return-value description and matching semantics, which are somewhat inferable from the word 'search' but would be more complete if stated.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the schema already documents all five parameters, including defaults and examples. The description adds minor reinforcement by naming the query types (ticker, name, or ISIN), but it does not provide meaningful parameter semantics beyond what the schema already offers.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the operation (search), the resource (securities on MOEX), and the search dimensions (ticker, name, or ISIN). This makes it distinct from data-retrieval siblings like get_security_info and market-data tools: this is the discovery tool, not a specific-record or market-data fetcher.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The intended use is implied: use it when you need to find securities by ticker, name, or ISIN. However, it does not explicitly say when to prefer an alternative such as get_security_info, nor does it give exclusions or conditions that would help route the agent away from this tool.

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

• list_enginesA
  3.9/5.0
  Behavior4/5

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

  With no annotations, the description carries the transparency burden. It clearly states the operation is a listing action covering all available engines, which conveys read-only behavior and broad scope. It does not detail output formatting or ordering, but for a zero-parameter list tool this is reasonably transparent.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no filler. Every word adds value by naming the action, the exchange, and the scope with illustrative categories.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a no-parameter, no-output-schema listing tool, the description is largely sufficient. It covers the essential context: what resource is listed and where. It could be more complete by clarifying the relationship between engines, markets, and boards, but this is not critical for invoking it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has no parameters, so the baseline is 4. The description correctly implies that no arguments are needed to call this tool.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('List') and resource ('all available trading engines on MOEX') with clarifying examples of engine types. It clearly identifies what the tool does, though it does not explicitly contrast it with sibling tools like list_markets or list_boards.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies that this tool should be used when an agent needs to enumerate available trading engines on MOEX. It provides clear context but gives no explicit guidance about when to prefer it over related siblings such as list_markets or list_boards.

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

• get_security_indicesA
  4/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It identifies the operation as a read-only lookup ('Get all indices'), which implies no side effects. However, it does not mention return format, potential error cases, or whether the result is a simple list of index names or full index objects, leaving some ambiguity.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, focused sentence with no filler. It front-loads the core action and resource, making it immediately clear to an agent what the tool does.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with one well-documented parameter and no output schema, the description states the essential outcome: retrieving indices containing a given security. It could specify the return type more explicitly, but overall it provides enough context for correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already provides complete coverage of the one parameter, including examples ('Security ticker (e.g. 'SBER', 'GAZP')'). The description adds no additional parameter semantics beyond the schema's existing explanation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and resource ('all indices that contain a given security'), clearly stating the tool's function. It is distinct from siblings like get_security_info or get_index_analytics because it focuses on index membership rather than security details or index analytics.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly conveys the use case: when you have a security ticker and need the indices that include it. While it does not explicitly name alternatives or exclusions, the context is unambiguous and the single parameter makes the invocation straightforward.

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