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

With annotations only covering readOnly/openWorld/idempotent, the description adds the critical traits: asynchronous execution with a receipt to fetch results later, per-line point billing, no trial calls, and authentication. It also discloses that K2 output is passed through verbatim from hs-code-api, which tells the agent where the semantics come from.

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 English text is front-loaded and information-dense, but the entire description is then repeated almost verbatim in Vietnamese, roughly doubling length without adding content. For an agent consuming one language, half the text is redundant.

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 real work: it explains that results are fetched later by receipt, follows the free-review shape, and describes the K2 group including duKienQuyetDinh, cauSuaDeXuat, and GIR/legal quotes. Minor gaps remain on the non-line parameters and the point cost magnitude.

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 description coverage is only 25%, so the description must compensate. It does explain maLuotPhanLoai well and the line-level dossier-check behavior, but loaiHinh, ngayDuKienDangKy, and how required line fields (stt, maHs, moTa, xuatXu) are interpreted for checking are not covered.

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 and resource: checking each line of a draft customs declaration for whether the goods description matches the declared HS code, using AI classification. It also distinguishes the output (a job receipt maLuot) from the sibling free review and from phan_loai_hs classification runs, so an agent can tell what this tool is and is not.

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?

Gives concrete operating conditions: runs in the background, charged per line, no trial calls, signed-in account required, max 50 lines. It also explains when to supply maLuotPhanLoai (to check against an earlier classification dossier). It stops short of explicitly stating when to use this paid check instead of soat_to_khai, leaving that comparison partly inferred from 'same shape as the free review'.

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