Server Quality Checklist

Tool Scores

• ratiosD
  1.9/5.0
  Behavior1/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 only states content ('financial ratios') and provides no information about input requirements, output format, error behavior, or side effects. This is a complete lack of transparency.

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

  Conciseness2/5

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

  The description is extremely short but it is under-specified rather than concisely informative. It is a fragment without a verb, and while it has no wasted words, it fails to earn its place because it conveys minimal useful information.

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

  Completeness1/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 parameter and no output schema, the description still fails to explain what financial ratios are included, how they are returned, or how to interpret them. It is completely inadequate for an agent to invoke this 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?

  The input schema fully documents the only parameter 'symbol' with description 'IDX ticker', giving 100% schema coverage. The description adds no additional parameter meaning beyond what the schema already provides, so the baseline of 3 applies.

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

  Purpose2/5

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

  The description 'Financial ratios for a company.' essentially restates the tool name 'ratios' with the qualifier 'for a company' but lacks any verb or explicit action. It does not clearly distinguish this from sibling tools like 'financials' or 'keystats', making it tautological rather than a genuine purpose statement.

  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 any conditions, prerequisites, or sibling tools, leaving the agent without context for selection.

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

• keystatsC
  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 must carry the full burden of behavioral disclosure. It only mentions the content type (valuation, size, performance metrics) without revealing response format, data timeframe, or any limitations.

  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, focused sentence with no redundancy. It is front-loaded with the core term 'Key statistics' and remains appropriately concise for a simple 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 a simple input schema and no output schema. The description gives a high-level overview but leaves ambiguity about the exact return structure and any behavioral nuances, making it adequate but with clear gaps.

  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 single parameter 'symbol' is fully described in the schema as 'IDX ticker', achieving 100% schema description coverage. The tool description does not add additional parameter context, but the high schema coverage establishes a baseline of 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 clearly states the tool provides key statistics for a company, specifying valuation, size, and performance metrics. It is unambiguous about the resource, but does not explicitly distinguish this from sibling tools like 'ratios' or 'financials'.

  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 keystats versus alternatives. The description does not mention any exclusions, prerequisites, or situations where another 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.

• orderbookB
  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 disclosing behavior, but it only says 'full order-book depth ladder.' It does not mention whether levels are aggregated, if there is a limit to depth, ordering (best bid/ask first), or any pagination. This is a minimal disclosure.

  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 concise sentence with no fluff. It communicates the core function efficiently, and every word contributes meaning. It is appropriately sized for a simple one-parameter 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 only one required parameter and no output schema, so the description need not explain return values. However, it does not elaborate on what the order-book ladder contains (e.g., bid/ask levels, quantities, aggregation). The phrase 'depth ladder' implies levels, but it is still minimal. It is adequate but could benefit from a bit more context.

  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% because the only parameter 'symbol' has a description 'IDX ticker.' The tool description adds nothing beyond the schema. Per the rubric, high schema coverage yields a baseline of 3, and the description does not compensate with extra 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 the resource clearly: 'Full order-book depth ladder for a symbol.' While no explicit verb is given, the intent to provide depth levels is distinct from sibling tools like 'quote' or 'intraday_prices.' It could be improved with an action verb, but it is specific enough to differentiate.

  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. The description simply states what it is, with no context about comparing to 'quote' or 'intraday_prices.' The agent must infer usage from the name and sibling tools.

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

• financialsB
  3.2/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 usefully states that the output is structured tables and that the large HTML report is stripped, which is a behavioral trait. It also explains that the numeric parameters are UI toggle selectors. However, it does not address whether the operation is read-only, potential side effects, rate limits, or error behavior, leaving 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?

  The description is extremely concise, two sentences, with the key point upfront. Every word serves a purpose: naming the resource, clarifying output format, and explaining the selector parameters. No fluff or redundancy.

  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?

  Given there is no output schema, no annotations, and only one of four parameters documented, the description is insufficient for a tool with this complexity. It does not explain how to specify different financial statements (e.g., income statement vs. balance sheet), what the response structure looks like, or how to handle errors. The description offers only surface-level guidance.

  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 only 25% (only symbol is described). The description adds value by explaining that data_type/report_type/statement_type are integer selectors matching UI toggles, but it fails to specify what each selector controls, possible values, or defaults. This leaves significant ambiguity for the three undocumented parameters.

  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 identifies the tool's function as returning financial statements in structured table form, distinguishing it from sibling tools like ratios or keystats. It also notes that the large HTML report is stripped, clarifying the output format. However, it lacks an explicit verb like 'get' or 'fetch', so it's slightly less direct than a 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 is used when financial statement data is needed, and it hints at selectors matching UI toggles. But it does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or prerequisites. The usage context is mostly inferred rather than stated.

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

• trendingB
  3.2/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 disclosure. It mentions 'community-driven' and 'right now', which hints at source and freshness, but does not explain ordering, update frequency, data fields returned, or any limitations. This is a significant gap for a tool with no output schema.

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

  Conciseness5/5

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

  The description is a single, concise sentence that is front-loaded with the core concept. It contains no filler or redundant content, earning a top score for conciseness.

  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, parameterless tool this description provides a basic context, but it does not clarify the output format or how it differs from the similarly named top_movers sibling. The absence of an output schema makes the lack of return-value information more noticeable, though the simple nature of the tool mitigates the gap.

  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 tool has zero parameters, so the description does not need to explain parameter syntax or semantics. The baseline score of 4 applies, and the description contains no irrelevant parameter information.

  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 identifies the resource (IDX stocks) and timeframe (right now), and 'trending' implies a listing/display action. It also adds a distinguishing trait ('community-driven') that separates it from likely sibling tools like top_movers, though it lacks an explicit verb like 'get' or 'list'.

  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 phrase 'right now' implies real-time use, but there is no explicit guidance on when to choose this tool over alternatives like top_movers or sentiment_stream. No exclusions or alternative tool references are provided.

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

• intraday_pricesA
  3.5/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 transparency burden. It discloses that the tool returns close-price series and that it underlies signals, but it does not mention time window, number of points, or how invalid symbols are handled. This is adequate but minimally 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?

  A single sentence front-loads the core resource and provides context. No filler words; every phrase 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?

  The tool is simple with only two parameters and full schema coverage, but there is no output schema, so the description should clarify the return shape. 'Close-price series' gives a general idea but omits the series length, timestamps, or trading-session boundaries, leaving the description adequate but not 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?

  Schema coverage is 100%: symbol is documented as 'IDX ticker' and interval as 'Minutes per point (default 1)'. The description adds no meaning beyond the schema, so the baseline of 3 is appropriate.

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

  Purpose4/5

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

  The description clearly identifies the tool as returning minutely intraday close prices for a symbol, which distinguishes it from siblings like quote (current quote) and orderbook (order depth). It lacks an explicit verb like 'retrieves' but the resource and granularity are specific.

  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 'the basis for volume/price-move signals' implies a use case, but it does not explicitly state when to prefer this tool over alternatives such as quote or price_performance, nor does it mention exclusions.

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

• sentiment_streamA
  3.5/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. It adds useful context ('sentiment/news proxy') but fails to disclose any behavioral traits such as read-only nature, pagination, sorting, or error handling. The description is too sparse to inform the agent about side effects or return 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, concise sentence that front-loads the core action and resource. Every word adds value, and it efficiently sets expectations with the 'not price data' caveat.

  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?

  Given the tool's low complexity (2 params, no output schema, no annotations), the description is minimally viable. It conveys the core purpose but omits details about output format, limit behavior, and data recency. It is complete enough for a simple tool but lacks some contextual richness.

  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 both parameters, so the baseline is 3. The description adds minimal meaning beyond the schema—only clarifying that posts 'mention' the symbol. It does not elaborate on how 'limit' affects results or how the symbol is matched.

  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 retrieves 'Recent community posts mentioning a symbol', which is a specific verb+resource combination. It also distinguishes itself from sibling price-focused tools by explicitly noting 'not price 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 description implies usage for sentiment/news analysis and explicitly excludes price data, but it does not name alternative tools or provide explicit when-to-use/when-not-to-use guidance. The differentiation is implicit rather than actionable.

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

• sectorsA
  3.6/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. It mentions 'List', which implies a read-only operation, but does not explicitly state safety, potential side effects, rate limits, or output ordering. The return format (id, name) is given, but no additional behavioral context is provided.

  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, concise sentence that is front-loaded with the key verb and resource. There is no wasted information or verbose phrasing.

  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?

  Given the tool's simplicity (no parameters, no output schema), the description is largely sufficient. It states the purpose and output fields. However, it doesn't clarify whether the list is exhaustive or if 'IDX' might be ambiguous to the agent, but these are minor omissions for such a simple tool.

  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 zero parameters, so the baseline is 4. The description does not need to explain parameter semantics. It does indicate the output shape, which is helpful.

  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 'List IDX sectors (id, name)' clearly states a specific action (list), a specific resource (IDX sectors), and output fields (id, name). It distinguishes from sibling tools like quote, top_movers, and orderbook, which cover different market 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 is provided on when to use this tool versus alternatives. The description is purely declarative and does not mention conditions, prerequisites, or when this tool would be preferred over sibling tools.

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

• broker_summaryA
  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 does reveal key output behavior: 'which brokers net-bought/sold on the latest completed session, in lots and IDR value, with foreign/local/govt classification.' It also clarifies the meaning of 'LATEST' as 'the previous completed session.' However, it does not disclose aspects like data availability, sorting order, or whether the result is read-only. This adds some value but stops short of rich context.

  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 two sentences with no wasted words. The first sentence front-loads the core purpose, and the second adds a unique selling point and a specific behavioral clarification. It is succinct and well-structured, earning a 5.

  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?

  Although there is no output schema, the description clearly states what the tool returns (brokers, net amounts, lots, IDR, classification), which is enough for a read-only summary tool with one required parameter. It also clarifies the time window. However, the mention of 'period=LATEST' without a matching schema parameter creates a gap, and it doesn't mention limits or error conditions. Overall, it is fairly complete but not flawless.

  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 description doesn't need to explain existing parameters—all have descriptions. The description adds no additional meaning to the schema parameters; it even introduces a 'period=LATEST' reference that does not exist in the input schema, which could confuse users. Therefore, baseline 3 is appropriate since the description provides no further semantic value 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 clearly states the tool's purpose: 'Broker summary for an IDX stock: which brokers net-bought/sold on the latest completed session, in lots and IDR value, with foreign/local/govt classification.' It names the resource (IDX stock) and the specific output (broker net-buy/sell with values and classification). This distinguishes it from siblings like 'orderbook' or 'quote' by focusing on broker-level bandarmology data, reinforced by 'This is the core bandarmology signal' and 'TradingView has no equivalent.'

  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 provides context for when to use the tool ('for an IDX stock' and 'core bandarmology signal'), but it does not explicitly state when not to use it or mention alternative sibling tools. 'TradingView has no equivalent' is an external comparison, not internal alternative guidance. The period=LATEST clarification helps with parameter usage but not overall tool selection.

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

• price_performanceA
  3.8/5.0
  Behavior3/5

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

  No annotations are present, so the description carries the burden of behavioral disclosure. It lists output metrics and timeframes, but does not describe the output structure, data source, pagination, or potential limitations. It is adequate for a simple read operation but lacks rich behavioral detail.

  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, information-dense sentence covering scope, timeframes, and metrics. No redundant or wasted words.

  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 parameter and no output schema, the description provides sufficient context for an agent to understand what data is returned. However, the exact output structure (e.g., array vs object) is not specified, so it is not 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 single parameter 'symbol' is fully documented in the schema as 'IDX ticker'. The description adds no additional semantic detail about the symbol format or valid values, so the baseline 3 applies.

  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 specifies the tool's function: providing multi-timeframe price performance data with concrete metrics (close, high, low, % change). It distinguishes itself from sibling tools like quote and intraday_prices by emphasizing the multi-timeframe scope.

  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 usage for multi-timeframe analysis, but does not explicitly state when to use this over alternatives like quote or intraday_prices. No exclusions or alternative recommendations are provided.

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

• top_moversA
  4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the transparency burden. It adds a valuable behavioral note that an empty list is expected when the market is closed, preventing the agent from misinterpreting it as an error. Other behaviors like authentication or rate limits are omitted, but the tool is a simple read-only hotlist, so this is adequate.

  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 extremely concise: two sentences, with the purpose front-loaded and a key edge case in the second sentence. Every word earns its place; no filler or redundancy.

  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 combination of schema (100% parameter coverage) and description covers the tool's purpose, its key edge case, and invocation parameters. It does not explain ordering or differentiate from the 'trending' sibling, but these are minor gaps for a tool of this 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?

  Schema coverage is 100% and each parameter has a description, including the enum for 'type' and the default for 'limit'. The tool description adds no additional semantic meaning beyond what the schema already provides, so the baseline 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 clearly states the tool returns a hotlist of IDX stocks categorized as top gainers, losers, or most-active. This specific verb-resource pairing distinguishes it from siblings like 'trending' or 'quote'.

  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: fetch market movers by category. However, there is no explicit guidance on when to use this tool versus alternatives such as 'trending' or 'quote', nor any exclusions.

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

• quoteA
  4.3/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 discloses real-time nature, the main outputs, and the secondary behavior of resolving internal company IDs. It stops short of detailing error conditions or data latency, but for a simple quote tool this is adequate.

  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 focused sentences, each adding value: the first defines the core function and outputs, the second adds a useful secondary behavior. No unnecessary words or filler.

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

  Completeness5/5

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

  The tool has a single parameter, no output schema, and no annotations. The description sufficiently covers what is returned (last price, change, best bid/offer) and the company ID resolution, making it complete for a simple real-time quote 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% and already describes the symbol parameter with examples. The description just repeats 'IDX symbol' without adding new semantic detail, so it provides no significant value 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 clearly states the tool's purpose: providing real-time quotes for IDX symbols, including specific data points (last price, change, best bid/offer) and the extra function of resolving internal company IDs. It distinguishes itself from siblings like orderbook and intraday_prices by focusing on a snapshot quote.

  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 implies usage for obtaining a quick real-time market snapshot and mentions the IDX scope. It does not explicitly exclude alternatives or say when not to use it, but the context is clear enough for a simple quote tool.

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