HLN Apparel — clothing manufacturer

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

Annotations already declare readOnlyHint, idempotentHint, nondestructive, and closedWorld, so the safety profile is fully covered. The description adds one genuine behavioral fact beyond the annotations: the response also includes a list of garments typically made at that weight class. It does not mention rounding or precision of the conversion, so it is adequate but not 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?

A single sentence, front-loaded with the conversion action and followed by the secondary payload. No filler, no restatement of the title or parameter names.

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 pure read-only computation with 100% schema coverage and no output schema, the description is nearly sufficient, and explicitly mentioning the garment list compensates for the missing output schema. It only falls short of complete by omitting conversion precision and the both/neither-parameter behavior.

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 100%, so both params are already documented with units and bounds, giving a baseline of 3. The description implies a one-of-two-unit conversion but never states the relationship between the two parameters, so it adds no meaning the schema lacks.

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 ('Convert'), an unambiguous resource ('fabric weight between GSM and ounces per square yard'), and even discloses a secondary function (listing typical garments). None of the sibling tools overlap with unit conversion, so it is trivially distinguishable. An agent knows exactly what this returns without opening the schema.

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?

No guidance on when to call this versus anything else, and no note on direction of conversion (supply oz or gsm?) or what happens if both/neither are provided. Usage is only inferable from the purpose statement. With no exclusions or prerequisites stated, this is the weakest dimension.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the useful fact that the payload is a fixed informational profile rather than a live query, but says nothing about caching, freshness, or response shape.

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 tight clause with the subject front-loaded and zero filler. It is a noun-phrase fragment rather than a sentence, but it communicates scope efficiently.

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 it does so by enumerating the profile sections. It omits the language parameter's effect on output, which is the only notable gap for such a simple read-only tool.

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 100% and the single language parameter is fully documented with an enum in the schema, so the baseline of 3 applies. The description adds no information about language behavior (e.g., whether content is translated or only the wrapper).

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 resource (HLN Apparel company profile) and enumerates the exact content it covers (founding year, quality standard, audits, shipping terms, scale, page links). It is clearly distinguishable from every sibling, none of which deal with company background, though the retrieval verb itself is only implied by the tool name.

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 this is for company-background questions, but there is no explicit statement of when to call it, no prerequisites, and no reference to alternatives (e.g., vs. list_product_categories for catalog data).

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 readOnly, idempotent, non-destructive, closed-world behaviour, so safety is covered. Because there is no output schema, the description's enumeration of returned fields (fabrics, GSM range, MOQ, sample time, lead time, size range, customisation options, page URL) is genuinely load-bearing return-shape information that the agent would otherwise lack.

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 with no filler; the field list is dense but each item adds real information about what comes back. Slightly long as a run-on enumeration, but nothing 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?

For a zero-required-parameter, read-only list tool with no output schema, the description supplies the missing return-shape detail and relies on the schema for the language option. An agent has enough to call it correctly, though it doesn't say whether the result is a flat list or paginated.

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?

One optional parameter with 100% schema description coverage and an enum (en/es/fr), so the schema fully documents it. The description adds nothing about how language affects the returned category data, 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 the resource (garment categories HLN makes) and enumerates the data each entry carries, so an agent can tell this is a catalogue-retrieval tool. It lacks an explicit verb like 'list' or 'retrieve', but the content is specific and clearly distinguished from every sibling (none of which deal with categories).

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 statement of when to call this tool, what triggers it, or what to use instead when the agent needs factory, fabric, HS-code, or inquiry data. Usage is only inferable from the content list.

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, idempotentHint, destructiveHint=false and closed-world, so the safety profile is covered. The description adds genuinely useful context beyond that: results are 'suggested' (not authoritative determinations) and each row carries its provenance, the CBP ruling it is based on, plus that the total rate is China-specific including Section 301. That provenance/reliability signal is not derivable from 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?

A single sentence that is front-loaded with the primary payload (suggested HS codes) and then layers the duty-rate detail. It is dense but every clause earns its place; no filler or repetition.

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 zero-required-parameter read-only lookup, the description covers what the tool returns and where the data comes from, and the schema covers the only input. Without an output schema the description must carry the return-shape burden, and it does so competently. The gap is the absence of any usage framing or statement of scope/limitations of the 'suggested' codes.

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 100% and the single 'group' parameter is fully documented in the schema, including the 'omit for every row' default behaviour. The description adds nothing about filtering by garment family, so the baseline of 3 is appropriate.

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 the resource precisely (HS codes for garments) and enumerates the exact data returned: US HTS line, general duty rate, China total rate with Section 301, and the underlying CBP ruling. That is specific enough to separate it from siblings like convert_fabric_weight or get_factory_overview. The only weakness is that the action verb is implied rather than stated — the text reads as a list of outputs for an unstated lookup.

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 or when-not-to-use guidance, no mention of the sibling tools, and no indication of prerequisites or context (e.g. when classifying a garment for import paperwork). The agent must infer the trigger condition entirely from the tool name.

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 'Sends nothing' and produces a confirmation_token that gates the real submission — an important non-obvious two-phase contract. It does not cover what the summary contains in detail or what happens if validation fails, so it stops short of full disclosure.

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?

Four short sentences, each carrying a distinct payload (sequencing, side-effect status, next step, input policy). The most decision-relevant fact, 'Step 1 of 2' and 'Sends nothing', is front-loaded.

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 correctly names the return values (summary and confirmation_token) and explains how to use them. Combined with the annotation-covered safety profile and a fully documented schema, an agent has everything 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 coverage is 100%, so the schema already documents all ten parameters and the baseline is 3. The description still adds decision-level meaning by tying the four required fields to an 'ask, don't guess' policy and by reinforcing the message parameter's anti-fabrication intent.

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?

Opens with a specific verb and resource ('Checks a quote request'), states the domain (HLN Apparel) and the outputs (summary plus confirmation_token). 'Step 1 of 2' plus the named sibling submit_inquiry makes the division of labor unambiguous to an agent comparing the two.

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 prescribes the workflow: show the summary to the buyer, get confirmation, then call submit_inquiry. It also gives a fallback rule for missing data ('ask for missing name, email, quantity or requirements instead of guessing'), covering both the sequencing and the input-gathering decision.

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 not-read-only, open-world side effects and idempotency, so the bar is lower; the description still adds real value by disclosing the outbound email receipt and that attachment links are downloaded and stored privately. It does not address what happens on duplicate or failed submission, which would matter given idempotentHint=true.

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?

Three short sentences, zero waste, with the sequencing and precondition front-loaded before the side effects.

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 an 11-parameter mutation with no output schema, the description covers the gating flow and the observable outcome (sales team notification, buyer receipt, private attachment storage). It stops short of describing failure/retry behavior or what a returned confirmation looks like, which the absent output schema forces the agent to guess.

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 100% with per-field descriptions, so the schema does the heavy lifting. The description only reinforces that field values must be identical to the preview_inquiry payload and that confirmation_token must be carried over — useful but marginal.

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 (sends the confirmed quote request to the HLN sales team) plus a secondary effect (emails the buyer a receipt). The 'Step 2 of 2' framing and the reference to preview_inquiry make it unmistakable which sibling precedes it.

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?

Names the explicit gating condition — only after the buyer confirmed the preview_inquiry summary — and adds the data-consistency requirement (same fields, same confirmation_token). An agent knows exactly when to call this and when not to.

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