Dated US import facts: CBP rulings, Section 301 ladder, landed cost, rule changes, recalls.
Scored across 8 tools
Most tools target clearly distinct resources: claims, CBP rulings, HTS candidates, duty stacks, rule changes, landed cost, recalls, and Section 301 headings. Some overlap exists between duty_stack_rules, section_301_ladder, and check_import_claim on Section 301 and current-rate queries, but the descriptions give enough scope detail to guide selection.
Seven of eight tools follow a descriptive noun-noun or adjective-noun snake_case pattern, such as classification_rulings, duty_passport, and section_301_ladder. check_import_claim breaks the pattern by leading with a verb, making the set mostly consistent with one notable deviation.
Eight tools is a reasonable, well-scoped count for a specialized US import-duty reference server. The set earns the count, though recall_check sits somewhat outside the duty-facts domain and slightly dilutes the focus.
The set covers current duty rules, rule changes, classification via CBP rulings and HTS candidates, Section 301 rate structure, and landed-cost arithmetic. A notable workaround is required for directly verifying whether a specific HTS8 code appears on a Section 301 list, which section_301_ladder explicitly does not do.
Fact-check a circulating claim about US import duties against the dated official record. Returns a verdict, why, and the sources. Covers the four figures still repeated everywhere in 2026: the $800 de minimis exemption, the $80–$200 postal flat duty, the ~54%/$100 courier rule, and 'reciprocal' baseline tariffs. Use this when a user quotes a number for US imports.
| Name | Required | Description | Default |
|---|---|---|---|
| claim | Yes | The claim in the user's words, e.g. 'under $800 is duty free' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It conveys that this is a read-only style analysis tool that returns a verdict, reasoning, and sources, and that it compares against a 'dated official record.' It does not enumerate edge cases or out-of-scope claims, but for a simple look-up-verification tool the key behavior is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured. The action and return value are front-loaded, the four covered figures are packed into one useful scope sentence, and the usage instruction is a short final sentence. No sentence 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 one-parameter tool with no output schema, the description provides enough to invoke it correctly: what the user claim should be, what the tool checks, what it returns, and when to use it. It doesn't describe failure behavior for claims outside the four covered figures, but nothing essential is missing for normal calls.
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 only parameter, `claim`, is already fully described in the input schema with an example ('under $800 is duty free'). Since schema description coverage is 100%, the description does not need to add much. It reinforces that the input should be a user-quoted number, but adds no new meaning beyond 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 opens with a specific verb ('Fact-check') and a specific resource ('a circulating claim about US import duties against the dated official record'). It clearly distinguishes itself from the sibling tools by focusing on verifying a user-quoted number, not on rulings, calculation frameworks, or rule lookups. It also states the return shape up front: a verdict, why, and the sources.
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 explicitly says 'Use this when a user quotes a number for US imports,' which gives a clear trigger for tool selection. It doesn't spell out when-not-to-use or name sibling alternatives, but the stated scope of covering the four recurring figures provides a reasonable decision boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search CBP's own binding classification rulings (CROSS) for a product in plain words and get what CBP actually decided: ruling number, date, subject, the HTS codes it assigned — including any chapter 99 heading, which is what carries a Section 301 addition — and whether the ruling has been revoked or modified. This is precedent from the agency that decides, not a guess: it is how you check whether the code your supplier gave you matches what CBP has ruled on comparable goods. Queried live at call time from rulings.cbp.gov; nothing is mirrored here.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many rulings to return, 1–10 (default 5) | |
| query | Yes | The product in ordinary words, e.g. 'LED face mask', 'plush toy', 'power bank' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it delivers: it says the tool is 'queried live at call time from rulings.cbp.gov' and 'nothing is mirrored here,' clarifying freshness and provenance. It also discloses that rulings may be revoked or modified and that chapter 99 headings carry Section 301 additions, which materially affects interpretation.
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 compact, front-loaded with the primary action, and every sentence adds value: what it searches, what it returns, why it matters, and how the data is sourced. There is 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?
There is no output schema, so the description must explain return values, and it does: ruling number, date, subject, assigned HTS codes including chapter 99, and revocation/modification status. Combined with the live-source note and usage context, an agent has enough information to invoke the tool and interpret the result.
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?
Both parameters already have detailed schema descriptions: query is described as an ordinary-word product and limit has range and default. The description reinforces 'plain words' and mentions comparable goods, but it adds little beyond the schema, 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 a specific verb and resource: 'Search CBP's own binding classification rulings (CROSS)' for a product in plain words. It also enumerates what the call returns, making it clearly distinct from sibling tools that handle import claims, duty stacking, or rule changes.
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 gives an explicit use case: checking whether a supplier-provided HTS code matches what CBP has ruled on comparable goods. It does not explicitly name sibling tools or state when not to use it, but the 'not a guess' framing and reference to Section 301 additions make the intended context strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Candidate HTS headings for a consumer product category, pulled daily from the official USITC HTS REST API: the candidate line, its general rate, every rated line in the heading, and the Section 301 status to verify on USTR. These are candidates chosen by category reading, not a classification ruling — the importer of record classifies.
| Name | Required | Description | Default |
|---|---|---|---|
| pick | No | Product slug, e.g. 'pet-fountain'; omit with query to list all slugs | |
| query | No | Keyword matched against slug and HTS description |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden and does well: it discloses the source (USITC HTS REST API), refresh cadence (daily), the specific data returned, and the caveat that the output is only candidates requiring verification on USTR. It does not cover failure modes or rate limits, but for a lookup tool this is solid.
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 dense sentences with the core purpose front-loaded, followed by the data contents and the critical non-ruling caveat. No filler or repeated schema 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 and no annotations, the description explains enough: source, daily refresh, returned fields, and interpretation caveat. It is slightly light on output structure and how the two optional parameters interact, but the schema covers parameter semantics and the tool is simple.
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 description adds no parameter-level detail beyond the schema. It mentions 'product category' but does not explain how pick/query select or combine; baseline 3 is appropriate because the schema already documents both 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?
The description clearly identifies the tool as providing candidate HTS headings for a consumer product category, with a specific data source and contents (candidate line, general rate, rated lines, Section 301 status). It explicitly distinguishes itself from a classification ruling, which separates it from the classification_rulings 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?
It gives clear context for use: look up candidate HTS headings pulled daily from USITC, and explicitly says these are not a classification ruling and the importer of record classifies. It does not name sibling tools as alternatives (e.g., classification_rulings for final rulings), so it stops short of full when/when-not routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The current China→US import duty stack, rule by rule, each with the record that establishes it and the date it was decided or published: HTS base rate, Section 301, Section 232, the struck-down IEEPA tariffs (2026-02-20), the indefinite de minimis suspension (2026-06-24), the expired postal flat rate (2026-02-28), and the MPF/HMF fee rates. Use this before quoting any US import rule from memory — the 2025 guidance that dominates training data is superseded.
| Name | Required | Description | Default |
|---|---|---|---|
| part | No | Which part to return; default all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that results are current, that each rule includes its source record and date, and that it includes struck-down, expired, and superseded items. This is substantial behavioral context, though it does not describe the exact return shape or formatting.
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 dense but purposeful sentences. The first front-loads the tool's content and provenance format; the second delivers an actionable usage warning. No filler or redundant 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 simple optional-parameter lookup with no output schema, the description gives enough context to invoke correctly and interpret results. It could be slightly more complete by explicitly mapping the part enum to the listed components, but the schema already covers that.
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 schema covers the single optional `part` parameter with clear enum values and a description, so baseline is 3. The tool description does not discuss `part` directly, but the enumerated content helps contextualize the 'superseded' and 'fees' parts without adding new parameter-level 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?
The description clearly defines the resource: a China→US import duty stack returned rule by rule, with establishing record and date. It enumerates the exact rules and fees included, making its scope unmistakable and distinguishing it from more focused sibling tools like section_301_ladder or import_rule_changes.
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 gives explicit guidance: 'Use this before quoting any US import rule from memory,' with a strong rationale that 2025 training guidance is superseded. It does not name alternative tools or state when not to use it, but the context is clear enough for an agent to know when this lookup is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What changed in the general US import rules, newest first, from the official Federal Register API: presidential tariff actions, CBP and DHS rules, USTR notices — each with its publication date, document number and federalregister.gov link. Use since to get only what is new to you, the same way you would poll a changelog. Case-specific antidumping, ITC and Foreign-Trade Zone paperwork is out of scope by design and the response says so.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum documents to return (default 25) | |
| since | No | Only documents published on or after this date (YYYY-MM-DD) | |
| matched_in | No | title_or_abstract = the import phrase is in the headline matter (usually the ones that matter); default any |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure. It states ordering (newest first), source (Federal Register API), and that the response explicitly notes the out-of-scope items. However, it does not explicitly state that the tool is read-only or describe any potential side effects, authentication, or rate limits, though for a retrieval API these are arguably implicit.
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 three sentences with no redundancy. The first sentence establishes purpose and output, the second gives a usage hint, and the third sets scope boundaries. It is front-loaded and each sentence earns its place, though it could be trimmed slightly without losing clarity.
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 covers purpose, scope, output format, and a usage pattern. It lacks explicit mention of pagination or error behavior, but the 'limit' parameter is documented in the schema, and the tool is a simple read-only API call. The exclusion of case-specific items is clearly stated, making the tool sufficiently complete for an agent.
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 meaningful context for the 'since' parameter by framing it as a changelog poll, which goes beyond the schema's dry 'Only documents published on or after this date'. No extra insight is provided for 'limit' or 'matched_in', so the description adds only marginal value overall.
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 clearly identifies the tool as a query for changes in general US import rules from the official Federal Register API, listing specific document types (presidential tariff actions, CBP/DHS rules, USTR notices) and output fields (publication date, document number, link). It explicitly excludes case-specific items, distinguishing it from siblings like classification_rulings or section_301_ladder.
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 gives a clear when-to-use pattern ('Use since to get only what is new to you, the same way you would poll a changelog') and an explicit when-not-to-use ('Case-specific antidumping, ITC and Foreign-Trade Zone paperwork is out of scope by design'). It stops short of naming specific sibling tools as alternatives, but the exclusion is precise enough for an agent to route correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Itemise a US landed cost from rates you supply: duties (HTS base + Section 301 + Section 232 on the customs value), MPF 0.3464% with the CBP floor disclosed, HMF 0.125% on ocean entries, plus freight and insurance. Deterministic arithmetic with the assumptions and sources attached. This tool never invents a product's duty rate: omit hts_base_rate_pct and it refuses and points you at the official schedule.
| Name | Required | Description | Default |
|---|---|---|---|
| ocean_entry | No | True for ocean entries, which add the Harbor Maintenance Fee; default false | |
| goods_value_usd | Yes | Customs value of the goods in USD | |
| section_232_pct | No | Section 232 addition in percent; default 0 | |
| section_301_pct | No | USTR Section 301 addition in percent (0 / 7.5 / 25 / 50 / 100); default 0 | |
| hts_base_rate_pct | Yes | The heading's general rate of duty, in percent. Look it up at hts.usitc.gov or with duty_passport; this server will not guess it. | |
| freight_insurance_usd | No | Freight plus insurance in USD; default 0 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses that the tool refuses to guess duty rates, that MPF includes a CBP floor, that HMF applies only to ocean entries, and that arithmetic is deterministic with assumptions attached. It does not explicitly state that the operation is read-only or non-destructive, but the description's emphasis on deterministic arithmetic and refusal behavior gives a clear behavioral profile.
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, each earning its place: the first enumerates the calculation components, the second states the deterministic nature and attached assumptions, the third gives the critical refusal behavior. The most important operational constraint (never invents a duty rate) is front-loaded at the end of the description, and the whole text is compact with 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 a calculation tool with six parameters, no output schema, and no annotations, the description covers the key behavioral constraints: what fees are included, when HMF applies, and what happens if a required rate is missing. It does not describe the output format or whether the result includes a breakdown, but the description's enumeration of components implies the breakdown. The main gap is not stating the return shape, but the tool's complexity is moderate and the description is largely sufficient.
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 six parameters. The description adds context for hts_base_rate_pct (the server will not guess it) and clarifies the role of ocean_entry (adds HMF), but it does not add meaning for goods_value_usd, section_232_pct, section_301_pct, or freight_insurance_usd beyond what the schema provides. Baseline 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 a specific verb ('Itemise') and a precise resource ('US landed cost'), then enumerates the exact components (duties, MPF, HMF, freight, insurance). It distinguishes itself from siblings by stating it computes from rates the user supplies, which separates it from duty_passport (rate lookup) and duty_stack_rules (rules).
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 explicitly states when to use this tool: when you have rates to supply and need a landed cost calculation. It also gives a clear exclusion: 'This tool never invents a product's duty rate' and directs the agent to the official schedule or duty_passport when the rate is unknown. This routes the agent to the correct sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Official US product recalls (CPSC saferproducts.gov API) touching a product category in the last 365 days: date, title, hazard and the cpsc.gov URL. A keyword hit means the words appear in a recall title, not that a particular supplier or SKU is affected. Use before recommending or sourcing a category.
| Name | Required | Description | Default |
|---|---|---|---|
| pick | No | Product slug, e.g. 'cable-powerbank' | |
| query | No | Keyword matched against the tracked categories and recall titles | |
| only_hits | No | Only categories with at least one recall; default true when no pick/query given |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool's scope (last 365 days), the source (CPSC API), and the caveat about keyword matching (title only, not supplier-specific). This is useful behavioral context, though it could go further by mentioning rate limits or error handling, but the description covers the key pitfalls.
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 a single, information-dense paragraph with no filler. It front-loads the core function (recall retrieval), then gives the data source, the output fields, and the important caveat about keyword matching, followed by a clear usage directive. Every sentence adds value, and it is 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?
Given the tool's moderate complexity (3 optional parameters, specific API source) and the lack of an output schema, the description covers the essential aspects: what it does, the time window, the output fields, and the interpretation caveat. It could be more complete with an example of how to use pick vs. query, but the current description is sufficient for an agent to call it correctly in most cases.
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 (pick, query, only_hits). The description adds minimal extra meaning beyond the schema, but it does imply that the tool filters by product category and keyword, which aligns with the parameters. No additional syntax or nuance is provided, so a baseline 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 clearly states the tool's purpose: retrieving official US product recalls from the CPSC saferproducts.gov API for a product category within the last 365 days, including date, title, hazard, and URL. It specifies the data source, the time window, and the output fields, distinguishing it from other tools in the set.
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 explicitly says 'Use before recommending or sourcing a category,' providing a clear context for when to use this tool. It also warns that a keyword hit means only the title contains the word, not that a specific supplier or SKU is affected, which helps agents avoid misinterpretation and guides them away from using it for supplier-level checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The Section 301 (China) additional-duty ladder, read straight from the official USITC HTS export of chapter 99 subchapter III: which 9903.88 / 9903.91 heading carries which addition (7.5%, 10%, 15%, 25%, 50%, 100%), which U.S. note defines its list, and — where the schedule states it — the date that heading took effect. It tells you the possible rates and where coverage is defined; it never asserts that a particular HTS8 code is on a list, because that lives in U.S. note 20/31 and the USTR annexes.
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | 20 = the original Section 301 lists; 31 = the increases effective 2024-09-27 | |
| heading | No | A chapter 99 heading prefix, e.g. '9903.88.03' or '9903.91' | |
| rate_pct | No | Only headings carrying this additional rate, e.g. 25 |
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 it does so responsibly: it discloses the data source, the exact scope of what is returned, the caveat that dates are only included where the schedule states them, and the tool's central limitation regarding HTS8 membership. This is meaningful behavioral context beyond the schema.
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 a single dense paragraph, but every clause earns its place — scope, source, parameters, rate values, and limitations are all packed in without filler. It could be split into shorter sentences for readability, but it is not bloated.
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 three-parameter reference tool with no output schema, the description adequately explains what it returns (rates, defining notes, effective dates) and what it deliberately does not return (HTS8-level assertions). Combined with 100% parameter schema coverage, an agent has enough context to select and invoke the tool correctly, though it doesn't mention how multiple optional filters might interact.
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 note, heading, and rate_pct. The description adds some interpretive context, such as the possible rate values and the meaning of note 20 vs 31, but it mostly restates the purpose rather than adding substantial parameter-level detail. 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 exactly what the tool provides: the Section 301 China additional-duty ladder from the USITC HTS export, mapping 9903.88/9903.91 headings to rate additions, defining U.S. notes, and effective dates where stated. It also explicitly differentiates itself from tools that assert HTS8-level list membership, so an agent can tell its scope apart from sibling 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 clearly frames when to use this tool: when you need possible Section 301 rates and where coverage is defined. It also provides a clear exclusion — it never asserts that a particular HTS8 code is on a list — so an agent knows not to use it for code-level list membership. It stops short of naming sibling alternatives explicitly, but the usage boundary is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_import_claimclassification_rulingsduty_passportduty_stack_rulesimport_rule_changeslanded_costrecall_checksection_301_ladderSource-linked US tariff and trade-action changes: legal status, effective dates, dated archive.
US tariff & trade truth: duty actually paid by origin/HS 2017+, HTS rulebook, CBP rulings. No key.
US tariff & trade truth: duty actually paid by origin/HS 2017+, HTS rulebook, CBP rulings. No key.
Is a foreign supplier on an FDA import alert red list, detained at the US border? 14,000+ listings.
Add one secure layer between your agents and this server.