Server Quality Checklist

Tool Scores

• get_weather_warningB
  3.4/5.0
  Behavior3/5

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

  No annotations exist, so the description carries the full behavioral burden. It does disclose the nature of the result (active advisories covering phenomena and effective time windows) and constrains the county value to the cwa://counties list. It does not disclose error behavior for invalid counties, empty-advisory states, or any access constraints.

  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 short sentences, front-loaded with the purpose and followed by the single critical parameter constraint. No filler or repetition of schema information.

  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 single-parameter query tool with an output schema present, the description covers purpose, parameter format, and result content adequately. The notable gaps are the missing sibling-routing guidance and any treatment of no-advisory or invalid-county outcomes, which matter given the external cwa://counties constraint.

  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 0%, so the schema alone is useless for the county parameter. The description compensates with a precise constraint — the value must be a full county name from cwa://counties — and a concrete example (臺北市), which materially improves the odds of a correct call.

  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 a specific verb (查詢/query), a specific resource (currently active weather advisories), and a scope (specified county). The parenthetical enumeration of phenomena — heavy rain, strong winds, valid time period — helps distinguish it from the typhoon-warning and earthquake-report siblings, though it never names them explicitly.

  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 given on when to choose this tool over get_weather_forecast, get_typhoon_warning, or get_earthquake_report. With three adjacent sibling tools, the absence of any routing, exclusion, or 'use X instead when...' note leaves selection to inference.

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

• get_typhoon_warningA
  3.5/5.0
  Behavior3/5

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

  The description communicates that the tool queries recent typhoon warnings and lists the data fields returned (name, path, rain/wind sections). It implies read-only via '查詢' (query). However, with no annotations present, it doesn't disclose limits, pagination, or error behavior – so it's adequate but not thorough.

  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 packs the resource, action, and output scope without redundancy. Excellent conciseness.

  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 operation with one parameter, it provides enough to call correctly. It lacks output schema details but states the content types included. No edge cases or error info, but acceptable for a query tool. Score 4.

  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 only parameter, limit, is not documented in the schema (0% coverage), but the description says '最近 N 筆' (most recent N items), which directly clarifies that limit controls how many recent warnings are returned. This compensates for the missing schema description, though it doesn't mention the default value or any bounds. Score 4 because the description adds useful semantic context for the parameter.

  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 queries recent typhoon warnings and specifies the returned content (name, path intensity, rain/wind sections). It names the specific resource and verb, distinguishing it from sibling tools like get_weather_warning by resource type. However, it does not explicitly name alternatives, so it's just short of a 5.

  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 conditions like 'use for typhoon forecasts' or contrast it with get_weather_warning or get_earthquake_report. The agent must infer usage from the resource name alone.

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

• get_weather_forecastA
  3.7/5.0
  Behavior3/5

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

  With no annotations present, the description carries the full burden of behavioral disclosure. It discloses the temporal window (36 hours) and data types covered, but doesn't mention that this is a non-mutating read operation, potential error conditions (e.g., invalid county), or rate limits—leaving an incomplete safety picture.

  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 with zero waste. The core purpose is front-loaded first, followed by a single essential parameter constraint. Every sentence earns its place.

  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 output schema covers return values, so that burden is lifted. The single parameter is well-documented with format guidance and an example. Remaining gaps—no error behavior or explicit read-only confirmation—are minor given the tool's simplicity and existing output schema.

  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 0% and the schema only labels the parameter as 'County' with no description, so the description must compensate. It does so effectively by specifying the exact format (must be a full county name from cwa://counties) and providing a concrete example (「臺北市」), which is valuable beyond the schema.

  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 a clear verb-initial function (查詢不明確未來36小時天氣預報) with specific outputs (天氣現象、降雨機率、氣溫). The scope is well-defined and distinct from siblings which cover earthquakes, warnings, and typhoons, although it doesn't explicitly name them.

  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?

  It clearly specifies the usage condition (querying forecast for a specific county) and imposes the county format requirement. However, it doesn't give when-not-to-use guidance or explicitly contrast with sibling tools, leaving the alternative-selection to the agent's inference.

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

• get_earthquake_reportA
  4/5.0
  Behavior4/5

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

  No annotations exist, so the description carries the burden. It clearly indicates this is a read-only query operation and specifies the significant-felt earthquake filter and which data fields are included. This is transparent for a simple retrieval tool, though it does not mention any timeout, response shape, or edge-case 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 one compact sentence that includes the core action, the object, the count concept, and the important result fields. There are no redundant or filler 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 one-parameter retrieval tool, the description conveys the essential behavior and output content. The output schema is present, so a full return-value description is not necessary. Missing details like default limit fall to 1 are minor because they are represented in the schema.

  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 0%, so the description must compensate. It does state '最近 N 筆', which communicates that the 'limit' parameter controls the number of returned reports. However, it never explicitly names the parameter or explains constraints such as default, minimum, or maximum, leaving some ambiguity.

  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 a specific verb '查詢' and a clear resource, earthquake reports, while explicitly listing the returned fields (time, location, magnitude, depth). It also distinguishes itself from the weather/typhoon sibling tools by focusing on earthquake 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 when to use this tool—when earthquake report data is needed—by contrasting with weather-related siblings. However, it does not explicitly state exclusions or compare itself with any alternative earthquake tools, so usage guidance remains 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.