Customs-Bridge

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

With no annotations, the description carries the full disclosure burden. It usefully names the tariff regime (CCT/MFN) so the agent knows preferential treatment is not applied, but it omits whether the operation is read-only, whether any auth is needed, and whether results are advisory or binding. Some behavioral context, but clearly incomplete.

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 tariff basis and input units are stated immediately and nothing 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?

There is no output schema and no annotations, so the description should ideally describe what is returned (duty rate, duty amount, VAT) and any caveats. The calculation scope is clear, but the return shape and operational details are left 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?

Schema description coverage is 100%, so the schema already documents all three parameters including defaults and formats. The description only restates hs_code and customs_value_eur at a high level and adds nothing about the optional origin_country's effect on the result (e.g. preferential rates), so 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?

States a specific verb (calculates) and resource (official EU customs duties under Common Customs Tariff/MFN plus import VAT), and scopes the required inputs (HS code, CIF value in EUR). This is clearly distinguishable from siblings like resolve_hs_code or check_import_restrictions, which resolve codes or restrictions rather than computing duty amounts.

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 mention of 'EU' and 'MFN' implies the applicable context (EU imports, non-preferential rates), but there is no explicit when-to-use guidance and no routing to or away from sibling tools such as resolve_cbam_and_antidumping. Usage must be inferred.

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 no annotations, the description carries the full behavioral burden. 'Checks' implies a read-only lookup, but nothing is said about authentication (a sibling provisions an API key), rate limits, whether results are point-in-time or cached, or how multiple restriction types are returned.

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 naming the action and the categories of output, with no filler. It is slightly terse for a compliance-lookup tool but wastes nothing.

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 read-only check with no output schema, the description covers what is being evaluated. It still omits when to use it, how origin_country (default CN) affects results, and what the caller should expect back.

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 taric_code and origin_country are already documented in the schema. The description adds domain context about what is checked but no syntax or format detail 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 states a specific verb ('Checks') and resource ('EU import restrictions, document codes, compliance directives'), with concrete examples (CE, REACH, CBAM, CHED). It does not, however, differentiate itself from siblings like resolve_cbam_and_antidumping, which overlaps on the CBAM topic.

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 guidance on when to run this check versus calculate_customs_duties or resolve_cbam_and_antidumping, nor any stated prerequisites (e.g. needing a resolved TARIC code first). Usage is only implied by the domain wording.

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?

No annotations are provided, so the description carries the full burden. It discloses the sandbox nature and 50-credit grant, which is useful, but says nothing about whether an account is created, whether email verification or a confirmation step is required, rate limits, idempotency, or how/where the key is delivered.

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 that leads with the action and resource. It is efficient, though the trailing benefit clause ('unlock advanced CBAM carbon calculations and factory-specific anti-dumping duty codes') is somewhat promotional rather than operational.

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?

This is a provisioning/mutation-style tool with no annotations and no output schema, so the description must explain the side effects and result. It omits what the caller receives (the key itself), whether state is created server-side, and any preconditions — leaving real gaps for an agent deciding whether to call 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?

Schema description coverage is 100% and both parameters are documented in the schema, so the baseline is 3. The description adds no syntax or format detail beyond the schema (e.g., no guidance on what a valid developer_email or a useful use_case looks like).

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 ('Provisions a free sandbox API key') and adds scope detail (50 credits, what it unlocks). It is clearly distinguishable from the sibling calculation/lookup tools, though it never names or contrasts them 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?

Usage is only implied: the phrase 'for agents to unlock advanced CBAM carbon calculations and factory-specific anti-dumping duty codes' suggests when you'd want it, but there is no explicit when-to-use/when-not-to-use guidance, no statement of prerequisites, and no mention of alternatives.

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 no annotations, the description carries the full behavioral burden. It conveys that duties computed are 'definitive' (a meaningful legal distinction) but says nothing about authentication (an api_key parameter exists), whether results are binding/estimates, rate limits, or failure behavior for unlisted codes.

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 with zero filler, front-loading both outputs (duties and CBAM obligations) before the material scope. Nothing is repeated from the schema or wasted on preamble.

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?

This is a 5-parameter financial computation tool with no output schema and no annotations, so the description should explain what comes back (per-line duty amounts, CBAM cost breakdown, currency, totals). It instead stops at stating the domain, leaving the agent unable to anticipate the response or the auth flow.

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% (5/5 parameters documented, including the api_key and origin_country default), so the schema already does the heavy lifting. The description adds no parameter-level meaning such as accepted code formats or what omitting weight_kg does for CBAM calculation, so the baseline of 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 gives a specific verb (computes) and two concrete resources (EU anti-dumping duties and CBAM carbon financial obligations), plus the covered commodity scope (steel, aluminium, sensitive imports). An agent can tell this apart from the generic 'calculate_customs_duties' sibling by domain, though it never explicitly names or contrasts that sibling.

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 guidance: nothing says when this tool should be chosen over calculate_customs_duties or check_import_restrictions, nor any preconditions (valid TARIC code, origin country required). Usage must be inferred entirely from the commodity scope in the sentence.

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?

No annotations are provided, so the description carries the full burden. It does disclose the useful behavioral fact that the tool returns a hierarchical path plus the official designation rather than a flat match, but it omits whether this is a read-only lookup, whether it requires auth, and error behavior for invalid codes.

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 verb and scope come first. It is terse enough that nothing is wasted, though there is no room for the usage details that are missing.

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?

This is a lookup tool with no output schema, so the description must sketch the return shape. It names the two returns (hierarchy, official designation) but gives no structure for them, and with no annotations there is nothing else covering 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 coverage is 100%, so the schema already documents both the hs_code and its code alias. The description's mention of 'code SH6 ou TARIC' narrows the accepted value types slightly but adds no format, syntax, or precedence guidance for the alias.

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 (resolves) and two concrete outputs (hierarchical tree and official designation) for a specific resource (HS6 or TARIC code). It is distinguishable from siblings like search_customs_nomenclature or calculate_customs_duties, though it never names or contrasts with them 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?

There is no statement of when to use this tool versus the alternatives (search_customs_nomenclature, resolve_cbam_and_antidumping), nor any precondition or scenario guidance. Usage can only be inferred from the verb 'resolve'.

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 no annotations, the description carries the full burden, yet it only names the search backend (FTS5) and the bilingual scope. It says nothing about matching semantics (stemming, partial words, ranking), result ordering, or how the default limit of 5 behaves.

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; scope (bilingual FR/EN, TARIC) comes first. The FTS5 detail is arguably implementation trivia, but it does not bloat the definition.

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?

A three-parameter search tool with no annotations, no output schema, and only one documented parameter leaves the agent guessing about result shape, ranking, and pagination behavior. Given the missing structured coverage, the description should say considerably more.

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 33%; only 'query' is documented, and 'limit' is entirely unexplained in both schema and description. The FR/EN mention implicitly informs the 'lang' enum, but the description adds no syntax, matching, or count semantics beyond that.

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: textual search in the TARIC nomenclature. It is clearly distinguishable in kind from calculate_customs_duties or check_import_restrictions, but never names or contrasts with the closest sibling, resolve_hs_code, so an agent must infer which lookup path to take.

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 when-to-use guidance at all: nothing says to prefer this for fuzzy/keyword lookups versus resolve_hs_code for exact code resolution, and no prerequisites or exclusions are given. The agent only learns what the tool is, not when to reach for it.

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