Server Quality Checklist

Tool Scores

• company_trendA
  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 burden of behavioral disclosure. It does disclose the year range (2019-2025) and the stock code format, which adds context. However, it does not describe the output structure, error behavior, or any access/rate limits. Since it's a simple read-only query tool, the description provides adequate but minimal 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.

  Conciseness5/5

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

  The description is concise and front-loaded: the main purpose is in the first sentence, followed by a clearly formatted Args section. Every sentence provides necessary information without redundancy. It is appropriately sized for a simple single-parameter tool.

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

  Completeness4/5

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

  The tool has one parameter, no annotations, and an output schema. The description covers the purpose and the parameter format, which is sufficient for the tool's simplicity. The presence of an output schema means return value details are documented elsewhere. A minor gap is the lack of explicit guidance on what the output looks like (e.g., a table or list), but it is not necessary. Overall, the description is nearly complete for this context.

  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 description coverage is 0%, and the schema only lists 'code' as a string with no meaning. The description compensates fully by explaining that the parameter is a 4-6 digit TWSE/TPEx stock code and provides an example ('2330'). This is essential and adds complete 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 shows one company's median pay for each year in a specific range (2019-2025). This uses a specific verb ('show') and a resource ('one company's median pay'), and the year range adds specificity. The sibling tools (lookup_company, industry_stats, top_by_median) appear to serve different purposes, so this description effectively distinguishes the tool.

  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 the use case: to retrieve annual median pay data for a single company. It provides a clear context for when the tool is appropriate but does not explicitly contrast it with sibling tools or state exclusions. Since it gives a focused purpose, it is above the 'implied usage' level but lacks explicit alternatives.

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

• industry_statsA
  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 states the tool summarizes pay distribution and explains its intended purpose, but it does not disclose specific output details or side effects. For a read-only summarization tool, this is adequate but not rich.

  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 compact and well-structured: a purpose statement, a usage rationale, and a parameter list with examples. Every sentence adds value and there is 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?

  Given the tool's simplicity (one parameter, output schema exists), the description fully covers purpose, usage, and parameter semantics. The output schema handles return details, so the description is complete for an agent to select and invoke the tool correctly.

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

  Parameters4/5

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

  The schema only defines 'industry' as a required string with no description. The description adds valuable guidance: 'Industry name or part of one' and provides concrete examples, clarifying that partial matches are acceptable.

  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 first sentence 'Summarise the pay distribution within one industry' uses a specific verb and resource, clearly defining the tool's function. The second sentence adds the sector-baseline use case, which distinguishes it from sibling tools like lookup_company or top_by_median.

  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 explicitly says to use this tool to judge whether a single company's pay is high or low for its sector, providing a clear when-to-use scenario. It does not explicitly name alternatives or exclusions, but the context is sufficient for most agents.

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

• top_by_medianA
  4.4/5.0
  Behavior4/5

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

  With no annotations, the description carries the behavioral disclosure burden. It details sort order (highest first), substring filtering for industry, the floor logic for min_median with an example, and the clamping behavior for limit. This goes beyond the schema, though it does not cover error behavior or data source nuances.

  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: one purpose sentence followed by a clean Args list. Every sentence earns its place, and the structure is easy to scan; no redundancy 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?

  Given the tool has only three optional parameters and an output schema exists, the description is nearly complete. It covers the ranking metric, ordering, filtering options, limiting behavior, and unit interpretation. The example clarifies the min_median semantics, making the tool well-specified for an AI agent.

  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%, and the description fully compensates by explaining each parameter: industry as an optional substring filter, min_median as a floor in 萬元/yr with a concrete example, and limit with range and clamping. This adds substantial 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 ranks companies by non-managerial median pay, highest first. This specific verb+resource (rank companies) and the metric (median pay) distinguishes it from sibling tools like lookup_company and company_trend.

  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 (ranking top companies) but does not explicitly state when to use this tool versus alternatives such as industry_stats or company_trend. It provides no when-not-to-use guidance or mention of alternative tools.

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

• lookup_companyA
  4.6/5.0
  Behavior4/5

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

  Without annotations, the description carries the behavioral disclosure burden. It explicitly discloses the substring matching behavior and the possibility of multiple results, which is key for managing expectations. It does not address error handling or return format, but an output schema exists to cover that.

  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 plus an argument explanation, front-loaded with a clear purpose. Every sentence provides useful information without 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?

  Given the single-parameter simplicity and presence of an output schema, the description covers the essential context: what the tool does and how to formulate queries. The substring caveat prevents misuse. No significant gaps remain.

  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 'query' parameter (0% coverage), but the description fully compensates by explaining acceptable formats (4-6 digit code or name substring) with examples. This exceeds the baseline and is highly actionable.

  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: 'Look up one company's salary disclosure by stock code or name.' It includes specific input formats and even notes substring matching, distinguishing it from sibling tools that likely provide aggregate or trend data.

  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 single-company lookups, with clear input guidance (stock code or name). It does not explicitly mention alternative tools, but the scope is evident. The caveat about short queries returning multiple companies provides additional context.

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