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

Goes well beyond the annotations by disclosing that the call is paid in points, requires a signed-in OZ account, and that backend data is returned verbatim with only a Vietnamese label added. This also reconciles the readOnlyHint=false annotation, which an agent would otherwise misread as a data-mutating call.

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 sentence is front-loaded and information-dense, but the entire content is then repeated verbatim in Vietnamese, roughly doubling length without adding any new fact for a bilingual-capable agent.

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?

With no output schema, the description does describe the return payload (risk level plus reasons and evidence), and it covers cost and auth. Only the undocumented tenNguoiNhap parameter and the origin code format keep it from being fully complete.

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 0%, so the description must carry the load; it defines tenNhan, the 4–8 digit shape of maHs, and the default CN origin, which is real added value. However, the fourth parameter tenNguoiNhap is never mentioned and the 2-character ISO constraint on xuatXu is left implicit.

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 — checks trademark/IP risk before importing — and names the exact inputs and the four-valued verdict (RED/YELLOW/GREEN/NOT ENOUGH DATA). This is clearly distinguishable from sibling lookups like tim_ma_hs or phan_loai_hs, which resolve codes rather than assess brand risk.

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 usable preconditions for calling: HS code is optional, name-only queries work but are downgraded to a soft warning, and supplying HS yields higher accuracy. It does not name any alternative sibling tool or state when to skip this tool in favour of a code lookup, so it stops short of full routing guidance.

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