Deterministic HS6/TARIC customs resolution engine and bilingual FTS5 nomenclature API for AI agents (UNE Node 04)
Glama couldn't complete the latest health check. If this server requires authentication, missing or expired test credentials may be the cause. A test profile lets Glama authenticate for health checks and discover tools; it is separate from your personal connections.
If you are the author, claim ownership, then add or update a test profile under Admin → Test Profile.
Scored across 2 tools
resolve_hs_code takes an existing code and expands its hierarchy, while search_customs_nomenclature takes keywords and returns matching codes. Their inputs and outputs are clearly different, though both operate on the same customs-nomenclature domain and could be momentarily confused by an agent unfamiliar with the distinction.
Both tools follow a consistent snake_case verb_noun pattern (resolve_hs_code, search_customs_nomenclature). There are no deviations or mixed conventions.
Two tools is thin for a server named Customs-Bridge, which suggests a broader bridging role. The narrow scope of code resolution and keyword search makes the count borderline but not unreasonable.
Core lookup and keyword search are covered, but the surface lacks operations like retrieving duty rates, validating full TARIC codes, or listing nomenclature chapters. These gaps may force agents to seek other sources for common customs tasks.
Résout l arborescence douanière à partir d un code SH6 universel (Chine/UE) ou d un préfixe TARIC à 8/10 chiffres.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Code numérique à résoudre (ex: "850440" pour convertisseurs statiques, "841290") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It implies a lookup that returns a hierarchy, but says nothing about permissions, error behavior for unknown codes, rate limits, or the shape of the returned tree.
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?
One front-loaded sentence that names the action, the input formats and the output concept with zero filler. Nothing is wasted.
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 single-parameter lookup with no annotations and no output schema, the description covers input adequately but never explains what the resolved tree contains or how deep it goes. Missing return-value context keeps it at minimum viable.
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% (baseline 3), and the description adds format constraints beyond the schema: the code may be a universal SH6 (China/EU) or an 8/10-digit TARIC prefix. That clarifies accepted input formats in a way the schema's single example does not.
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?
States a specific verb (résout) and resource (arborescence douanière) with the accepted input forms (SH6 universel Chine/UE or préfixe TARIC 8/10 chiffres). It does not explicitly contrast itself with the sibling search_customs_nomenclature, so an agent must infer that 'resolve a tree' differs from 'search nomenclature'.
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?
No when-to-use guidance, no prerequisites, and no mention of the sibling search_customs_nomenclature as an alternative. The agent is left to guess whether to resolve or search for a given code.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recherche déterministe de codes TARIC / Nomenclature Combinée par mots-clés bilingues (FR/EN) via FTS5.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Nombre maximal de résultats (défaut: 5) | |
| query | Yes | Mots-clés décrivant la marchandise (ex: "moteurs électriques", "lithium cells", "drones") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It usefully discloses that the search is deterministic and backed by FTS5 (exact full-text matching, not semantic), which shapes expectations of results. It says nothing about result limits, ranking, or empty-result behavior.
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?
A single front-loaded sentence naming verb, resource, and mechanism with no filler. Efficient, though it omits routing information that would need to go somewhere.
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 2-parameter, output-schema-less search tool with no annotations, the description adequately covers what it does and how it searches. It falls short on disambiguation from resolve_hs_code and on any result-shape or limit expectations.
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%, so query and limit are already documented in the schema, and the description does not restate them. It adds only the bilingual FR/EN hint, which is a modest semantic addition beyond the schema's examples. Baseline 3 applies.
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?
States a specific verb (Recherche) and resource (codes TARIC / Nomenclature Combinée), with the mechanism (FTS5) and language scope (FR/EN). An agent understands what it returns, but the description never distinguishes it from the sibling resolve_hs_code.
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?
"par mots-clés bilingues" implies how to invoke it (keyword query, either language), which is real usage context. However there is no explicit when-to-use statement or condition selecting this over resolve_hs_code, leaving routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
resolve_hs_codesearch_customs_nomenclature
Add one secure layer between your agents and this server.