USTariffRates

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

With no annotations provided, the description carries the full behavioral burden and does so well: it discloses API-key authentication, the source of reviewed CBP instruction histories, governing message metadata, effective dates, content hash, fallback logic, refusal reasons, excluded_from_order behavior, and the limits of scope evaluation and estimate status.

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 dense but well front-loaded: access requirement first, then core purpose, fallback rules, exclusion behavior, and caveats. Every sentence adds useful operational context without wasted phrasing.

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 tool with no output schema and no annotations, the description is quite complete on behavior, source data, return concepts, and caveats. It still leaves some parameter semantics and output-shape details implicit, especially around optional fields like customs_value_usd.

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 low at 43%, so the description must compensate. It adds meaning for exporter/producer matching and case context, but does not explain several parameters such as customs_value_usd, country versus exporter_country, or the full meaning of as_of relative to entry date.

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 resource and scope: the current CBP cash-deposit rate for one AD/CVD case, exporter, producer, and entry date. It clearly distinguishes this from general tariff or duty tools by naming AD/CVD, CBP instructions, and all-others/excluded-from-order handling.

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 decision logic for named exporter/producer combinations versus the all-others rate, and explains that excluded combinations return excluded_from_order. It does not explicitly compare this tool to siblings such as calculate_duty or lookup_tariff, but the AD/CVD-specific context makes the intended use 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?

No annotations are provided, so the description carries the full disclosure burden. It discloses API-key access, metered per-call billing, null propagation for missing customs value and requirement facts, pagination and restart behavior for AD/CVD discovery, and explicit scope limits such as not being a full landed cost or clearance and not verifying evidence.

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 dense but well ordered: access and purpose first, then required fields, omitted-value behavior, discovery pagination, metering, and scope limits. Every sentence adds operational information, and there is no filler.

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 18-parameter assessment tool with no annotations and no output schema, it covers the key invocation behavior and major failure modes. It remains short of fully complete because it does not describe the response shape and misstates the required set by omitting line_id.

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 baseline is 3. The description adds useful omission semantics for customs_value_usd, requirement_facts, case_numbers and adcvd_cursor, but it also says only hts_code, country and as_of are required even though line_id is required by the schema, creating a potentially misleading required-parameter statement.

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 assesses tariff treatments, AD/CVD cases and import requirements for one entry. It also scopes the tool with phrases such as 'one entry' and 'not a full landed cost,' but it never names a sibling tool such as calculate_duty or screen_import_requirements, so sibling routing 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?

It gives substantive usage conditions: API key required, omit customs_value_usd when unknown, omit requirement_facts when unknown, and omit case_numbers to start AD/CVD discovery. It also explains how to continue with adcvd_cursor, but it does not explicitly say when to choose a sibling tool instead, so full alternative routing is not provided.

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. It usefully discloses the key-tier gating, that results include 'coverage boundaries' (i.e. rate ranges it cannot audit), and provenance — real behavioral value. However, it says nothing about whether the call is read-only, what happens to unsupported HTS lines, or error behavior on oversized/malformed line sets, which matters for a tool with a 200-line nested payload.

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 sentences, no filler, front-loaded with the access prerequisite followed by the action and return shape. Slightly imperfect ordering — the operational behavior matters more than the key tier to an agent deciding whether to call — 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?

The input schema is enormous and deeply nested (line-level facts, chapter 98/99 declarations, agricultural safeguards), yet the description never explains how 'lines' drives the audit or what a coverage-boundary result looks like in practice. There is no output schema, so the brief return-value summary is necessary but thin 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 only 25% across 4 parameters; mode, as_of, and entry_number have essentially no schema documentation. The description only hints that input is organized 'by entry line' and adds nothing about as_of (which pins the rate version) or entry_number (provenance linkage). 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?

Names a specific verb and resource ('Audit declared duty against supported rates by entry line') and states the output shape (discrepancies, coverage boundaries, provenance). This implicitly distinguishes it from calculate_duty, which computes duty rather than checking a declared figure, though it never names 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?

The audit scenario (a filed entry with declared duty already present) is implied by 'audit declared duty against supported rates', and the access tier requirement is stated. But there is no explicit when-to-use guidance and no routing to calculate_duty, assess_import_entry, or screen_import_requirements for adjacent tasks.

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 and does add real value: it discloses the authentication modes (API key, OAuth, x402 payment) and the return structure (import charges vs. landed cost). However, it omits error behavior, what a 'supported' layer means, and the fact (buried in the schema) that unrecognized fact keys are rejected and that unimplemented claims return a review response rather than a total.

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 sentences, no filler, and the output-shape sentence earns its place. Minor flaw: the definition leads with the access/payment sentence rather than the purpose, so the most decision-relevant content is not 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?

For a 13-parameter tool with deep nested objects, one enum, no output schema, and no annotations, the description is far too thin. It explains the result shape but leaves the agent guessing about the two distinct ways to declare special treatment (facts vs. claims vs. chapter99), quota handling, and the many undocumented scalar parameters.

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 38% – well below the 50% threshold – so the description must compensate, and it does not: hts, country, value, mode, as_of, quota_state, product_content, component_values_usd, alcohol_by_volume_percent, and quantities receive zero mention. The one arguably central argument, facts, is documented only inside the schema, not the 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?

States a specific verb+resource+scope: 'Calculate supported US duty layers and fees for one import line'. An agent can tell this is a duty computation, not a lookup (lookup_tariff) or a comparison (compare_tariff_codes). It stops short of naming siblings or distinguishing itself from assess_import_entry, and 'supported' is left unqualified.

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 / when-not-to-use guidance and no named alternative. The clause 'without estimating fact-dependent treatment' hints at a boundary but does not tell the agent which tool to reach for when facts are unknown, or how this differs from assess_import_entry or replay_tariff.

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 and discloses API-key authentication, edition-aware/historical resolution, a five-target cap, cursor pagination, and the non-binding nature of results. It still does not explicitly state read-only behavior, side effects, or 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 four compact sentences covering access, purpose, capabilities, and a caveat, with no repetition. It is mostly front-loaded, though the API-key note precedes the core purpose.

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 complex tool with 10 parameters, no annotations, no output schema, and very low schema description coverage. The description gives high-level capability but omits enough parameter and return-value detail that an agent cannot confidently know how to invoke 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 only 10%, and the description helps by explaining as-of/history, editions, the five-target cap, pagination, and the country/system scope. It does not explain the required code/source/target relationship, include values, or limit/cursor semantics for most of the 10 parameters.

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 operation—finding edition-aware concordance candidates across China, US, EU, GB, and Brazil tariff systems—and the resource being compared. It implies cross-system comparison but does not explicitly contrast with siblings such as lookup_tariff or search_tariffs.

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 use for cross-system concordance and notes candidates are non-binding classification leads, which is useful context. However, it never states when to use this tool instead of lookup_tariff/search_tariffs or when it is inappropriate.

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 and does well: it discloses that an API key is required, enumerates what comes back (date, subject, cited HTS codes, later/earlier rulings), flags that some fields only appear 'when extracted', and warns that a ruling binds only the merchandise it was issued for. Missing only things like error behavior for unknown ruling numbers or pagination/size 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?

Front-loaded with the access requirement and the core operation, then the return detail, then the binding caveat — the ordering is sensible. It is a single dense sentence with long enumerations, slightly heavy for a one-parameter lookup.

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?

No output schema exists, so describing the returned fields is essential and the description does it thoroughly, plus auth and a domain caveat. For a simple single-argument lookup it is nearly complete; only error/not-found behavior is 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 coverage is 0%, so the description must compensate, and it does by giving two concrete ruling-number examples (N338012, H313152) that convey the expected format beyond the bare regex pattern. It does not explain the letter prefix convention or the length bounds, keeping it short of a 5.

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 ('One CBP CROSS ruling by number') and anchors it to the equivalent REST endpoint, so the agent knows exactly what it retrieves. The examples (N338012, H313152) and the enumerated return fields make its scope unambiguous versus the sibling search_rulings.

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?

'One ... ruling by number' strongly implies lookup-by-identifier rather than keyword search, which routes the agent away from search_rulings. It never explicitly names search_rulings or states when not to use this tool, so it falls short of a full when/when-not 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?

With no annotations at all, the description carries the full burden. It does disclose a real behavioral trait the schema cannot express — the Pro API key requirement — and clarifies results are customer-scoped (no cross-account leakage). However it omits ordering, pagination behavior implied by before/before_id, and what a change record contains.

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 tight sentences with the access constraint front-loaded, which is the right ordering for a gated endpoint. No wasted words, though the second sentence could have carried slightly more load given the description's brevity.

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?

Six parameters at 17% schema coverage with no annotations and no output schema is a lot of unaddressed surface. An agent still cannot determine how to page through results or what a "tariff change" record looks like, so the definition is under-specified for the tool's 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 only 17% (only origin documented), so the description must compensate and largely does not. "Workflow and classification filters" loosely maps to acknowledged and hts, but limit, before, and before_id — the cursoring pair — receive no explanation anywhere, leaving an agent guessing at pagination semantics.

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?

"List customer-scoped tariff changes" gives a specific verb plus resource and adds a scope qualifier that separates it from sibling reads like search_tariffs or lookup_tariff. It stops short of naming which sibling to use instead, but the resource itself is unambiguous.

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 states an access prerequisite (Pro API key) but never says when to call this versus search_tariffs or lookup_tariff, nor when to exclude oneself. The phrase "optional workflow and classification filters" hints at filtering but gives no selection criteria.

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, so the description carries the full burden. It does useful work by naming accepted auth modes (API key, OAuth, x402) and describing the shape of the answer (ruling evidence, duty layers, warnings, coverage, provenance). It says nothing about the read-only nature of the call, error/failure behavior, or how much evidence is 'bounded'.

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 sentences with no padding, but the leading 'Access: API key, OAuth, or x402 payment' clause sits ahead of the actual purpose, delaying front-loading of what the tool does. Beyond that ordering, every clause 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 an 8-parameter tool with a deeply nested facts object and no output schema, the description does well to say the response includes duty layers, warnings, coverage and provenance. But it leaves the agent without guidance on the facts declaration surface or on how its duty output relates to calculate_duty, so a substantial complexity gap remains.

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 88%, so the schema already documents hts, view, as_of, country, match, claims, detail and facts in depth. The description adds only the origin-supplied conditional, and it never touches the very complex facts declaration semantics, which the schema alone carries.

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 ('Look up a US HTS classification') plus what accompanies it (CBP CROSS ruling evidence, duty layers, warnings). It doesn't differentiate from close siblings like calculate_duty, compare_tariff_codes or search_tariffs, so an agent must infer the boundary from the duty-layer wording alone.

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 only conditional guidance is 'when origin is supplied', which explains a branch of behavior rather than when to pick this tool over alternatives. With near-identical siblings such as compare_tariff_codes and calculate_duty, some explicit routing ('use X to find a code, use this once you have one') would be needed for a 4 or 5.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses authentication modes and that archive coverage is reported explicitly, but it does not state whether the operation is read-only, how incomplete archive coverage affects results, or what the response shape contains.

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 only two short sentences and avoids repetition. However, it leads with access mechanics before the core purpose, which is slightly less front-loaded than ideal.

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 tool is complex, with six parameters, required historical inputs, nested facts structures, and no output schema. The description does not explain return values or how archive coverage, match mode, or claims affect invocation, leaving significant gaps for an agent despite the rich input schema.

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 high at 83%, so the schema already documents most parameters. The description adds no specific meaning for hts, country, as_of, match, claims, or facts, 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 states a specific action and resource: comparing a supported historical tariff stack with the current stack while reporting archive coverage. That is clear enough to distinguish it from lookup or calculation tools, though it does not explicitly name or differentiate against siblings like compare_tariff_codes or calculate_duty.

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 no explicit guidance on when to use this tool versus alternatives. The phrase 'historical tariff stack' implies a use case, but there are no conditions, exclusions, or named alternatives to route the agent between replay_tariff, compare_tariff_codes, and calculate_duty.

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 burden and does substantial work: API-key authentication, the five possible per-family outcomes (requirement_identified, not_applicable_to_this_rule, needs_information, outside_coverage, unavailable), the source-date limitation, and the explicit caveat that evidence is not verified. It does not describe error or rate-limit behavior, but the behavioral profile is otherwise well disclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The first sentence is a single sprawling enumeration of roughly two hundred regulatory families that dominates the description and buries the actual instruction. The later sentences are tight and well-ordered, but the description as a whole is badly front-loaded and far longer than the decision-relevant content requires.

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 very high-complexity screening tool, the description covers authentication, the screening semantics, output outcome categories, the state dimension, and explicit limits — enough to call it correctly. The unexplained rule_ids parameter and the absence of any return-shape guidance (no output schema exists) leave it short of 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?

destination_states is explained thoroughly (ISO 3166-2, US-CA only, empty state_requirements when omitted, federal results unchanged), and the facts contract is sharpened with the unknown-handling rule. However, rule_ids — one of only four parameters — is never mentioned, and as_of only gets 'for one entry date', leaving a material gap against the ~50% schema coverage.

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 opens with a specific verb and resource ('Screen declared product and entry facts against the published import-requirement families') and pins the scope to 'one entry date', plus maps it to the equivalent endpoint POST /v1/import-requirements/screen. It also distinguishes itself from the clearance-adjacent siblings via 'This is not import clearance, and evidence is not verified', though the enormous family enumeration makes the core purpose harder to extract than it should be.

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 real usage instruction for the facts object ('Omit a fact you do not know; never answer no for an unknown') and explains the destination_states opt-in and its effect. But it never says when to pick this over siblings like assess_import_entry or audit_entry; the only differentiation is a negative disclaimer, which implies rather than states the choice.

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 and does well: it discloses API-key requirements, return contents (cited HTS codes, modifying/revoking rulings, CBP link), coverage metadata, and important legal caveats. It does not cover rate limits or pagination behavior, but the behavioral disclosure is otherwise strong.

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 dense and front-loaded: access requirement first, then the core search operation, return details, coverage metadata, and legal caveat. Every sentence adds useful context without filler.

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?

It covers authentication, operation, return content, and legal caveats, which is valuable given no output schema. But with five parameters at 0% schema coverage, missing limit/offset/collection semantics leaves clear gaps for correct invocation.

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, but it only explains the hts and query criteria. It leaves limit, offset, and the collection enum (NY/HQ) undocumented, and its hts guidance (4 to 10 digits) is narrower than the schema pattern (4 to 13 characters allowing dots).

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: searching CBP CROSS rulings by HTS code/prefix and/or subject words. It is clear what the tool does, but it does not explicitly differentiate itself from the sibling get_ruling or search_tariffs 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?

The description explains the search criteria and the API-key prerequisite, which implies when to use it. However, it does not state when to use this tool instead of get_ruling or search_tariffs, so guidance is only 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?

With no annotations, the description carries the full behavioral burden. It usefully discloses authentication modes (API key, OAuth, x402 payment) and that results are "current" classifications, but says nothing about read-only nature, result ordering, or what a rate stack includes. That is helpful but incomplete for a no-annotation tool.

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 with the access constraint front-loaded and the core search behavior immediately after. The optional rate-stack clause is a useful qualifier rather than filler; little could be trimmed without losing meaning.

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 never indicates the shape of results (e.g., codes plus descriptions plus rates) or how many results are returned. Given the domain complexity and absence of structured documentation, it leaves meaningful gaps, though the core call path is clear.

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 only 33%: query and limit are undocumented in the schema. The description compensates by explaining that the query accepts product descriptions, codes, or prefixes — non-obvious from a bare string — and clarifies that country triggers origin-specific rate stacks. It still doesn't explain the limit parameter or pagination behavior.

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 ("Search current US HTS classifications") and clarifies the accepted query forms (product description, code, or prefix), which differentiates it from an exact-code tool like lookup_tariff. It never names a sibling tool explicitly, so the differentiation is implied 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?

Usage is implied through the query forms the tool accepts (description text, code, prefix) and the optional country parameter for rate stacks, but there is no explicit when-to-use or when-not-to-use guidance relative to lookup_tariff, compare_tariff_codes, or search_rulings. An agent must infer the routing decision.

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