Vietnam HS Code & Tariff — by OZ

sinh_mo_ta_khai_bao

Generates a Vietnam customs declaration product description (Circular 38/2015 field 1.78, as amended up to Circular 121/2025) from an HS code and product details, with a compliance score; when hs-code-api returns them, also the ECUS text, HYS continuation, full description and justification table, passed through verbatim. If the classification dossier lacks evidence, the result is a draft (banNhap: true, moTaEcus null) with a draft text, reasons and questions to ask (cauHoi) instead; do not declare a draft. Sinh mô tả hàng hoá khai báo hải quan theo TT 38/2015 (sửa bởi TT 39/2018, TT 121/2025) chỉ tiêu 1.78 từ mã HS và thông tin hàng, kèm điểm tuân thủ; khi hs-code-api trả, kèm mô tả ECUS, phần khai tiếp HYS, mô tả đầy đủ và bảng giải trình, chuyển nguyên văn. Hồ sơ chưa đủ căn cứ thì trả bản nháp (banNhap: true, moTaEcus null) kèm câu hỏi (cauHoi) thay cho mô tả ECUS; không dùng bản nháp để khai.

Input Schema

Name	Required	Default
`maHs`	Yes
`model`	No
`xuatXu`	No
`tenHang`	Yes
`thongSo`	No
`chatLieu`	No
`congDung`	No
`kichThuoc`	No
`tinhTrang`	No
`loaiToKhai`	No	NHAP
`nhaSanXuat`	No
`thuongHieu`	No
`maLuotPhanLoai`	No
`quyCachDongGoi`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedOct 30, 2026

addedInput schema / properties / kichThuoc

Added value: +{
+  "anyOf": [
+    {
+      "maxLength": 100,
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ]
+}

addedInput schema / properties / loaiToKhai

Added value: +{
+  "default": "NHAP",
+  "enum": [
+    "NHAP",
+    "XUAT"
+  ],
+  "type": "string"
+}

addedInput schema / properties / maLuotPhanLoai

Added value: +{
+  "anyOf": [
+    {
+      "format": "uuid",
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ]
+}

addedInput schema / properties / nhaSanXuat

Added value: +{
+  "anyOf": [
+    {
+      "maxLength": 200,
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ]
+}

addedInput schema / properties / quyCachDongGoi

Added value: +{
+  "anyOf": [
+    {
+      "maxLength": 200,
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ]
+}

addedInput schema / properties / tinhTrang

Added value: +{
+  "anyOf": [
+    {
+      "maxLength": 100,
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ]
+}

First observedOct 15, 2026

TDQS

A4/5.0

Behavior5/5

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

Beyond the annotations, it discloses important behavior: the tool returns a compliance score, may pass through ECUS text, HYS continuation, full description and justification table verbatim, and falls back to a draft state with banNhap=true, moTaEcus=null, reasons and cauHoi when evidence is insufficient. This is rich operational context not present in the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The English portion is front-loaded and information-dense, but the full Vietnamese translation repeats the same content and makes the description unnecessarily long. The duplication adds little for an agent that can already parse the English text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description explains output states and the draft fallback well, which is important because there is no output schema. However, for a 14-parameter tool with no schema descriptions, it leaves most input semantics undocumented, so it is not fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and there are 14 parameters, but the description only broadly mentions an HS code and product details. It does not explain most input fields such as maHs, tenHang, loaiToKhai, maLuotPhanLoai, thongSo, or the NHAP/XUAT enum, leaving a significant semantic gap.

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 states a precise verb and resource: generate a Vietnam customs declaration product description for Circular 38/2015 field 1.78 from an HS code and product details. It also distinguishes the output from a mere classification result by naming the compliance score and the hs-code-api-derived fields.

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?

It gives clear context for use and an explicit exclusion: when the dossier lacks evidence the result is only a draft, and the draft must not be declared. It does not name sibling alternatives such as phan_loai_hs or soan_ho_so_giai_trinh, so it stops short of full when-to-use routing.

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

All Vietnam HS Code & Tariff — by OZ tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?