Server Quality Checklist

Tool Scores

• check_tariff_updatesA
  3.9/5.0
  Behavior3/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 disclosing behavioral traits. It implies a read-only comparison operation, but does not explicitly mention any side effects, permissions, rate limits, or potential costs. It gives basic transparency but lacks detail about edge cases or system impact.

  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, using two sentences to convey purpose, parameter default, and output format. There is no unnecessary information, and the structure is logical: statement of function, optional behavior, and return details.

  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 one optional parameter, the description includes all necessary information: what it does, the parameter's default, and the exact structure of the returned data. It is complete for a user to understand and invoke the tool without additional context.

  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 parameter 'hts_codes' is described both in the schema and in the tool description, with the default behavior (watchlist) clearly explained. Since schema coverage is 100%, the baseline is 3, but the description adds a concise clarification of the default behavior, earning a 4.

  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: comparing current HTS version with a previous fetch and listing changes. It explicitly mentions the output structure (code, column, old/new values) and the default behavior when no codes are provided, making the purpose unambiguous.

  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 does not provide any guidance on when to use this tool versus alternatives like search_hs_candidates or calculate_tariff_scenario. It only describes the tool's own behavior without mentioning when it is appropriate or inappropriate to use it.

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

• calculate_tariff_scenarioA
  4/5.0
  Behavior4/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 explicitly notes that the tool returns Chapter 99 rules verbatim and instructs the LLM to read the exception string to layer duties correctly, and to always remind the user that the result is an estimate. This goes beyond the schema by revealing the output format and the need for interpretation.

  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: the first front-loads the core function, the second gives clear LLM instructions. Every word earns its place, with no redundancy or 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?

  The description defines the key return values (MFN/FTA duties, Chapter 99 rules, MPF/HMF fees) and includes a processing protocol for the LLM. Given the absence of an output schema, it is fairly complete, though it does not address edge cases like invalid codes or missing unit-based inputs (which the schema partially covers).

  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%, and the tool description does not add meaningful detail beyond what the schema already states for each parameter. It mentions origin and value only generically, while the schema gives specific usage constraints for quantity, weight, and ocean_freight.

  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 MFN/FTA duties, all Chapter 99 rules (IEEPA/301/232) verbatim, and MPF/HMF fees. This specific verb-resource pairing distinguishes it from sibling search/watch/update tools.

  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 for tariff calculation with Chapter 99 layers, but it does not explicitly state when to use it versus alternatives like search_hs_candidates or watch_tariff_changes. The context is clear enough to infer usage, but no exclusionary guidance is provided.

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

• dataset_infoA
  4/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 transparency burden. It discloses what data is exposed (download date, source, license, row count) but does not explicitly confirm it is read-only, describe the response format, or mention any caching 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, front-loaded sentence that states the key information fields and the primary purpose. Every word earns its place and there is no unnecessary 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?

  For a zero-parameter, read-oriented info tool, the description is sufficient: it names the dataset, the useful metadata fields, and the intended use case. No output schema exists, but the description covers the essential expected content.

  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 baseline 4 applies. The description adds semantic value by clarifying what dataset information the tool exposes, even though there are no input parameters to document.

  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?

  Description clearly identifies the tool as supplying metadata about the HTS dataset (load date, source, license, row count). It is distinguishable from sibling tools like search_hs_candidates and calculate_tariff_scenario, though it relies on the title rather than an explicit verb for the action.

  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 states the tool is used to check data freshness: 'dùng để kiểm tra độ tươi của dữ liệu.' It gives a clear context for when to use it but does not mention when not to use it or name alternatives.

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

• watch_tariff_changesA
  4/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 and does disclose that the tool saves codes and requires a subsequent call to check_tariff_updates to see changes. However, it does not mention potential side effects like whether the watchlist is overwritten or appended, or any permissions needed, leaving some behavioral ambiguity.

  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 the first sentence stating the primary action and the second explaining the workflow with check_tariff_updates. It is efficient, front-loaded, and contains no unnecessary words or 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?

  For a tool with only 2 parameters and no output schema, the description sufficiently explains what the tool does, how to integrate it with check_tariff_updates, and the intended use case (monitoring 2025-2026 tariff changes). It lacks minor details such as return behavior or watchlist mutation semantics, but overall it is adequately complete 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?

  The input schema provides full descriptions for both parameters (hts_codes and origin_country), so the baseline is 3. The description adds only 'kèm xuất xứ' (with origin) which merely restates the schema's origin_country field, adding no new meaning or format details beyond what the schema already communicates.

  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 saves HTS codes to a watchlist for monitoring tariff changes, using the specific verb 'Lưu' (save) and resource. It also distinguishes itself from the sibling tool check_tariff_updates by explicitly pointing to it as the follow-up step, making the purpose unmistakable.

  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 provides clear context on when to use this tool: to track 2025-2026 tariff changes without manual searching, and explicitly instructs to call check_tariff_updates after dataset updates. It does not mention exclusions or when not to use it, so it falls short of full explicit alternative guidance.

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

• search_hs_candidatesA
  4.3/5.0
  Behavior4/5

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

  No annotations provided, so description carries full burden. It openly states results are candidates, not rulings, and warns about the need for legal terminology, preventing misuse. It also implies potential retry behavior, which is useful context.

  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?

  Two short paragraphs with clear structure: function, caveat, then highlighted important usage note. Dense but not overly long, with critical advice front-loaded in caps.

  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?

  Despite no output schema, description explains what is returned (duty, link) and the preprocessing needed. It covers essential behavior for a search tool, though it could mention limit parameter semantics more, but schema handles that.

  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, but description adds crucial guidance on how to phrase product_description (translate to HTS-style material+function with examples), which goes beyond schema and substantially improves usage correctness.

  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 it returns top 8-10 digit HTS code candidates with duty and precedent link, and explicitly notes results are candidates for screening, not final rulings. It distinguishes from siblings (calculate, watch, check, dataset) by being a search function.

  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?

  Provides explicit instructions: translate commercial product names into legal HTS terminology before calling, with concrete examples, and if zero results, retry with alternative phrasings. It doesn't explicitly name alternative tools but sets clear context for when to use (pre-broker screening).

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