Vietnam HS Code & Tariff — by OZ

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely new context that the report is routed to the operations team ('để nhóm vận hành xem'), but says nothing about what the reporter gets back, rate limits, or whether a report is deduplicated.

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 action and its subject are front-loaded in the first clause, with the conditional parameter hint immediately after. The Vietnamese restatement is redundant for a bilingual audience but adds no bloat beyond one sentence.

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 simple three-parameter, no-output-schema report tool with annotations covering the safety profile, the description is close to sufficient. It still leaves the post-submission behavior and the required/optional distinction among parameters unstated.

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 parameter meaning. It explicitly explains maLuot (the turn code from a result) and implies moTa (the bug description) and tenCongCu (which OZ tool), which is partial compensation; the length constraints and the exact role of tenCongCu are left entirely to the schema.

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?

The description states a specific verb+resource ('Report a bug or connection problem with an OZ tool'), so an agent can tell what it does without opening the schema. It does not, however, differentiate itself from the closely related sibling gui_phan_hoi (send feedback), which is a real ambiguity 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?

Usage is implied rather than stated: the agent learns to include the maLuot code 'from the result' when one exists, which is a useful conditional hint. There is no explicit when-to-use vs. gui_phan_hoi guidance and no exclusions, so guidance remains only partially developed.

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

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

Annotations declare a non-read-only, non-destructive, non-idempotent mutation. The description adds meaningful context beyond that: it re-queues the job and does not charge additional points. It still omits auth/error behavior, but the key operational trait is disclosed.

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 informative, with the Vietnamese translation duplicating the same content. The duplication is useful for a Vietnamese-domain tool but slightly reduces conciseness.

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 two-parameter mutation without an output schema, the description covers when to call it, what it does, and the no-extra-charge behavior. It could say more about parameter expectations, but is otherwise complete enough to invoke correctly.

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 0%, so the description must clarify both required parameters. It identifies maLuot as a receipt code and implies boSung contains the added facts, but adds no format or length guidance beyond the schema's bare types.

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 action, resource, and triggering condition: adding facts to a finished-but-incomplete HS classification job via receipt maLuot and re-queuing it. The CAN_DU_KIEN condition distinguishes it from sibling lookup/classification tools.

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?

Explicitly says to use it when the retrieved result reports CAN_DU_KIEN and the user has answered the listed questions. It does not name alternative siblings or state when not to use it, but the precondition is clear.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false and destructiveHint=false, so the agent knows this is a non-idempotent write with no destructive side effects. The description adds the rating vocabulary and the optional HS correction, but does not disclose what happens on repeated submissions or that the referenced run must exist. Modest added value over 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.

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

Two front-loaded sentences with the core action first. The bilingual Vietnamese restatement duplicates the English content verbatim, which is defensible for a Vietnamese-domain tool but is still redundant text rather than added information.

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 four-parameter write tool with no output schema, the description covers the rating semantics but omits where maLuot comes from (the prior tool call's result) and what a submission produces. Annotations handle the safety profile, so the remaining gap is workflow context.

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 carries the full burden. It glosses danhGia (the four ratings) and maHsDung (optional correct HS code), but says nothing about the required maLuot or the ghiChu note field, leaving half the parameters unexplained. Below the baseline 3 warranted by high-coverage schemas.

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?

The description states a specific verb-and-resource pair ('records your rating of a previous result') and enumerates the four rating values plus the optional correct HS code, so the agent knows exactly what this tool does. It stops short of differentiating itself from siblings like tra_ma_hs or tra_thue, which is the only gap.

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?

'A previous result' implies this is a post-result feedback loop, so usage is inferable, but there is no explicit when-to-use statement, no mention of the required maLuot identifier, and no exclusions or alternatives named. Adequate but leaves the agent to infer the trigger.

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

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

Beyond the readOnlyHint/openWorldHint annotations, the description discloses a real state machine: DANG_XU_LY, XONG, CAN_DU_KIEN (which returns the questions to ask), and LOI (failed with points refunded). The refund-on-failure and once-per-receipt billing behavior are non-obvious traits that annotations cannot convey.

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 four statuses and their meanings are stated twice, once in English gloss and again verbatim in a Vietnamese sentence, adding no new information. The front-loaded English portion is good, but the duplication and language mixing waste roughly half the text.

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?

There is no output schema, yet the description explains what each returned state means and what accompanies CAN_DU_KIEN and LOI, which is the key information an agent needs. It stops short of describing the result payload format or expected wait/retry cadence, but for a single-parameter read tool it is largely 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 carries the burden, and it does identify maLuot as the receipt-turn code ('mã lượt biên nhận'). It adds no format or length detail (the schema imposes 6-100 chars), so it only partially compensates for the empty schema description.

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?

The description states a specific verb and resource: it retrieves the state and full result of an asynchronous HS classification job keyed by a receipt code. That is clearly distinct from the submission sibling phan_loai_hs, but the description never names that or any other sibling, so the differentiation is inferable rather than explicit.

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?

Usage context is implied (this is the polling counterpart to an async submission) and one genuinely useful usage fact is given: the tool is free and points are charged only once at the receipt turn, so repeated polling is safe. However, there is no explicit 'call this after submitting' or 'do not use for X' guidance.

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

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

Annotations cover the safety profile (readOnly=false, destructive=false, openWorld=true, non-idempotent), so the description's real added value is the two-phase async behavior: it may return only a receipt {maLuot, trangThai: DANG_XU_LY} rather than an immediate answer, and legal/GIR citations are quoted verbatim from the backend rather than generated. This is meaningful context the annotations do not convey.

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?

Purpose is front-loaded, but the English and Vietnamese sentences are near-duplicate translations, and the inline JSON receipt fragments add density. Content earns its place, but the redundancy and mixing of two languages in the same field make it heavier than necessary.

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 5-parameter tool with no output schema, the description covers purpose, input constraints, the async return shape, and how results are retrieved — enough for an agent to call it correctly. The main residual gap is the un-described structure of the thongSo object, which the schema leaves undocumented.

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% across 5 parameters, so the description carries the burden. It maps parameters to meaning (tên hàng, chất liệu, công dụng, thông số) and explains what nguonThongSo records plus its ANH/LINK/CHU enum role. It does not describe thongSo's shape as an arbitrary key/value object, so it falls slightly short of fully compensating.

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?

Names a specific verb and resource (suggests Vietnam HS codes for a product) and states the scope (from a text description of name, material, use, specifications). It also differentiates from siblings by declaring what it is not — text-only, no images or marketplace links — and implies results come from a separate lookup (ket_qua_phan_loai) via the turn 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?

Clearly states the input context (text description only, not images or links) and the async pattern: a receipt is returned in the gateway's waiting mode and status/results are fetched with the same maLuot. It does not explicitly name a sibling tool to use, so the routing guidance is one step short of a 5.

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

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

Annotations already declare the profile (readOnlyHint=false, idempotentHint=false, openWorldHint=true, destructiveHint=false), which is consistent with a generative non-repeatable call and creates no contradiction. The description adds genuinely new behavioral context not present in structured fields: the output includes a compliance score and follows Circular 39/2018. However it omits any warning that the text is machine-generated/not legally authoritative, what happens with an invalid or mismatched HS code, and nothing about latency or failure modes.

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 content is front-loaded in two short sentences, but the Vietnamese sentence is a verbatim translation of the English one, so half the text is redundant for an agent rather than earning its place. It is not bloated, but it wastes tokens on duplication while omitting parameter detail.

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 non-idempotent, open-world generative tool with 8 undocumented parameters and no output schema, the description is thin. It never explains the shape of the return (beyond 'a description and a compliance score'), the scale/meaning of the score, or how the HS code and product attributes are combined, leaving the agent unable to predict results or validate inputs.

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% across 8 parameters, so the description carries the full documentation burden, yet it only alludes to 'an HS code and product details' generically. It does not map to any specific field (maHs, tenHang, xuatXu 2-letter code, chatLieu, congDung, thuongHieu, thongSo) nor explain formats or which fields drive the compliance score. The Vietnamese parameter names are partially self-describing, but that is schema-level, not description value.

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?

Names a specific verb+resource (generates a Vietnam customs declaration product description) and anchors it to a legal standard (Circular 39/2018 / TT 39/2018) plus a compliance score output. It is clearly not the same as siblings like phan_loai_hs or tra_cay_hs, but it never names or contrasts with them, so it stops short of full sibling differentiation.

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?

Usage is only implied: 'from an HS code and product details' hints that an HS code must already be known (possibly obtained via tim_ma_hs or phan_loai_hs) and that the tool is for producing a declaration description. There is no explicit when-to-use, when-not-to-use, or named alternative, so the agent must infer the workflow position.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds useful behavioral content with no output schema present by stating what is returned (codes plus basic duty rates) and constraining input to Vietnamese keywords. However it says nothing about matching behavior, result caps, or the meaning of 'basic' duty rates.

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?

Front-loaded with the search action and its method in one sentence, with zero filler. The Vietnamese sentence duplicates the content bilingually, which is defensible for a Vietnam-domain tool but is technically redundant for an agent reading the English.

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 low-complexity, read-only, two-parameter tool the description covers purpose, input language, and return content, which is close to sufficient. It falls short because gioiHan's behavior (default value, max of 20, effect on results) is entirely undocumented anywhere, leaving an agent unable to reason about result limits.

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 carries the full burden for two parameters. It partially covers tuKhoa ('Vietnamese product-name keywords' and '(tiếng Việt)'), but gioiHan is never mentioned, and no length constraints or default-limit semantics are conveyed, so it fails to compensate for the coverage gap.

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?

The description names a specific verb and resource ('Searches Vietnam HS codes') plus the input method ('by Vietnamese product-name keywords') and the return shape ('matching codes with basic duty rates'). This is clearly distinguished from a classification tool, but it never explicitly differentiates itself from close siblings like tra_cay_hs or phan_loai_hs, which an agent must choose between.

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?

Usage is only implied: the agent can infer it should call this when it holds a Vietnamese product-name keyword rather than an existing code. There is no explicit when-to-use, no when-not-to-use, and no routing to alternatives such as tra_cay_hs or phan_loai_hs, which is a real gap given the number of HS-related siblings.

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

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

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), so the description's job is to add context — and it does, by disclosing the returned structure (path, parent, siblings, children) and the notable inclusion of residual 'other' lines, which is non-obvious behavior. It does not state what happens for a non-existent or malformed code, leaving that gap.

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 well front-loaded and dense with useful detail, but the second sentence is a verbatim Vietnamese translation carrying no new information, effectively doubling length for zero added semantics. Acceptable if bilingual parity is intentional, but it does not earn its place on information grounds.

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 only one parameter, no output schema, and annotations already declaring read-only behavior, the description's enumeration of return fields is the most important thing it can do, and it does so. The remaining hole is error/miss behavior when the supplied code is invalid or unknown.

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 0% and the single parameter 'maHs' is documented only as a bare string. The description compensates with the crucial constraint that it is a 4-8 digit HS code, which excludes 2-digit chapter queries and is the key semantic the agent needs. It does not describe validation or error handling for out-of-range codes, so it stops short of full compensation.

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 — 'Returns the Vietnam HS nomenclature tree around a code (4-8 digits)' — and enumerates the exact output shape (path, parent, siblings, children, residual 'other' lines). This is far more specific than a sibling like 'tim_ma_hs' or 'tra_chu_giai', but the description never names an alternative tool, so the differentiation is inferred rather than explicit.

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?

There is no when-to-use versus when-not guidance and no mention of sibling tools such as tim_ma_hs (code lookup) or phan_loai_hs (classification). The agent must infer from the resource noun that this tool is for hierarchy expansion around a known code, but nothing in the text says so.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds that the returned content is chapter and heading notes rather than a code or rate, which is useful context, but says nothing about what happens with an invalid or incomplete HS code, or the size/shape of the returned text.

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 core statement is front-loaded and short, but the second sentence is a verbatim Vietnamese restatement of the first, which duplicates content rather than adding it. For a bilingual audience this may be intentional, yet it doubles length without new information.

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 one parameter, no output schema, and read-only annotations, the tool is simple enough that the description is close to sufficient. However, an agent still lacks guidance on what the notes look like, how large they are, and what a failed lookup returns.

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% and the only documentation for maHs is a regex pattern. The description does identify the parameter's meaning ('for an HS code' / 'theo mã HS'), partially compensating, but does not clarify accepted formats, chapter-level vs heading-level codes, or whether dots/dashes are required.

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: returns chapter and heading notes of the Vietnam tariff nomenclature for an HS code. This implicitly separates it from siblings like tim_ma_hs (code lookup) or tra_thue (duty rates), but never names an alternative explicitly, so sibling differentiation is left to inference.

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?

There is no when-to-use statement, no prerequisites, and no mention of alternatives such as tra_cay_hs or tra_thue. The agent must infer from the noun phrase alone that this is the tool for explanatory notes attached to a chapter/heading.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds real behavioral context beyond that: a 50-item-per-call batch limit and the set of possible result statuses (in force, expired, amended/replaced). It does not mention auth needs, but the added context is meaningful.

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 purpose statement is front-loaded, but the description duplicates itself across English and Vietnamese (the closing Vietnamese sentence repeats the opening English one), so roughly half the content is redundant rather than additive.

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 read-only single-parameter lookup with no output schema, the description covers purpose, input format, batch limit, and the enumerable return states, which is sufficient for correct invocation. Only auth/permission context is absent.

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?

With a single parameter and 0% schema description coverage, the description carries the burden and does so well: it specifies soHieu is an array of strings, gives an example (["57/2022/NĐ-CP"]), caps it at 50 items, and explicitly warns a single string is rejected. These details go beyond the bare schema (which only enforces minItems 1).

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+resource ('Checks whether Vietnamese legal documents are in force by document number') and enumerates the outcome states (in force, expired, amended, replaced). None of the siblings (tax, procedures, HS codes) overlap, so the agent can route confidently.

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?

The purpose clearly implies when to use it and the description adds an input-shape constraint (array only, not a single string), but there is no explicit when-to-use/no-use guidance or named alternative. Usage is implied rather than spelled out.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safe-read profile is covered. The description adds format tolerance detail but discloses nothing further about behavior — no indication of what rate categories are returned, whether lookup is exact vs fuzzy, or failure modes.

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 efficient, but the Vietnamese text is a verbatim translation that roughly doubles length without adding information for a tool-selection agent. One language would have sufficed; the duplication dilutes conciseness.

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 simple two-parameter lookup with no output schema, the description covers input format adequately and annotations cover the safety profile. However, it says nothing about the shape or content of the returned duty information, which is a real gap when no output schema exists to fill it.

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?

With 0% schema description coverage, the description must carry parameter meaning, and it does: maHs accepts 4–8 digits with dots or spaces tolerated, and xuatXu is a 2-letter country code. That compensates well for the bare schema, though it doesn't say how dots/spaces are normalized or what happens with an invalid country code.

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+resource ('looks up Vietnam import duty rates') scoped to an HS code, which is a distinguishable function from sibling tools like tra_tien_le or tra_thu_tuc_nhap_khau. It does not explicitly name or contrast any sibling, so it lands just short of a 5.

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?

The description implies its use case (checking duty rates for a given HS code) but never states when to pick this over alternatives such as tra_tien_le or tra_cay_hs, nor any exclusions or prerequisites. Usage is inferable but nothing is spelled out.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered by structured data. The description adds useful substance beyond that by specifying the returned content (inspections, licences, legal documents with force status), but says nothing about invalid-code handling, coverage limits, or rate/auth constraints.

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?

Front-loaded with the action and scope in the first clause, followed by the return contents. The Vietnamese sentence is a near-verbatim translation rather than new information, which pads length slightly, but the whole definition remains compact.

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 sensibly enumerates the returned categories and their force-status dimension. For a single-parameter read-only lookup that is close to sufficient; only edge cases (invalid or non-existent codes, chapter coverage) are unaddressed.

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% and the single property 'maHs' is an undocumented string, so the description carries the semantic burden. It does so by stating the required format ('8-digit HS code'), which is the critical detail the schema omits, though it stops short of examples or leading-zero guidance.

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 (looks up) and resource (Vietnam import procedures) scoped to an 8-digit HS code, and enumerates what is returned: specialized inspections, licences, and governing legal documents with force status. This clearly separates it from domain siblings like tra_thue (tax), tra_cay_hs, and tim_ma_hs, though it never names an alternative.

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?

The phrase 'for an 8-digit HS code' implies the precondition for calling it, but there is no explicit when-to-use, when-not-to-use, or routing to siblings such as tra_thue for tax rates or tim_ma_hs when the code itself is unknown. An agent must infer the workflow from the domain wording alone.

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

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

The annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered and not contradicted. The description adds useful source context (TB-TCHQ notices) but says nothing about result limits, pagination, or what happens when no ruling matches, so it only modestly exceeds the annotation baseline.

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?

Two short sentences with the core purpose front-loaded and no filler. The second sentence is a straight Vietnamese restatement of the first, which is redundant for an English-reading agent but likely serves a bilingual user base.

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 simple read-only lookup this is nearly sufficient, but with no output schema the description should say something about the shape or nature of returned rulings, and it leaves the both-params-optional behavior of a zero-required-parameter search unexplained.

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 parameter meaning. It does map the two inputs implicitly (maHs = HS code, moTa = product description), which is genuine added value, but it never says whether at least one is required, whether both can be combined, or how the 3-300 character constraint on moTa and the null-allowed types affect a call.

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?

The description names a specific verb and resource: it looks up Vietnam customs classification rulings (TB-TCHQ notices), and states the two lookup modes (HS code or product description). It is distinguishable from siblings like tra_thue or tra_chu_giai, though it never explicitly contrasts itself with them, which keeps it from a 5.

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?

Usage is only implied: an agent can infer you call this when you need precedent classification rulings rather than tariff rates or explanatory notes. There is no explicit when-to-use statement, no exclusions, and no mention of the sibling tools (tim_ma_hs, phan_loai_hs, tra_chu_giai) that an agent might confuse with this one.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered; the description usefully adds that a lookup with an opinion number returns the full text plus a reference Vietnamese translation, which partially compensates for the missing output schema. It says nothing about coverage, truncation, or behavior when the HS code has no entry.

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?

Two compact sentences, front-loaded with the resource and selector, and the bilingual Vietnamese line mirrors the English rather than adding new content. Efficient, if slightly redundant by design for a Vietnamese-facing tool.

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 two-parameter, no-output-schema tool with minimal annotations, the definition covers the core lookup but leaves the ordinal parameter, empty-result behavior, and the HS-code/opinion-number relationship unexplained. Adequate but with clear gaps.

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 burden. It labels maHs ('mã HS') adequately, but the second parameter thuTu (integer 1-999) is never explained - it is unclear whether 'opinion number' refers to thuTu or is a derived value, and no format or selection rule for it is given.

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 ('looks up') and a precise resource ('WCO classification opinions (Compendium)') with the selector ('by HS code'), so the purpose is unambiguous. It does not, however, distinguish itself from near-neighbors such as tra_chu_giai or tra_tien_le, which also retrieve explanatory/opinion-like content.

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?

The 'by HS code / with an opinion number' phrasing implies the retrieval workflow, so usage is inferable, but there is no explicit when-to-use or when-not-to-use guidance and no sibling is named as an alternative. Given the crowded tra_* family, this leaves real routing ambiguity.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered without description help. The description adds value by disclosing the specific account attributes returned (quota, trial usage, consent), but says nothing about auth requirements or freshness of the data.

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 listing the four returned fields, with the Vietnamese translation mirroring it. The bilingual duplication is redundant for a purely English-reading agent but appears deliberate for the audience, and nothing else 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?

There is no output schema, so the description carries the burden of describing return content and does so by enumerating all four fields. Combined with readOnlyHint annotations, an agent has enough to call and interpret the result, though return formatting and units remain unspecified.

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?

The tool takes zero parameters, which is the baseline-4 case. The description correctly implies no inputs are needed to retrieve the account summary.

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?

The description names a specific verb (shows/displays) and enumerates the exact resource content: remaining points, today's trial uses, daily key quota, and data-sharing consent status. No sibling tool in the list covers account state, so there is no ambiguity to resolve.

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?

Usage is only implied — an agent infers it should call this when it needs the account's quota/consent state. There is no explicit when-to-use statement, no prerequisites, and no exclusions, though for a zero-parameter read tool the context is fairly self-evident.

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

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

Annotations already declare this is a non-read-only, non-idempotent, closed-world write. The description adds meaningful workflow context (a human OZ agent will contact, quote, and import on the user's behalf, gated on consent), which is beyond the annotation set. It still omits what is actually created, timing, and any post-submission behavior, so the addition is moderate rather than rich.

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 core action and the consent guard are front-loaded and there is no filler. The English sentence is mirrored in Vietnamese, which is redundant for a reader of one language but is a plausible localization choice rather than padding.

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 mutation tool with 7 parameters, no output schema, and 0% schema description coverage, the description explains the workflow but leaves the entire parameter contract undocumented. An agent must guess at the meaning and expected format of most inputs, which is a substantial gap for a non-idempotent submission.

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% across 7 parameters, so the description carries the full documentation burden and does not meet it. It implicitly touches two fields ('this item' ~ tenHang, consent ~ dongYLienHe) but never explains maHs, soLuong, ghiChu, linkSanPham, or maLuotLienQuan, leaving most parameters opaque.

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?

The description states a specific verb ('Submit a request') and resource ('OZ staff to quote and import this item on your behalf'), so an agent can immediately tell it initiates an import/quote request rather than a lookup. Among siblings that are almost all tra_* lookup tools this is clearly distinct, though it does not explicitly differentiate itself from the other submission tool gui_phan_hoi.

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?

It gives an explicit precondition: 'when the customer agrees to be contacted' / 'Chỉ dùng khi khách đồng ý để OZ liên hệ', which is a genuine when-to-use gate matching the required dongYLienHe=true. It stops short of naming alternatives or stating when NOT to use it beyond that single condition.

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