Skip to main content
Glama

goods_classify

Classify goods for export control from a description (or HS code).

Bilingual (English / Russian, auto-detected) goods classifier. Returns the best-matching HS code (with EN+RU descriptions), related ECCNs, control reasons (NS, MT, NP, CB, AT...), an export-control level (high/medium/low/ none), a confidence score, and alternative matches for review.

This is destination-agnostic — it identifies WHAT the goods are and whether they are controlled in principle. To get the license decision FOR A SPECIFIC destination, pass the result into export_controls_screen.

IMPORTANT, the matcher is lexical, and confidence scores the strength of the string match, not the correctness of the classification: "equipment" returns semiconductor manufacturing equipment at confidence 1.0. Treat the code as a suggestion for narrowing the question. When no hs_code was supplied the result carries classification_basis and classification_confidence_note; read them before quoting any code, and ask the user for the HS code or ECCN on their shipping documentation.

Args: description: Goods description, min 2 chars (e.g. "uranium centrifuge", "центрифуга для урана"). Required. hs_code: Optional known HS code (4 or 6 digits) for a direct lookup. language: Optional hint — "en" or "ru" (auto-detected if omitted).

Examples: goods_classify("uranium centrifuge") # → HS 840120, ECCN 0B001 goods_classify("центрифуга для обогащения урана") # Russian query, same result goods_classify("semiconductor manufacturing equipment") goods_classify("", hs_code="840120") # direct HS lookup

Use case: 'Is a semiconductor lithography machine export-controlled?'

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
hs_codeNo
languageNo
descriptionYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

TDQS

A5/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and does so excellently. It discloses the lexical matcher's behavior, explains that confidence reflects string match strength rather than classification correctness, and warns users to read classification_basis and classification_confidence_note when no HS code is supplied.

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 thorough yet well-structured. It front-loads the core purpose, then covers key behavior, parameters, and examples. Every sentence adds critical value, including the practical warning about lexical matching and the concrete use case at the end.

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?

The description is complete for a tool of this complexity. It covers purpose, usage, limitations, parameters, examples, and expected return elements (HS code, ECCNs, control reasons, confidence, alternatives). Since an output schema exists, the description appropriately focuses on behavior and context rather than exhaustively listing return fields.

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 parameter descriptions (0% coverage), but the description fully compensates: it explains description is required with min length, hs_code is optional for direct lookup, and language is an auto-detected hint. Examples also demonstrate parameter combinations, including empty description with hs_code.

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 opens with a specific verb and resource: 'Classify goods for export control from a description (or HS code).' It clearly differentiates from sibling tools by stating it is destination-agnostic and directs users to export_controls_screen for destination-specific decisions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use the tool (to identify what goods are and whether controlled in principle) and provides an alternative: 'To get the license decision FOR A SPECIFIC destination, pass the result into export_controls_screen.' It also clarifies the tool's limitations with the lexical matching caveat.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.3/5.0
Disambiguation4/5

Most tools have distinct purposes, but some overlapping areas (goods_classify vs hs_code_lookup vs eccn_lookup; fx_rate vs fx_rate_history vs fx_volatility) require close reading of descriptions to select correctly. The detailed descriptions help, but the shear number of lookup tools creates mild ambiguity.

Naming Consistency3/5

Names mix verb-first (track_payment, mcp_verify) and noun-first patterns (iban_validate, fx_rate, ssi_lookup), with some phrase-like names (banks_using_correspondent, is_business_day_check). While readable, there is no single consistent convention.

Tool Count3/5

33 tools is heavy, but the server's broad scope (payments, FX, sanctions, export controls, company registries, SWIFT) justifies most of them. A few marginal tools (mcp_register, mcp_verify, company_search_result) add bulk without core value.

Completeness5/5

The tool set covers the payment lifecycle end-to-end: tracking, settlement, FX, compliance, sanctions, and company due diligence. There are no obvious dead ends; the tools chain together via next_steps and search_id flows.

Resources