tariff_classificationClassifies products into correct HTS codes from text or documents, automating tariff lookup and ensuring customs compliance in real time.
Pricing: {"unit": "credits", "per_run": 2}
| Name | Required | Description | Default |
|---|---|---|---|
| product_description | Yes | Description of the product used to identify HS/HTS codes. |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the sparse openWorldHint annotation, the description offers only marketing-level claims like 'correct HTS codes' and 'ensuring customs compliance in real time.' It does not disclose uncertainty/confidence, verification needs, failure modes, or any side effects. Pricing is the only concrete added behavioral/cost detail.
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?
The description is short: two purposeful sentences plus a structured pricing note. There is no filler, and key capabilities and cost are front-loaded. The only slight inefficiency is the promotional tone of 'ensuring customs compliance in real time.'
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 one-parameter tool with a full output schema, the description covers the basic purpose and input modality. It is incomplete in disambiguating against tariff_calc and in setting expectations about classification caveats or confidence, but the output schema reduces the need to describe return values.
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?
Schema coverage is 100% and the single parameter is already clearly described in the schema. The description's 'from text or documents' mildly reinforces that the input is free-form text, but it does not add additional parameter semantics beyond what the schema provides, so it hits the baseline.
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 uses a specific verb ('classifies') and target resource ('products into HTS codes'), and adds input modality ('from text or documents') plus the automation/compliance purpose. This makes the tool's core role clear and implicitly distinguishes it from sibling tariff_calc, which is about calculation rather than classification.
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 phrase 'from text or documents' implies when to use it — for HS/HTS classification from unstructured product descriptions. However, it never explicitly states when not to use it or names alternatives (e.g., tariff_calc for calculating duties), leaving the selection boundary to inference.
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.
Tools are generally distinct in purpose (search, due diligence, tariff, supply chain), but the two 'search_company_candidates' and 'search_region_candidates' are similar in name and both serve lookup functions, and multiple tools like 'corporate_exception_report' and 'due_diligence_report' overlap in producing comprehensive company reports. The separation is clear enough for an agent but could cause confusion between similar-sounding search tools.
Names mix styles: descriptive multi-word names (due_diligence_report, supply_chain_risk_prediction) and abbreviated names (sg_chokepoint, sg_visualization). There is no consistent verb_noun pattern, and the 'sg_' prefix is inconsistently applied. However, most names are readable and roughly follow a noun-based pattern.
With 9 tools, the server covers a broad but coherent domain: search/identity, due diligence, supply chain analysis, and tariff compliance. Each tool addresses a distinct high-level capability, and the count feels appropriate for the scope—not too thin or overly heavy.
The tool surface covers major workflows: company identification, due diligence reporting, supply chain risk/chokepoint analysis, tariff classification and calculation. Minor gaps exist (e.g., no explicit update/delete on data since it's a read-only data provider), but for its purpose as an analysis API, it is reasonably complete.