lookup_hs_codePublic: classify a product against the Harmonised System (HS) tariff schedule. Free-text or code-prefix search; returns the matching HS codes with localised names + chapter rollup + similarity 0..1. Use the result with check_dual_use to screen export-control risk.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Defaults to 10. | |
| query | Yes | Product description or HS code prefix. | |
| locale | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It explains the search modes ('Free-text or code-prefix search') and the return payload ('matching HS codes with localised names + chapter rollup + similarity 0..1'), which goes beyond taxonomy-level descriptions, though it omits details like no-match behavior or pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The description front-loads the core purpose and public access, then states inputs, outputs, and downstream integration in a compact, well-organized way.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description does a good job of summarizing return values and intended use. A minor gap is that terms like 'chapter rollup' are not expanded, and there is no mention of edge-case behavior, but the core calling context is adequately covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents query and limit well, and the description adds some meaning by noting free-text/code-prefix search and localised names, which clarifies locale. However, it does not deeply elaborate parameter formatting or edge cases, and coverage is moderate rather than high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'classify a product against the Harmonised System (HS) tariff schedule.' It also names the output directly and connects to a sibling tool, making it easy to distinguish from generic product search or sanctions checking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when the tool is useful and explicitly routes the output to check_dual_use. It does not explicitly state when not to use this tool versus other siblings, but the recommended downstream usage is a strong practical guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool maps to a distinct resource and action: product/manufacturer retrieval, catalog search, category listing, HS classification, dual-use screening, sanctions screening, and partnership inquiry. The compliance checks are related but clearly separated by HS-code vs. name-based screening, so an agent is unlikely to pick the wrong tool.
Most tools follow a predictable verb_noun snake_case pattern: check_, get_, list_, search_, lookup_. partnership_inquiry is the only clear deviation, using a noun phrase instead of a verb-led name, but the overall convention is still easy to infer.
Nine tools is a well-scoped size for a public B2B trade and compliance server. Each tool covers a distinct step in the catalog-discovery or pre-flight workflow, with no redundant or decorative entries.
The core workflows are covered: category browsing, product search, manufacturer retrieval, HS classification, dual-use and sanctions screening, and partnership outreach. A minor gap is the lack of direct manufacturer text/country search, which is explicitly deferred to separate Wave 3b auth tools; agents can still discover manufacturers indirectly through product search.