Server Quality Checklist

Tool Scores

• company_eventsC
  2.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 doesn't mention date range behavior, how far back events go, whether it's historical or upcoming events, or the return format. For a data retrieval tool with no annotation safety profile, 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.

  Conciseness4/5

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

  The description is a single concise sentence with no wasted words. It's slightly under-specified, but for its length it's efficient and front-loaded with the 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?

  An output schema exists which covers return value documentation, but the tool has no annotations and the description doesn't clarify the event types fully (the 'etc.' is vague). The source parameter has unclear semantics between VCI and KBS. For a moderately complex data tool, the description leaves meaningful gaps about scope and data coverage.

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

  Parameters2/5

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

  Schema description coverage is 100%, so both parameters have descriptions. However, the source parameter's values (VCI vs KBS) are not explained beyond listing them, and the description adds no context about what the different sources mean or when to choose each. With 100% coverage the baseline is 3, but the source semantics are materially under-specified.

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

  Purpose3/5

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

  The description states the tool gets company events and lists examples (dividends, AGM, earnings), which gives a specific verb+resource. However, it doesn't distinguish this from siblings like company_news or company_overview, and the generic 'etc.' leaves scope ambiguous.

  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 use this tool versus company_news or other company tools. It doesn't indicate what kinds of queries warrant events data vs news or overview data. The description implies retrieval but offers no exclusions or alternatives.

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

• financial_cash_flowC
  2.6/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 doesn't mention whether this is a read-only operation, any authentication requirements, data freshness, or whether the response is a single statement or a time series. Given it's a financial data retrieval tool with an output schema, more behavioral context would be valuable.

  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 concise sentence that states the purpose efficiently. No waste or filler, though it's arguably too sparse given the tool's scope.

  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 3 parameters, an output schema, and is part of a family of financial statement tools (balance_sheet, income_statement, ratio) with 20 siblings. The one-sentence description doesn't explain what data is returned, how it differs from siblings, or what the 'VCI' vs 'KBS' source distinction means. For a financial statement tool with an output schema, more context about return content would help.

  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 documents all 3 parameters with descriptions (symbol, period, source). The description adds nothing beyond the schema. Baseline 3 is appropriate since the schema handles the documentation burden adequately.

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

  Purpose3/5

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

  The description states 'Get cash flow statement for a company' with a specific verb and resource. It's clear what it does but doesn't distinguish it from sibling tools like financial_balance_sheet, financial_income_statement, or financial_ratio beyond the statement name implied by the tool name itself.

  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 use this tool vs siblings. While the tool name implies cash flow specifically, the description provides no context about use cases, exclusions, or when a different financial statement tool would be more appropriate.

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

• financial_income_statementC
  2.6/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. It doesn't disclose whether the data reflects ttm/quarterly/annual conventions, currency, fiscal year alignments, or whether the source (VCI vs KBS) affects figures. With zero annotations, the description should provide more behavioral context about what the returned income statement contains and any caveats.

  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 efficient sentence with no wasted words. It's appropriately front-loaded and concise. However, given the tool's richness, one could argue it's under-specified rather than concise, but by the conciseness standard it is well-sized.

  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?

  With an output schema present, return values don't need explanation, but this tool has no annotations, 3 parameters (1 required), and sits amid many similar financial siblings. The description ('Get income statement data for a company') is minimal and doesn't cover source semantics, period behavior, or when income statement data is the right choice. It's a capable tool but the description under-specifies it.

  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 already documents the period and source parameters with defaults. The description adds no additional nuance about how period or source choices affect results, but at 100% coverage the baseline of 3 is appropriate. The description doesn't say what data each source provides or how annual vs quarter affects the structure.

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

  Purpose3/5

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

  The description states a specific verb+resource ('Get income statement data for a company'), which is clear enough. However, it doesn't differentiate from sibling tools like financial_balance_sheet, financial_cash_flow, or financial_ratio — though the name itself partially distinguishes it. The purpose is clear but generic without mention of what periods or data dimensions are covered.

  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 on when to use this tool versus the financial_balance_sheet, financial_cash_flow, or financial_ratio siblings. The description gives no context on which scenarios call for income statement data versus cash flow or balance sheet data. This is a gap given the large sibling set.

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

• financial_balance_sheetC
  2.7/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. The description only says 'get balance sheet data' without disclosing what the response contains (line items like assets, liabilities, equity), whether prior or trailing periods are included, or if there are limits on requested periods. For a data-retrieval tool with no annotation safety profile, this is minimal transparency.

  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, zero waste - efficient and to the point. However, the extreme brevity borders on under-specification given the clarity gaps in purpose and usage. It earns points for compactness but doesn't over-earn because the brevity sacrifices informational value.

  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?

  There is an output schema present, which helps complete the picture of return values. However, given there are 20 sibling tools including other financial statement tools, the description should do more to differentiate this tool. The 3 parameters are each documented in the schema, and the output schema exists, but the description leaves gaps in when/how to use this tool relative to its financial siblings.

  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 all 3 parameters (symbol, period, source) are documented in the schema. The description adds no parameter-level meaning beyond what the schema already provides. Baseline 3 is appropriate since the schema fully covers parameters and the description contributes no additional semantic context.

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

  Purpose3/5

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

  The description states 'Get balance sheet data for a company' - a clear verb+resource but very terse. It doesn't distinguish itself from sibling financial tools like financial_income_statement, financial_cash_flow, or financial_ratio beyond the name itself. The purpose is understandable but lacks scope clarity (historical range, entity framing) that would help a user pick it among siblings.

  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 when-to-use or when-not-to-use guidance is provided. An agent cannot determine when to choose this over financial_income_statement, financial_cash_flow, or financial_ratio based on the description alone. There's no mention of alternatives, prerequisites, or context suggesting this is the right tool for balance-sheet-specific needs vs other financial statements.

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

• company_officersC
  2.9/5.0
  Behavior2/5

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

  Description provides no behavioral context beyond 'get company officers / management team'. With no annotations present, the description carries full burden, but it doesn't disclose what fields are returned, whether data availability varies by source (VCI vs KBS), pagination, or historical depth. The existence of an output schema helps, but for a data-retrieval tool with zero annotation coverage, more behavioral transparency would be valuable.

  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 efficient sentence that states the action and resource clearly. Five words of actual content with zero wasted phrasing. However, it is arguably under-specified rather than concise - the brevity comes at the cost of behavioral and parameter 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?

  The tool has an output schema and 100% schema description coverage, and its complexity is low (2 params, 1 required, no enums, no nested objects). Given this context, a minimal description is mostly adequate for a straightforward getter. However, the distinction between source values (VCI vs KBS) and their implications could be clarified, and the tool's relationship to sibling company tools like company_overview and company_shareholders is not explained.

  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 already documents both parameters (symbol and source) with example values. The description adds no parameter-specific meaning beyond what the schema provides. Under the baseline rule for high coverage, a 3 is appropriate - the schema does the heavy lifting and the description doesn't need to compensate.

  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 'Get company officers / management team' states a clear verb and resource. It is distinguishable from siblings like company_news (content), company_shareholders (ownership), and financial_* (statements) by the focus on officers/management personnel. It doesn't explicitly contrast with those siblings, but the subject matter is distinct enough to avoid confusion, so this falls short of a 5 only because no naming of alternatives is present.

  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 on when to use this tool versus alternatives. There is no mention of when company_officers is preferred over company_overview or company_shareholders, nor any exclusion guidance. For an agent choosing among many company_* and financial_* sibling tools, explicit selection guidance would be helpful but is entirely absent.

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

• company_overviewC
  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 carries the full burden of behavioral disclosure. It doesn't specify whether results are cached, which fields are always present vs conditionally present, price as of what date/time, exchange coverage, or what happens for delisted/unknown tickers. The vague 'etc.' signals incomplete disclosure of return content.

  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?

  A single, efficient sentence front-loads the purpose. The 'etc.' is slightly vague but acceptable. No wasted words or redundancy. Could arguably be a touch more specific about scope, but it's appropriately sized.

  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 has an output schema, which reduces the burden on the description for return-value explanation. However, given the potential source variance between VCI and KBS and the fact that 'overview' is an aggregator-style tool with many siblings, the description could explain what distinguishes VCI from KBS or note coverage differences. The complexity is moderate and the output schema helps, so a 3 is fair.

  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 both parameters fully. The description adds marginal insight by implying what data fields the overview contains, but doesn't explain the source semantics (what VCI vs KBS differ in) or clarify the symbol format beyond examples. Baseline 3 is appropriate given full 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 clearly states the verb ('Get') and resource ('company overview information') and lists example fields (industry, market cap, description). It distinguishes from sibling tools by its scope—it's the profile/research tool among data-focused siblings (stock_history, financial_*). Lacks a fully specific resource noun but is adequately clear.

  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 provides no guidance on when to use this tool versus alternatives. It doesn't mention which siblings to prefer for specific data needs (e.g., financial statements vs overview), and doesn't state any prerequisites like needing the company to be listed on a particular exchange. No exclusions or when-not-to-use guidance.

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

• company_shareholdersC
  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 carries the full burden of behavioral disclosure. The one-line description does not mention return format, whether it includes ownership percentage details, whether the data source (VCI vs KBS) affects results, or any rate/access limitations. For a data-retrieval tool, the absence of any behavioral detail is a gap.

  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, efficient sentence with zero filler words. It's appropriately minimal; nothing could be trimmed. It could arguably be slightly more verbose to add behavioral detail, but this is conciseness, not under-specification to the point of fragment (as in the process example).

  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 a simple 2-parameter read operation with a 100% covered schema and an output schema present, so the completeness bar is moderate. The description is adequate for basic usage but omits clarification on the source parameter's practical difference and the notion of 'major' threshold, which are relevant for correct interpretation of results. It is sufficient, not rich.

  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 both source (VCI/KBS) and symbol (with examples) documented. The source parameter's distinction between VCI and KBS is only minimally explained; the description doesn't clarify that choosing a different source could change which shareholders/reporting basis is shown. However, since the schema fully documents both parameters, 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 'Get major shareholders of a company' uses a clear verb (Get) and resource (major shareholders) with a company scoping. It distinguishes well from siblings like company_officers (officers) and company_overview (general company info), though it could be more specific about what 'major' means (e.g., top N holders, ownership percentages).

  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 on when to use this tool versus company_officers or company_overview, nor are any prerequisites mentioned (e.g., needing a valid symbol from listing tools). The context that it requires a specific listed symbol is only implied by the parameter schema, not stated in the description.

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

• fx_historyC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It doesn't reveal return format (candles, OHLCV?), whether it returns currency symbols alongside prices, data source or restrictions, or expected data granularity/free-tier limits. The 'has output schema' context signal mitigates somewhat since the output is already structured, but the description itself adds no behavioral context.

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

  Conciseness4/5

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

  A single concise sentence that states the core purpose without padding. It's appropriately minimal, though it could potentially front-load more usage-relevant detail without becoming verbose.

  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 complexity is moderate (4 params, all optional with defaults, output schema present). With a good output schema and 100% schema coverage, the description is arguably adequate for basic selection. However, the lack of any distinction from sibling asset-class tools and no behavioral context leaves a gap given the tool has zero annotations and many near-siblings.

  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% and all four parameters (start, end, symbol, interval) have descriptive schema text with defaults and formats. The description adds no parameter information beyond confirming it's 'currency pair' data, which the schema already states via the symbol example (EURUSD, GBPUSD). Baseline 3 is appropriate since the schema does the heavy lifting.

  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 it fetches forex historical price data, with a specific verb ('Get') and resource ('forex currency pair historical price data'). It distinguishes from siblings like stock_history and crypto_history by specifying forex, though it doesn't explicitly note the difference from world_index_history which also deals with forex-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 Guidelines2/5

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

  No guidance on when to use this tool vs alternatives. Sibling tools include crypto_history, stock_history, and world_index_history, which could confuse the agent about which asset class to query. The description gives no context on when forex data is appropriate versus exchange-rate-index history.

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

• listing_industriesC
  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 carries the full burden of behavioral disclosure. It doesn't mention what the output contains (list of industries, mappings to stocks?), whether it's a bulk snapshot, how 'source' affects results, or any data freshness characteristics. There's also an output schema present, which could reveal behavior but isn't visible to justify a higher score.

  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?

  A single concise sentence that front-loads the purpose. Very efficient with zero waste. Could be slightly richer while remaining concise, but as written it is appropriately terse.

  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 1-parameter tool with full schema coverage and an output schema present, the description is largely adequate. However, given the ICB classification context and available siblings like listing_symbols_by_group, a bit more context on what the returned classification looks like would strengthen completeness. Moderate complexity tool, marginal adequacy.

  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% and the single 'source' parameter is already documented with default and allowed values (VCI/KBS). The description doesn't add detail beyond this, but with a single well-documented parameter and full coverage, the baseline of 3-4 is appropriate. The 'VCI or KBS' source options are self-explanatory.

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

  Purpose3/5

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

  The description uses a specific verb-resource pair ('Get ICB industry classification') and narrows scope to Vietnamese stocks. However, it doesn't distinguish this from listing_symbols_by_group or listing_symbols_by_exchange siblings, though 'ICB industry classification' does convey a distinct data type. It's clear but minimal in differentiation.

  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 listing_symbols_by_group or listing_symbols_by_exchange. The ICB industry classification angle is implied but no explicit when/when-not guidance 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.

• listing_symbols_by_groupC
  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 carries the full burden of behavioral disclosure. It doesn't state whether this is a read operation (though 'get' implies non-mutating), doesn't mention rate limits, pagination, or any edge cases around groups/exchanges, nor does it clarify the relationship between 'groups' and 'exchanges' for the two sibling listing tools.

  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?

  A single concise sentence that states the purpose without waste. Adequately front-loaded. However, given the minimal description, some structural opportunity for edge-case notes is missed, but the extreme brevity is acceptable.

  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?

  An output schema exists, which helps complete the picture. However, with zero annotations, this listing tool's description is fairly thin. It doesn't address how 'group' differs from 'exchange', which is relevant given sibling tools listing_symbols_by_exchange and listing_all_symbols. Adequate for a simple listing operation but leaves interpretation ambiguity.

  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 both parameters (group and source) are documented with examples of valid values and defaults. The description itself adds no additional parameter meaning beyond 'market group', but with full schema coverage the 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 'Get stock symbols in a market group' uses a specific verb (get) and resource (stock symbols by market group). It distinguishes from listing_all_symbols and listing_symbols_by_exchange, though it would benefit from naming these alternatives explicitly. Clear purpose overall.

  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 use this tool vs alternatives like listing_symbols_by_exchange or listing_all_symbols. The input schema mentions market groups like VN30, HNX30, HOSE, etc., providing implicit context, but no explicit when/when-not guidance is given.

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

• world_index_historyC
  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 carries the full burden of behavioral disclosure. The description says 'Get' which implies read-only, but the return format, any rate limits, supported index universe, or how data might differ from stock_history (e.g., normalization, currency) are not disclosed. This is a bare minimum description 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?

  A single efficient sentence with zero waste. It is appropriately concise, though it could have leveraged the space to add distinguishing context rather than remaining purely generic.

  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?

  An output schema exists and schema coverage is 100%, which reduces the burden. However, for a financial data tool among many similar history tools, the description should clarify the index universe supported, how it relates to stock_history, and any notable behavior differences. It's minimally adequate but not rich enough given the sibling-tool complexity.

  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 description coverage is 100%, so the schema already documents all 4 parameters well. The description itself adds nothing beyond 'historical data' framing, but the schema fully covers semantics including defaults, formats, and example symbols. The baseline of 3 for high coverage is marginally exceeded because the schema provides rich examples like DJI/IXIC/GSPC mappings.

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

  Purpose3/5

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

  The description 'Get world market index historical data' uses a clear verb+resource but is generic and doesn't differentiate from sibling tools like stock_history, fx_history, or crypto_history which all provide historical data. It lacks specificity about which indices are covered or how it differs from other 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 Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives like stock_history or other history tools. The description doesn't clarify that this covers market indices specifically, nor when to choose it over stock_history for index-related queries. 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.

• company_newsB
  3/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 some burden. It correctly implies this is a read operation by saying 'Get', but does not disclose return format, pagination, news recency limits, or whether 'source' changes the news type. Given an output schema exists to describe the return, the bar is somewhat lowered, but for a news tool the lack of detail on scope is a moderate 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?

  Extremely concise - a single sentence, zero fluff, front-loaded with the core purpose. Every word earns its place.

  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?

  An output schema exists which reduces the burden on the description for return values. However, for a news tool, key questions remain unanswered: how far back does 'latest' go, does source (VCI vs KBS) affect availability, and is there any filtering/disambiguation needed for companies with multiple listings? The description is adequate but thin given the sibling competitor landscape and the meaning of the source parameter.

  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 already documents both parameters. The description doesn't add value beyond the schema - 'symbol' and 'source' are self-explanatory and fully described in the schema. No additional context like date filters or news category is provided.

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

  Purpose3/5

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

  The description states 'Get latest news about a company' with a clear verb and resource. However, it doesn't distinguish from sibling tools like company_overview or company_events - it's unclear how 'news' differs from 'events' or what temporal scope 'latest' implies (days, weeks, months?).

  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 use this tool versus alternatives. There's no mention of what data the source parameter (VCI vs KBS) provides, whether news is recent only, or when one would prefer company_news over sibling tools like company_events or company_overview.

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

• crypto_historyB
  3.2/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. The description doesn't state return format, pagination, rate limits, or whether this is a read-only operation. However, 'Get...history data' strongly implies a read operation, which provides reasonable transparency for a simple data-fetching 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?

  The description is a single concise sentence with zero wasted words, which is appropriate for a straightforward data-fetching tool. It's front-loaded with the key purpose but could arguably add the interval/date flexibility it supports.

  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 has an output schema (which helps), 4 well-documented parameters, and a simple read-only purpose. The description covers the core purpose adequately, though it doesn't mention the flexible date range or interval options that the parameters support. For a simple fetch tool, this is minimally complete but not enriched.

  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 each parameter already well-described in the schema (start/end date defaults, symbol examples, interval options). The description doesn't add meaning beyond what the schema provides, so the baseline of 3 applies. No parameter-level enrichment is offered in the description.

  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 'Get cryptocurrency historical price data' clearly states the verb (get), resource (cryptocurrency), and scope (historical price data). It distinguishes from sibling tools like stock_history and fx_history by specifying cryptocurrency, though it doesn't explicitly name any 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 on when to use this vs alternatives like stock_history, fx_history, or world_index_history. The tool name and 'cryptocurrency' qualifier imply the usage context, but there's no explicit when-to-use/when-not-to-use guidance given the many sibling history/candle tools.

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

• stock_historyB
  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 burden of behavioral disclosure. The description only states what the tool fetches but doesn't explain return format, pagination behavior, rate limits, what happens with invalid symbols, or whether the data source (VCI vs KBS) changes response characteristics. For a data-retrieval tool with zero annotations, this is a significant gap in transparency.

  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?

  A single clear sentence that front-loads the primary purpose. There's zero waste. It could arguably include usage guidance, but as a standalone one-liner it's appropriately concise.

  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 description is adequate for a straightforward data-fetch tool with a rich schema (100% coverage) and an output schema present. However, given there are no annotations and this is one of several stock-history-related tools (stock_intraday is a close sibling), a brief note about when to prefer this vs stock_intraday, or about data-source differences, would improve completeness. The output schema helps, but the lack of any behavioral caveats leaves it at baseline adequacy.

  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% (all 5 parameters have descriptions in the schema). The description itself adds nothing about parameters beyond what the schema already documents. Baseline 3 is appropriate since the schema fully documents each parameter's meaning and defaults.

  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 'Get historical OHLCV price data for a Vietnamese stock' has a specific verb (Get) and resource (OHLCV price data), clearly distinguishing it from sibling tools like stock_intraday (intraday data) and trading_price_board (current snapshot). It specifies the market (Vietnamese) and data type (historical OHLCV). Loses one point because it doesn't explicitly differentiate from the closely related stock_intraday sibling, though the 'historical' qualifier helps.

  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 it ('historical' OHLCV data), which contrasts with stock_intraday for current/real-time data, but it doesn't explicitly state when to choose this over alternatives or note any exclusions. The context (Vietnamese stocks) is clear, but there's no explicit guidance about when NOT to use it or which sibling to use instead.

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

• stock_intradayB
  3.2/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of disclosure. It doesn't describe pagination behavior, whether data streams live updates or is a snapshot, rate limits, or whether the source parameter (VCI vs KBS) yields different data coverage. For a real-time/intraday data tool, these behaviors matter significantly. The output schema exists but the description adds no behavioral context beyond 'today's data'.

  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, efficient sentence with no filler. It's appropriately front-loaded with the essential purpose. Could arguably add a bit more usage context without becoming bloated, but as written it's lean and clear.

  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 has a moderate complexity level with an output schema and 3 documented parameters. The description covers the basic purpose but misses useful context: what the source parameter choices mean, typical data fields returned, or how intraday data differs in granularity/timing from stock_history. Given the tool's simplicity and full schema coverage, this is adequate but not rich.

  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 three parameters documented (symbol, source, page_size). The description adds no parameter information beyond the schema. The source parameter's semantics (what VCI vs KBS means for data quality or coverage) are not explained anywhere, but baseline 3 is appropriate given full 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 'Get intraday (today's) trading data for a stock' clearly states the verb (get), resource (intraday/today's trading data), and scope (for a single stock via symbol). It distinguishes itself from sibling tools like stock_history (which implies historical data) and trading_price_board, though it doesn't explicitly name alternatives.

  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 this is for today's data as opposed to historical, which loosely differentiates from stock_history. However, it provides no explicit when-to-use vs alternatives guidance, no mention of market-hours considerations, and doesn't clarify how this differs from trading_price_board or stock_price_depth.

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

• trading_price_boardB
  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 burden of behavioral disclosure. It doesn't state what fields the price board returns, whether data is delayed vs live, whether it supports global markets or only VN exchange, or rate limits/limits on symbol count. For a real-time financial data tool with zero annotations, 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.

  Conciseness4/5

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

  The description is a single efficient sentence with zero waste. It's appropriately terse, though it could arguably add a bit more value while staying concise.

  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 fairly simple (2 params, simple types, no enums) and has an output schema, so the description carries a moderate burden. However, it doesn't mention the source param's existence, market scope, or real-time caveats (e.g., live exchange hours). Given the output schema covers return structure, the description is adequate but thin for a real-time data tool.

  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 baseline is 3. The description adds no parameter-specific detail beyond the schema, which documents the source (VCI or KBS with default) and symbols format. The description's 'multiple stocks' echoes the symbols param's comma-separated format, adding marginal value at best.

  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 'Get real-time price board for multiple stocks' has a clear verb+resource (get/price board) and specifies multiple stocks scope. It's clear enough, though it doesn't explicitly distinguish from trading_price_depth or trading_intraday siblings beyond the real-time board concept.

  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 doesn't explicitly state when to use this vs alternatives. Among siblings like stock_price_depth, stock_intraday, and stock_history, there's no guidance on choosing the real-time price board. Usage context is implied (real-time board for multiple symbols) but no exclusions or alternatives are referenced.

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

• financial_ratioB
  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 full burden for behavioral disclosure. It doesn't state whether this is a read-only operation (implied by 'get' but not explicit), whether output depends on the chosen period/source, what data availability constraints exist (e.g., ratios require specific source availability), or how the returned ratios vary across sources (VCI vs KBS may compute differently).

  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, focused sentence with zero wasted words. It front-loads the primary action and enumerate examples of returned ratios efficiently. Appropriate length for a straightforward tool.

  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 has an output schema and complete parameter documentation, which lowers the burden. It lists representative ratios and mentions period/source options via schema. However, with no annotations and no guidance on source differences (VCI vs KBS produce different data) or how ratios relate to sibling statement tools, it's adequate but not complete for a multi-source financial tool.

  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 documents all three parameters (symbol, period, source) including defaults and example tickers. The description adds the list of ratio types returned (P/E, P/B, ROE, ROA), which helps clarify what the symbol parameter yields, but doesn't add significant meaning beyond the schema beyond that ratio list.

  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 tool gets financial ratios (P/E, P/B, ROE, ROA) for a company, using specific verb 'Get' and a clear resource. It distinguishes from sibling financial statement tools (balance sheet, income statement, cash flow) by focusing on computed ratios rather than raw statements, but doesn't explicitly name those siblings as alternatives.

  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 it (when you need computed valuation/profitability ratios vs raw financial statements from sibling tools), but doesn't explicitly state when not to use it or name alternatives. For a tool in a large financial family, explicit guidance on when to choose ratios over balance_sheet/income_statement/cash_flow would be valuable and is absent.

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

• fund_listingB
  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 technically carries the full burden. That said, the tool has zero parameters and is a read-only listing operation, so behavioral disclosure needs are minimal. The description does not state whether results are paginated, sorted, or what fields each fund entry contains, but this is partially mitigated by the presence of an output schema explaining the return value.

  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?

  A single clean sentence with zero waste. It is appropriately brief for a zero-parameter listing tool, though it could slightly differentiate itself more explicitly from sibling listing tools like listing_all_symbols by naming the domain 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?

  For a zero-parameter, read-only listing tool with an output schema present, the description is reasonably complete. However, it doesn't convey the scope of what is included (e.g., fund categories, whether criteria like fund type or issuer are filters), nor whether the returned structure contains nested fund data. Given the output schema exists, a 3 is a fair middle-ground score.

  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 tool has zero parameters, so there is no parameter documentation burden to meet. The description accurately aligns with the 100% schema description coverage (nothing to describe). However, it adds no value on top of the schema since there are no inputs to elaborate on—hence a baseline-neutral score rather than higher.

  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 'Get list of open-ended mutual funds available in Vietnam' uses a specific verb ('Get'), a specific resource ('list of open-ended mutual funds'), and scopes the domain ('Vietnam'). It distinguishes itself from the sibling tools which all center on stocks, FX, crypto, and indices—funds are a unique resource here.

  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 is for listing funds as opposed to the stock/crypto/history focused siblings, providing clear domain context. However, it offers no explicit guidance on when to use this tool vs alternatives (e.g., no mention of whether it pairs with stock_history or any other secondary lookup), nor any exclusions or prerequisites.

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

• stock_price_depthB
  3.4/5.0
  Behavior3/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. It states what it returns (bid/ask levels) but does not disclose whether this is a snapshot vs. streaming, whether it includes depth aggregation, real-time vs. delayed data, or rate limits. The output schema presumably clarifies structure. The description adds modest value but leaves behavioral traits such as data freshness and snap semantics unstated.

  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 efficient sentence that conveys the core purpose with useful parenthetical detail (bid/ask levels). No fluff or redundancy. It could have included a note on when to use it over siblings, but as-is it is tight and front-loaded.

  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 has only 2 params with 100% schema coverage and an output schema present, so the structural baseline aids completeness. However, the description doesn't mention important contextual aspects like whether this data is real-time or delayed, how many levels are returned, or whether fallback sources exist. For a market-data tool, freshness semantics matter and are unaddressed.

  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 both parameters (symbol and source) are already documented in the schema. The description adds no parameter-level nuance beyond what the schema provides. Baseline 3 is appropriate; the source parameter's meaning is somewhat clear from schema defaults but no extra guidance is offered in the description.

  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 'Get order book / price depth (bid/ask levels) for a stock' clearly states the verb (get), resource (order book/price depth with bid/ask levels), and scope (per stock). It differentiates fairly well from siblings like stock_history and stock_intraday which deal with price data over time, while this covers current depth levels. It doesn't explicitly contrast with siblings but the resource is specific enough.

  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?

  There is no explicit when-to-use guidance or exclusions in the description. The implied usage is clear (when you need bid/ask depth levels for a stock), but no alternatives are mentioned and no context on market hours, liquidity constraints, or distinction from tick/level data is given. It's adequate but not proactive.

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

• listing_all_symbolsA
  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 full burden for behavioral disclosure. The description accurately states this is a read operation returning listed symbols, which is consistent with its nature. However, it doesn't disclose potential response size concerns (all symbols across three exchanges), whether the source parameter affects data freshness, or any rate-limit or permission implications.

  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 sentence that conveys the complete purpose with zero wasted words. It names the exchanges explicitly and is front-loaded with the core action ('Get all listed stock symbols'). There's nothing extraneous to trim.

  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 list-retrieval tool with one optional parameter and an output schema present, the description is largely sufficient. The exchange coverage is explicitly stated. The only gap is that it doesn't distinguish itself from listing_symbols_by_exchange and listing_symbols_by_group siblings, which could cause an agent to select the wrong tool for a filtered query. But given the simplicity of the tool and good schema coverage, this is a minor omission.

  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 the schema documents the single 'source' parameter with its default (VCI) and options (VCI or KBS). The description doesn't add meaning beyond the schema—it doesn't explain when to choose VCI vs KBS, what distinguishes these sources, or any quality/timeliness differences. Baseline 3 is appropriate when the schema fully covers parameters and description adds no additional context.

  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 tool's function: 'Get all listed stock symbols on Vietnamese exchanges (HOSE, HNX, UPCOM).' It uses a specific verb+resource (get/listed symbols) and explicitly scopes to Vietnamese exchanges, listing the exact exchanges covered. It distinguishes from sibling tools like listing_symbols_by_exchange and listing_symbols_by_group by indicating this is the comprehensive 'all symbols' retrieval rather than a filtered subset.

  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 indicates this returns ALL symbols across HOSE, HNX, UPCOM, which implicitly suggests it's the broad-coverage tool compared to listing_symbols_by_exchange (per-exchange) and listing_symbols_by_group (grouped). However, it doesn't explicitly state when to prefer this over the sibling alternatives or mention any trade-offs such as response size or pagination. The context is implied rather than stated.

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

• listing_symbols_by_exchangeA
  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 burden. It indicates this is a read/listing operation (safe, non-destructive by nature), and the output is grouped output. However, it doesn't disclose whether the output includes all exchanges at once or requires a parameter, or describe the data freshness/format characteristics beyond what the output schema shows.

  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?

  One concise sentence that communicates purpose and scope efficiently with zero waste. It could arguably append usage guidance, but as a purpose statement it's appropriately tight.

  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 listing tool with one fully-documented parameter and an output schema, the description adequately covers the essentials. It could note the relationship to sibling grouping tools, but the exchange-grouping distinction is fairly self-evident from the name and description. Complete enough for this low-complexity tool.

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

  Parameters5/5

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

  Schema coverage is 100% and there's only one parameter (source) which the schema already fully documents with its VCI/KBS options and default. The description doesn't need to add further parameter detail; the schema handles it completely.

  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 verb+resource+scope: 'Get stock symbols grouped by exchange' with specific exchanges named (HOSE, HNX, UPCOM). This distinguishes it from siblings like listing_all_symbols and listing_symbols_by_group by specifying the grouping dimension (exchange).

  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 use when you need symbols organized by exchange, distinct from listing_symbols_by_group (presumably group-based). However, it doesn't explicitly state when NOT to use this tool or name the alternative grouping tools as alternatives, leaving the differentiation implied rather than explicit.

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