Server Quality Checklist

Tool Scores

• get_basic_financialsA
  3.9/5.0
  Behavior3/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 the return format ('str: Basic financial metrics in JSON format') and provides example metrics, which is useful. However, it doesn't mention error behavior, symbol validity requirements, or any other side effects beyond the read-only nature implied by 'get'.

  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 concise and well-structured, with a one-sentence purpose, an Args section, and a Returns section. Every sentence adds information and nothing is redundant.

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

  Completeness4/5

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

  For a simple one-parameter tool with no output schema, the description adequately explains the purpose, parameter, and return format. It lists example metrics (P/E, market cap) but could mention edge cases or limitations. Overall, it's complete for the tool's complexity.

  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?

  The schema provides no description for the symbol parameter, but the description fully compensates with a clear explanation: 'The stock symbol to look up (e.g., AAPL for Apple Inc.)'. This adds meaning and a concrete example, making the parameter's purpose unmistakable.

  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 'Get basic financial information for a company' with a specific verb and resource. It distinguishes from siblings by mentioning metrics like P/E ratio and market cap, but it doesn't fully articulate the boundary relative to get_stock_price or get_stock_candles.

  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 when basic financial metrics are needed, but it doesn't explicitly state when to prefer this over sibling tools or provide exclusions. The example symbol (AAPL) gives a concrete use case, but no alternative guidance is offered.

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

• get_market_newsA
  3.9/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It discloses the return format (JSON with headlines, summaries, URLs) and the min_id pagination behavior, but does not mention ordering, result limits, or any side effects. The 'Get' verb implies read-only, but this is not explicitly stated.

  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, with a one-line purpose followed by structured Args and Returns sections. Every sentence adds value, and there is no redundant or filler content.

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

  Completeness4/5

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

  For a simple read-only tool with two optional parameters, the description covers purpose, parameters, and return format sufficiently. Minor gaps include no mention of news time window, result limits, or ordering, but these are not critical for basic usage.

  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 description coverage is 0%, so the description fully compensates. It explains the category parameter with allowed values and the min_id parameter for retrieving news after a specific ID, giving clear meaning beyond the raw 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 'Get the latest market news' with a specific verb and resource. The listed categories (general, forex, crypto, merger) distinguish it from stock-specific siblings like get_company_news and get_stock_price.

  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 explicit when-to-use or when-not-to-use guidance is provided. It does not mention that company-specific news should use get_company_news or that stock quotes should use get_stock_price. Usage is only implied by the tool's name and categories.

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

• get_stock_priceA
  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 mentions the return format (JSON string) but does not disclose potential errors, read-only nature, rate limits, or data source.

  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 concise, uses clear sections (Args, Returns), and every sentence contributes meaning without filler.

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

  Completeness4/5

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

  Given the tool's simplicity (one parameter, no output schema, no annotations), the description covers the essential aspects: purpose, parameter, and return format. However, it lacks error handling or validity notes, leaving a minor 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 description's Args section explains the symbol parameter with an example (e.g., AAPL for Apple Inc.), adding meaning beyond the schema's bare string type and field title.

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

  Purpose5/5

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

  The description uses the verb 'Get' and identifies the resource 'latest stock price and related information for a given symbol', clearly distinguishing it from sibling tools like get_stock_symbol_lookup and get_stock_candles.

  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 establishes a clear context for retrieving current price, but does not explicitly mention alternatives or when not to use this tool. Sibling names imply distinct use cases, but the description could have been more explicit.

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

• get_stock_candlesA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden. It discloses the premium feature access risk and describes the return format as JSON with open, high, low, close values. This adds meaningful behavioral context beyond schema, though it does not cover error scenarios or rate limits.

  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 well-structured and front-loaded with the purpose, then organized into Args and Returns sections. It is slightly verbose but every line provides needed information, such as the premium warning and parameter details.

  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 complexity (4 parameters, no output schema, no annotations), the description is fairly complete: it covers purpose, all parameters, return format, and a caveat. It lacks explicit sibling differentiation and default behavior explanation, but defaults are present in the schema.

  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 description coverage is 0%, so the description fully compensates by explaining all four parameters, including example symbols, supported resolution values, and time formats. This adds significant meaning beyond the bare 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 function with a specific verb and resource: 'Get historical price data (candles) for a stock.' The term 'historical' and 'candles' distinguish it from sibling get_stock_price, which likely provides current 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?

  Usage is implied through the description of historical data, but there is no explicit guidance on when to use this tool versus alternatives like get_stock_price. The premium feature note provides a constraint but does not offer a clear 'when not to use' or point to alternatives.

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

• get_stock_symbol_lookupA
  4.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 the full burden. It discloses that the tool searches and returns a list of formatted strings, but omits details on matching behavior (e.g., fuzzy vs exact), potential empty results, error conditions, or any read-only assumption. This is minimal but not misleading, hence a mid-range score.

  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 concise and well-structured: a one-sentence summary, followed by Args and Returns sections. Every element adds value, with no redundant or vague text. It is front-loaded with the purpose and easy to parse.

  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 lookup tool with one parameter and no output schema, the description provides essential information: purpose, parameter semantics, and return type. It lacks details on output format specifics or edge cases, but given the low complexity, this is reasonably complete. A score of 4 reflects the slight uncertainty about what 'formatted information' precisely entails.

  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?

  The schema only specifies 'query' as a required string, but the description adds substantial meaning: it explains what inputs are acceptable (symbol, name, ISIN, CUSIP) and gives a concrete example ('apple'). With schema description coverage at 0%, this description fully compensates and enhances usability.

  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 a specific action ('searches for best-matching symbols') on a specific resource (stock symbols), distinguishing it from sibling tools that deal with prices, financials, and news. The inclusion of example query types ('symbol, security's name to ISIN and CUSIP') reinforces the scope.

  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 when to use this tool: whenever you have a partial symbol, name, or identifier and need to find the canonical symbol. It provides clear context by listing acceptable inputs, but does not explicitly mention alternatives or when not to use it. Since sibling tools all operate on known symbols, this is adequate context without excluding other tools.

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

• get_company_newsA
  4.4/5.0
  Behavior3/5

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

  With no annotations provided, the description alone must convey behavioral context. It details the return format (JSON string with headlines, summaries, URLs), but does not disclose limitations, error conditions, rate limits, or explicit read-only guarantees. For a simple news retrieval, this is adequate but not comprehensive.

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

  Conciseness5/5

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

  The description is concise and well-structured. It front-loads the primary purpose, then lists parameters with clear formatting and finally describes the return value. Every sentence adds value with no redundancy.

  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?

  For a simple tool with 3 string parameters and no output schema, the description covers all essential aspects: purpose, parameter meanings, and return value format. It is complete enough for an agent to select and invoke the tool correctly without additional clues.

  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?

  The input schema has zero description coverage, but the description fully compensates by explaining each parameter: symbol with an example (AAPL), and from_date/to_date with format guidance (YYYY-MM-DD). This adds significant meaning beyond the bare 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 function: 'Get news for a specific company over a date range.' It uses a specific verb (Get), identifies the resource (company news), and differentiates from sibling tools like get_market_news by emphasizing company-specificity.

  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 context is clear: use when you need news for a particular stock symbol over a date range. It implicitly distinguishes from get_market_news, but lacks explicit guidance on when not to use or alternative tool references.

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