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?

With annotations already declaring non-read-only and non-destructive behavior, the description adds important context: it re-queues the job, does not charge again, and attaches facts to the exact lines that requested them. It does not cover permissions or response details, but it meaningfully exceeds what the annotations provide.

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, but the description repeats the same content in Vietnamese, roughly doubling length without adding new information. The duplication weakens conciseness despite the clear initial statement.

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 tool with no output schema, the description covers the triggering conditions, re-queue behavior, no-extra-charge guarantee, and line-specific fact insertion. It is nearly complete, though it omits expected return behavior and detailed boSung formatting.

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 explain the two parameters. It identifies maLuot as the receipt code and boSung as the facts to add, but it does not explain the format, length limits, or expected structure of boSung beyond the general notion of facts for listed lines.

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 mutation action (adds facts to a background job), the resource (finished-but-incomplete job identified by maLuot), and the exact result states that trigger it (CAN_DU_KIEN, K2 NEED_FACTS, HO_SO_THIEU_DU_KIEN). It clearly distinguishes this repair/re-queue operation from sibling classification and declaration-check 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?

It gives precise when-to-use conditions: after a background job finishes with an incomplete status and the user has answered the listed questions. It does not explicitly name alternatives or when-not cases, but the triggering statuses make the intended context 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?

With annotations already declaring readOnlyHint=false, openWorldHint=true, and idempotentHint=false, the description adds substantial context beyond them: it explains the output evidence labels, mentions sources, clarifies input media limitations, and notes the image field is disabled due to an internal host block. It does not explain why the operation is not read-only (e.g., side effects) or detail any rate limits.

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 description is front-loaded with purpose and return structure, and the Vietnamese portion adds non-redundant constraints (no HS code, no e-commerce page reading, unused image field) rather than merely repeating the English. It is somewhat longer than minimal due to bilingual phrasing, but every part contributes specific 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?

Given no output schema, the description adequately explains the return shape (attribute frame, evidence label, sources). It also covers input constraints and operational limitations. It does not specify failure behavior (e.g., no match found) or source selection logic, which are minor gaps for a tool of this complexity.

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 compensate. It does so by mapping the five parameters: tenHang (name), model, thuongHieu (brand), moTa (short description), and explicitly stating that anhUrl (image) is currently unused. It falls short of detailing format constraints, precedence, or examples, but covers all parameter roles adequately.

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 ('Identifies') and resource ('a product from a text description'), and specifies the exact output ('attribute frame ... with evidence label HYPOTHESIS / CORROBORATED / VERIFIED and sources'). It explicitly distinguishes from sibling tools by stating 'KHÔNG trả mã HS' (does not return HS code), which separates it from HS-code lookup/classification siblings.

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 clear context: input is text (name, model, brand, short description), it does not read e-commerce platform pages, and the image field is currently unused. However, it does not explicitly name alternative tools for HS code queries or state a preferred ordering relative to them, leaving the 'instead of' mapping implicit.

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 already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuinely useful behavior: the three status values, that LOI refunds points, that XONG returns a full review shape with K2 NEED_FACTS / HO_SO_THIEU_DU_KIEN lines, and the cost model. It does not cover result expiry or polling cadence, so it sits at a solid 3 rather than higher.

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 same content is delivered twice, once in English and once in Vietnamese, which doubles length without adding information. The opening sentence is also corrupted by the 'maLuot:' splice, hurting front-loading. Under-specification is not the issue; redundancy and mangled structure are.

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 read tool with no output schema, the description supplies the status vocabulary, the refund behavior on failure, and the shape of a completed result, which is most of what an agent needs to interpret the response. Missing only lifecycle details such as retention or retry timing.

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 parameter meaning; it does identify maLuot as the 'mã lượt biên nhận' (receipt/turn code) for a background run, which is more than the bare string schema. It gives no format, sourcing guidance, or what to do when the code is unknown, so it only partially compensates.

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: retrieves the state and full result of a background declaration code check, keyed by receipt code. This is distinguishable from the sibling kiem_ma_to_khai (the likely initiator), though it never names that sibling. The purpose is clear despite the garbled 'receipt maLuot:' splice.

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 presence of DANG_XU_LY ('still working') signals polling, and the note that it is free with points charged once at the receipt hints at repeated calls. However, it never says when to call this vs kiem_ma_to_khai, how often to poll, or how long results persist.

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?

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.

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.

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

Annotations only declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false, so the description adds real value: it discloses the point cost, the signed-in-account requirement, the external/registered-database scope (China and Vietnam), and a 'reference only, not a legal opinion' disclaimer. That is meaningful beyond the annotation set, though it says nothing about failure modes or latency of the image-matching gateway.

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?

Each language version is front-loaded and efficient, but the English and Vietnamese sentences are near-identical restatements, so roughly half the text carries no new information for an agent that reads either language. Functional for localization, but it doubles the surface area without adding semantics.

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 carries the burden of describing returns and does so: most similar registered trademarks from China and Vietnam with a similarity score, plus the disclaimer that these are machine image matches. Missing only pagination/result-count behavior and error handling, which are minor for a single-parameter lookup.

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 parameter urlAnh carries only format=uri and maxLength in the schema. The description compensates by specifying that the parameter is an image URL and must be https, which is precisely the constraint an agent needs beyond the schema's generic uri format.

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 gives a specific verb and resource with a clear modality: 'Checks trademark (IP) risk from a product logo image', and states the output is the most visually similar registered trademarks with a similarity score. It distinguishes image-based checking ('bằng ẢNH logo') from a plain trademark check, though it never explicitly names sibling kiem_tra_shtt (the likely text-based counterpart), so the differentiation is implicit rather than stated.

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?

Input conditions are given ('give an https image URL') plus prerequisites (paid in points, signed-in OZ account), which is useful operational context. However, there is no explicit when-not-to-use guidance and no routing to alternatives such as kiem_tra_shtt for text-based trademark lookups, leaving selection between the two to inference.

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 readOnlyHint=false, openWorldHint=true, idempotentHint=false, and the description explains why: each call creates a 'lượt' (turn) and returns {maLuot, trangThai: DANG_XU_LY} while processing, so calls are not idempotent and are consistent with the non-read-only hint. It also discloses that GIR rules and legal basis are quoted verbatim from the backend. It does not state latency/rate limits or failure behavior, keeping it short of a 5.

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 important content is front-loaded, but the description is written twice in near-identical English and Vietnamese, which doubles length without adding information. The final async-receipt sentence is valuable and would stand on its own; the duplication is the main waste.

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, and the description usefully covers the deferred-return shape (maLuot, DANG_XU_LY) and that results are fetched by turn code. For a 6-parameter tool with 0% schema description coverage, though, it leaves dinhDanh undocumented and does not clarify how the textual fields are combined or which are truly optional in practice.

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 loosely maps the textual inputs (tên hàng, chất liệu, công dụng, thông số) onto tenHang/chatLieu/congDung/thongSo and describes nguonThongSo's semantics (source of the specs: ANH, LINK, CHU). However the dinhDanh identity object (frame/xacMinh) is entirely unexplained and no enum value meaning beyond the gloss 'where the specs come from' 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 and resource: suggests Vietnam HS codes for a product from a text description, with alternative codes and GIR/legal citations. The scope limits (text-only, no images or marketplace links) make it operationally distinguishable. It never names a sibling such as tim_ma_hs, so the differentiation is implicit 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?

Gives real usage context: input must be a textual description (name, material, use, specs), not images or marketplace links, and nguonThongSo must record where the specs came from. It also explains the deferred mode: the gateway returns a receipt and status/result are fetched with the same turn code. No explicit when-not-to-use or alternative-tool routing is stated.

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 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.

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.

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.

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.

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.

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.

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, requires a signed-in account, and produces only a draft the declarant must review. Annotations only cover readOnly=false, non-idempotent, non-destructive, open-world, so the cost/auth/draft caveats are genuinely additive.

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 earns its place, but the Vietnamese paragraph is a near-verbatim duplication of the same content, roughly doubling length for no added information. Deliberate bilingual coverage, but it costs 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?

Covers purpose, cost, auth requirement, and the draft caveat well, which matters for this paid non-idempotent tool, and there is no output schema to explain. However, with 11 undocumented parameters and no schema descriptions, an agent lacks the input semantics needed to call it 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 description coverage is 0% across 11 parameters, so the description carries the burden but documents almost none of them. It only hints indirectly at maKhai (declared code), maHaiQuan (code the customs office wants), and taiLieuCo (supporting documents); loai, hanTraLoi, lyDoHaiQuan, hangDangBiGiu, and others are unexplained.

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 (drafts) and resource (customs explanation file for a Vietnam HS code dispute), and enumerates the actual deliverables: draft letter, code comparison, argument outline, weak points, supporting documents. This clearly distinguishes it from siblings like soat_to_khai or phan_loai_hs.

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 a clear trigger condition — use when the customs office applies a different HS code ('khi Hải quan áp mã HS khác'). It does not name alternatives (e.g., yeu_cau_chuyen_gia_oz for expert escalation) or state when not to use it, so it stops short of explicit routing.

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 read-only and closed-world behavior, but the description adds substantive context beyond them: it is free for signed-in users (implying an auth requirement), makes no AI call (deterministic), and explicitly reports the HS-description check as 'not checked' rather than silently omitting it. That limitation disclosure is exactly what an agent needs to interpret results correctly.

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 is front-loaded and the check list is well structured, but the entire description is duplicated verbatim in Vietnamese, doubling length without adding information for an agent. Every sentence in the English half earns its place; the mirror half is pure redundancy.

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 complex nested-input review tool with no output schema, the description covers what is checked, what is not, and the auth/cost profile, which is most of the behavioral burden. It is still thin on how results are surfaced (a sibling ket_qua_soat exists) and on the meaning of the less obvious input fields.

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 schema supplies names and formats but no meaning. The description partially compensates by mapping check topics to likely fields (description→moTa, duty rate→thueSuatKhai, ACFTA/Form E→coFormE, licences→giayPhepCo, value→triGia), but never documents the line-item array, loaiHinh, or ngayDuKienDangKy, and gives no format or constraint 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?

The description states a specific verb and resource ('Reviews a draft customs declaration line by line before it is filed') and enumerates the exact checks performed (description quality, duty rate, ACFTA/Form E, licences, value sanity, technical file). It also draws a boundary against the description-to-HS-code check that sibling tools handle, though it does not name that sibling explicitly.

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 implies the usage window ('before it is filed') and discloses the one check it does not run, which helps an agent avoid misusing it. However, no alternative tool is named for the omitted HS-code check, and there is no explicit when-to-use / when-not-to-use routing beyond that single negative statement.

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 cover safety (readOnlyHint=true, openWorldHint=false). The description adds meaningful context beyond them: it discloses that the returned figures are reference data that must be re-verified with a local agent before finalizing — an important reliability caveat for a lookup tool. It stops short of saying how data is sourced or refreshed.

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 efficient, but the Vietnamese sentence largely restates the English content plus the caveat, so roughly half the text is duplicative. It is short overall, but not every sentence earns its place.

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, no-output-schema read tool with annotations, coverage is adequate: it says what facts come back and warns about verification. The notable gap is that no product/HS code is accepted yet duty rates normally depend on the goods, leaving an agent unclear about the granularity of the returned rates.

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?

Only one parameter exists and schema description coverage is 100%, so the schema already documents the destination country with its own example. The description reinforces that the lookup is keyed on destination country but adds no syntax or format guidance beyond the schema, so the 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?

The description names a specific verb+resource: looking up destination import facts (duty rate, origin preferences, required documents) for third-country direct trade, and even gives a worked example. It does not, however, distinguish itself from close siblings like tra_thue or tra_thu_tuc_nhap_khau, which appear to overlap on duty and procedure lookups.

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 by the 'third-country direct trade' scoping and the closing caveat to verify with a local agent before finalizing, which signals this is advisory reference data. But no explicit when-to-use/when-not or alternative (e.g., when to prefer tra_thue for tariff details) is stated despite several overlapping 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 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 only say this is a non-read-only, non-destructive write. The description adds real behavioral context beyond that: it is free for signed-in users, requires a phone number and explicit consent to be contacted, and the specialist can view the referenced run's contents only with per-invocation permission. That per-run privacy behavior is not derivable from the schema or 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?

The content is front-loaded and each English sentence is useful, but the entire description is duplicated verbatim in Vietnamese, roughly doubling its length. If bilingual output is a deliberate product requirement this is defensible, but it is still redundancy 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 5-parameter, all-required, zero-coverage mutation tool with no output schema, the description covers cost, consent, and privacy well but leaves the urgency parameter unexplained and gives no sense of what happens after the request is filed. Adequate but with a visible gap.

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. It explains soDienThoai (phone number), dongYLienHe (agreement to be contacted), and choPhepXemNoiDung (per-run content permission), and implies maLuot is the prior run. It says nothing about mucGap, the urgency enum (THUONG/GAP/RAT_GAP), which is the one parameter an agent could easily set wrong.

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: ask an OZ customs specialist to call you back about a declaration review or HS-code dispute run you already completed. That is concrete enough for an agent to select it. It does not, however, differentiate itself from the sibling yeu_cau_dat_qua_oz, which an agent must disambiguate on its own.

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 by 'a declaration review or HS-code dispute file you already ran', which tells the agent a prior run must exist. There is no explicit when-not-to-use, no prerequisites (other than being signed in), and no routing guidance against the very similar yeu_cau_dat_qua_oz sibling.

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.