Server Quality Checklist

Tool Scores

• get_stock_detailsB
  3.3/5.0
  Behavior2/5

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

  No annotations provided, so description carries full burden. Describes output snapshot and link, but does not disclose error handling, rate limits, authentication needs, or behavior for invalid tickers. Insufficient for a complete behavioral profile.

  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, efficient and without fluff. Covers key details but could benefit from structuring the metric categories (e.g., list). However, it remains clear and front-loaded.

  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 no annotations or output schema, description lacks completeness. Does not specify return format, pagination, error behavior, or usage limits. For a single-ticker snapshot, more context (e.g., data refresh frequency) would be helpful.

  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% with descriptions for all 3 parameters. Description reinforces that ticker is required and adds grouping by category, but does not significantly enhance parameter understanding beyond schema. 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?

  Clearly states it retrieves a detailed metric snapshot for a single US stock or ETF. Mentions specific categories (valuation, growth, profitability, dividends) and a link to Tickertape page. Distinguishes from sibling tools like screen_stocks (screening) and search_stocks (search).

  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?

  Implicitly indicates it is for individual tickers, but does not explicitly state when to use alternatives or provide exclusions (e.g., for multiple tickers use screening tools). No guidance on prerequisites or context.

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

• search_stocksA
  3.7/5.0
  Behavior4/5

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

  With no annotations, the description carries full burden. It discloses behavioral traits: 'The first call builds a local index and may take a few seconds.' This is valuable for agent planning. However, it does not mention any read-only nature, permissions, or caching behavior. Still, it is fairly transparent for a search tool.

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

  Conciseness5/5

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

  Two sentences, front-loaded with purpose and return info, no fluff. Every sentence adds value: purpose, return format, and a behavioral note. Highly efficient.

  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 covers purpose, return content (tickers with exchange and sector), and initial latency. However, without an output schema, it is incomplete: it does not specify the full result structure (e.g., if ticker symbol and company name are returned, or if there are additional fields like price). Also, no mention of pagination despite a limit parameter. Adequate but with 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?

  Schema coverage is 100%, so baseline is 3. The description adds minimal parameter context beyond the schema: it mentions query is 'Ticker symbol or (partial) company name' which repeats the schema description. No additional meaning is provided for 'limit' or 'asset_type' beyond defaults and ranges.

  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: 'Look up US stocks or ETFs by ticker symbol or company name. Returns matching tickers with their exchange and sector.' It uses a specific verb ('look up') and resource ('US stocks or ETFs'), and distinguishes from sibling tools like 'get_stock_details' (detailed info) and 'screen_stocks' (filtering).

  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 explicit guidance on when to use this tool versus alternatives. It does not mention when not to use it or suggest sibling tools like 'screen_stocks' for more advanced filtering. Usage is only implied from the purpose.

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

• screen_etfsA
  4/5.0
  Behavior3/5

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

  No annotations provided, so description carries full burden. It doesn't explain return format, pagination behavior beyond parameters, or rate limits. The schema covers basic constraints, but behavioral traits are lacking.

  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 sentences, front-loaded with the core action and a quick reference to sibling tool. Every word is purposeful and no waste.

  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 7 parameters, no annotations, and no output schema, the description covers the screening purpose and directs to list_filters. Missing return format explanation, but otherwise adequate.

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

  Parameters3/5

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

  Schema coverage is 100%, so baseline 3. The description adds context for filters and categories but doesn't significantly enhance understanding of parameters 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 screens US ETFs by metrics like AUM, expense ratio, returns, and dividend yield. It distinguishes from siblings by specifying 'US ETFs' vs stocks or filter discovery.

  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 advises using list_filters to discover metric names and mentions categories for restriction. It could explicitly state when not to use, but the guidance is helpful.

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

• screen_stocksA
  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 full burden. It discloses that results are sorted and paginated, and explains filtering mechanics for numeric and categorical parameters. It does not mention auth, rate limits, or edge cases, but for a screening 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?

  Three concise sentences, front-loaded with purpose, then usage guidance. 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.

  Completeness4/5

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

  Given 8 parameters and no output schema, the description covers filtering, sorting, pagination, and references list_filters for metric discovery. It leaves out details on columns and error handling, but overall sufficient for correct invocation.

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

  Parameters3/5

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

  Schema coverage is 100%, so baseline is 3. The description adds context about using list_filters for metric names and clarifies that sectors and industries are separate, but does not significantly extend beyond the schema descriptions.

  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 screens US stocks by fundamental and technical criteria, listing categories like valuation, growth, and dividends. It distinguishes from siblings such as screen_etfs and get_stock_details by specifying US stocks and referencing list_filters for metric discovery.

  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?

  It advises using list_filters to discover metric names and explains that numeric filters use min/max while sectors and industries have separate parameters. However, it does not explicitly contrast with screen_etfs or search_stocks, though sibling names provide context.

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

• list_filtersA
  4.7/5.0
  Behavior4/5

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

  No annotations provided, but description tells what the tool returns (metrics, classifications, units, ranges, sector/industry values) and that results are inputs for other tools. Could mention read-only nature explicitly, but overall 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?

  Two sentences: first states purpose, second provides usage guidance. No unnecessary words, front-loaded with key information.

  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?

  No output schema, but description comprehensively lists what the tool returns (metrics, classifications, units, ranges, allowed values). Explains how output is used downstream, making it complete for a simple listing 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?

  Schema covers both parameters fully. Description adds usage context: search filters by name/description, category filters to a specific category with examples. This enhances understanding 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?

  Description states clearly that the tool lists metrics and classifications for screening US stocks and ETFs. It distinguishes from sibling tools like screen_stocks and screen_etfs by being a discovery tool.

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

  Usage Guidelines5/5

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

  Explicitly instructs to call this first to discover valid metric names, units, ranges, and values. Explains that returned aliases should be passed to screening tools, providing clear when-to-use guidance.

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