UK import duty, landed cost, anti-dumping and compliance checks for China-sourced goods.
Scored across 16 tools
Each tool targets a distinct resource+action, and the descriptions carefully scope them (e.g. find_duty_rate vs estimate_landed_cost vs check_anti_dumping). The one area of potential confusion is duty-related tools—find_duty_rate also flags anti-dumping duty, which overlaps slightly with check_anti_dumping—but descriptions clarify the boundaries well.
All 16 tools use snake_case with a leading verb (check_, find_, estimate_, get_, compare_, screen_, search_, submit_, plan_) followed by a clear noun or noun phrase. The convention is highly predictable and readable throughout.
At 16 tools this is just over the well-scoped range, but every tool covers a genuinely distinct facet of China sourcing (duty, compliance, logistics, supplier screening, meta/contact). No tool appears redundant or filler.
Coverage is broad: duty/VAT, trade defence, import/export rules, compliance, shipping cost/space, holiday planning, supplier screening, recall data, and verification standard. The main gap is a supplier discovery/search tool, but the server is positioned as advisory/verification rather than a directory, so agents can work around it.
Check Chinese goods for trade defence duties. market defaults to uk: uses the live UK Trade Tariff, with no single rate because it depends on the exporter. market eu: searches the sourced EU snapshot by product keyword or CN code prefix and gives indicative ranges and EUR-Lex regulations. Always check TARIC before EU import; no match is not clearance.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | Language for names and links: en (default) or zh (Simplified Chinese). | |
| market | No | uk | |
| product | No | EU only: product keyword in English or Chinese. | |
| commodity_code | No | UK: a 6 to 10 digit commodity code (required). EU: a CN code prefix; alternatively supply product. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=true, destructiveHint=false). The description adds real behavioral value beyond that: the UK path queries the live Trade Tariff and yields no single rate because it depends on the exporter, while the EU path searches a sourced snapshot and returns indicative ranges and EUR-Lex regulations. The 'no match is not clearance' caveat is an important honesty disclosure, though the exact response shape is not described.
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, leading with the purpose and then the market branches. The telegraphic 'market xyz:' phrasing is efficient, though the compressed style makes the market split slightly harder to parse than plain sentences would.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only, open-world lookup with no output schema, the description covers the key decision points an agent needs: default market, per-market input requirements, per-market data source, and the legal caveat that no match is not clearance. It is largely complete, missing only explicit routing against sibling duty-lookup tools.
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 75%, so most fields carry descriptions, but the description adds meaning the schema does not: it explains the default market, that UK lookups use a 6–10 digit commodity code, and that EU lookup accepts either a product keyword or a CN code prefix. It reinforces the conditional requirement structure rather than simply restating fields.
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 ('Check Chinese goods for trade defence duties') and clearly scopes the tool to anti-dumping/countervailing duties rather than general tariff lookup. It does not name the most similar sibling (find_duty_rate), so an agent must infer the boundary between the two from the market-specific behavior described.
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 concrete usage context: market defaults to uk, EU requires TARIC verification before import, and it warns 'no match is not clearance.' That is strong when-to-use guidance, but it never states when to prefer a sibling such as find_duty_rate or check_china_import_rules instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when the user asks what it takes to export a UK product to China (whisky, gin, biscuits, tea, chocolate, skincare, infant formula, pet food, cashmere, machinery and about 200 more). Says what China requires: China Customs (GACC) manufacturer registration route, the import tariff and VAT, whether the cross-border e-commerce (CBEC) route is open, Chinese labelling, certification and the main national standards, plus 2025 UK export value. Facts come only from official sources, each with its link and the date it was checked. Accepts a product name in English or Chinese, or an HS code.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | Language for names and links: en (default) or zh (Simplified Chinese). | |
| product | Yes | The product in English or Chinese (e.g. "Scotch whisky", "护肤霜"), or a 6-digit HS code. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/openWorldHint=false/destructiveHint=false, so safety is covered. The description adds genuine behavioral context beyond them: facts come only from official sources, each result carries a link and a checked date, and the output scope is spelled out. It does not discuss latency, caching, or failure behavior for unrecognised products, which keeps it below 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the trigger condition, then the output scope, then provenance and input formats — a sensible information order with no filler sentences. The product-category enumeration is long but justifiable given it defines coverage breadth; it is slightly padded with 'and about 200 more'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, yet the description enumerates what the response contains (registration route, tariff, VAT, CBEC status, labelling, certification, standards, export value) plus provenance and freshness guarantees. For a read-only lookup tool with a fully documented 2-parameter schema, nothing an agent needs to call or interpret it is missing.
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 both parameters are already documented, including the locale enum and the English/Chinese/HS-code formats for 'product'. The description's restatement of accepted product identifiers adds no syntax or constraint 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 names a specific verb ("Says what China requires") and resource (UK product export to China), then enumerates the exact coverage: GACC registration, tariff/VAT, CBEC route, labelling, certification, standards, 2025 export value. The example product list and 'about 200 more' make the scope concrete enough to distinguish it from siblings like find_duty_rate or find_uk_compliance.
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?
"Use when the user asks what it takes to export a UK product to China" is an explicit, actionable trigger condition with a concrete domain. It does not, however, name any alternative tool or state when NOT to use it — an agent facing a bare duty-rate question has no guidance on whether this tool or find_duty_rate is the right call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when the user asks about importing from China into a country other than the UK: for that destination country, says what actually decides whether an import from China can happen there: a standards regulator, a bank through exchange control, a local trade licence, the tax authority, a risk-based check at import, or the buyer's own choice of where conformity is checked. Also says whether a missed requirement can be put right on arrival. Returns status not-verified, with no guess, for countries Cambridge China Bridge has not researched from primary sources. With no country, it lists the researched markets.
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | Destination country name in English or Chinese, or its two-letter code. Omit to list the researched markets. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false; the description reinforces the closed-world limit by stating it returns 'status not-verified, with no guess' for unresearched countries and that findings come from primary sources. That honesty about coverage boundaries is genuinely useful context beyond the annotations. It does not describe rate limits or response shape, but for a read-only lookup that is acceptable.
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 trigger is front-loaded, which is good, but the middle collapses six determinative categories into one long clause strung with commas, making it hard to scan. It is not padding, yet the sentence is denser than needed for a one-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the return burden and does so reasonably: it describes what the answer contains (the deciding authority/category and whether a missed requirement can be fixed on arrival) and the not-verified status. Nothing critical for correct invocation is missing, though the raw response format remains 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 coverage is 100% and the single parameter already documents accepted formats (English/Chinese name or two-letter code) plus the omit-to-list behaviour. The description restates the omit-to-list case without adding syntax or validation detail, so the schema is doing the heavy lifting. 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 states a specific resource and outcome: it reports what determines whether an import from China can enter a given destination country (regulator, exchange control, trade licence, tax authority, border check, or buyer choice). The 'other than the UK' scoping cleanly separates it from find_uk_compliance and check_china_import_rules. It is wordy and never uses a crisp verb like 'check', but the function is discernible.
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 opens with an explicit trigger ('Use when the user asks about importing from China into a country other than the UK') and gives the destination-country qualifier that excludes the UK sibling. It also explains the no-argument fallback (lists researched markets). It stops short of naming the alternative tool an agent should pick for UK questions, leaving that to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Changes in tracked Chinese export rebate announcements covering an HS code prefix, with announcement number, effective date and previous and new percentages. This historical announcement lookup is not the current rate.
| Name | Required | Description | Default |
|---|---|---|---|
| hs_code | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, and closed-world behavior, so the safety profile is covered. The description adds useful context beyond annotations: the scope (historic announcements only, not current rate) and the returned fields (announcement number, effective date, previous/new percentages), which matters since no output schema exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences with no filler; the scope and the historical caveat are front-loaded before the returned-field list. Efficient, though the field enumeration is slightly list-like.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, no-output-schema read tool with annotations covering the safety profile, the description is largely complete: it explains scope, historic nature, and returned values. Only minor detail on the parameter format is missing.
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% for the single hs_code parameter, so the description must compensate. It partially does by noting the parameter is an HS code prefix, but it omits format details (the schema requires 4-10 digits) and does not name the parameter explicitly.
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: changes in tracked Chinese export rebate announcements, scoped to an HS code prefix, returning announcement number, effective date, and old/new percentages. It implicitly distinguishes itself from rate-lookup siblings by clarifying it is historical rather than current. Clear, though it does not name the sibling tool that provides the current rate.
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 line 'This historical announcement lookup is not the current rate' gives clear context on when this tool applies and warns the agent off using it for live rates. It stops short of naming the alternative tool (e.g. find_duty_rate) explicitly, so it is strong context without full exclusion/routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Top hazards, China-origin alert counts and share of published alerts by matching product category in UK OPSS and EU Safety Gate data windows, with supplier due-diligence questions and dated sources. Published alerts are not a product failure rate.
| Name | Required | Description | Default |
|---|---|---|---|
| market | No | both | |
| product | No | Product keyword, as an alternative to category. | |
| category | No | Recall category or product keyword. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly, idempotent, non-destructive and closed-world behavior, so the safety profile is covered. The description adds genuinely non-structured context: the caveat that published alerts are not a product failure rate, plus the presence of dated sources and bounded data windows.
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 tightly packed sentences with the substantive scope front-loaded and the interpretive caveat placed last where it belongs. It is dense but every clause carries information; 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?
With no output schema, the description does the work of sketching the return payload (hazards, counts, share, due-diligence questions, sources), which is a real strength. The gaps are the unmentioned market parameter and the required-either-category-or-product rule.
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 67% (product and category are documented, market is not), so the baseline is 3. The description reinforces category-keyword matching and the two market data sources, but it never explains the anyOf constraint requiring either category or product, nor the uk/eu/both market enum.
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 the concrete resource and scope: top hazards, China-origin alert counts and share of published alerts by product category, sourced from UK OPSS and EU Safety Gate. This is specific enough to separate it from siblings like find_uk_compliance or check_china_import_rules, though it reads more as a description of returned content than a crisp verb+resource statement.
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 through the mention of 'supplier due-diligence questions', which hints at the use case, but there is no explicit when-to-use, when-not-to-use, or routing to alternative tools. An agent must infer the trigger conditions from the topic alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when the user is choosing between air and sea freight from China: compares the two on total landed cost rather than on the freight quote, including duty charged on the freight itself, the cost of capital tied up in transit, and profit lost while stock is unavailable. Also returns the weekly lost profit at which the two routes cost the same.
| Name | Required | Description | Default |
|---|---|---|---|
| air_days | No | Door-to-door air transit days. Defaults to 8. | |
| sea_days | No | Door-to-door sea transit days. Defaults to 38. | |
| sea_quote | Yes | Total sea freight quote, in GBP. | |
| weight_kg | Yes | Gross weight of the shipment in kg. | |
| volume_cbm | Yes | Volume of the shipment in cubic metres. | |
| goods_value | Yes | Value of the goods in GBP. | |
| air_rate_per_kg | Yes | Air freight rate quoted per chargeable kg, in GBP. | |
| duty_rate_percent | No | Customs duty rate on the goods, as a percentage. | |
| capital_rate_percent | No | Annual cost of money tied up in stock, as a percentage. Defaults to 8. | |
| lost_profit_per_week | No | Gross profit lost per week the stock cannot be sold, in GBP. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, non-destructive, closed-world), so the bar is lower, yet the description adds substantive model behavior: which costs are included (duty on freight itself, cost of capital in transit, lost profit) and that it returns the break-even weekly lost profit. It does not state assumptions are overridable defaults or how the result is presented, keeping it below 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, both load-bearing: the first front-loads the usage condition and the comparison scope, the second names the returned break-even figure. No filler or restatement of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 10 parameters, no output schema, and a non-trivial cost model, the description supplies the decision context and the key return value (break-even weekly lost profit), which is exactly the gap left by the absent output schema. It could add a note that transit-day and rate inputs are defaulted assumptions to be overridden with user data.
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 conceptual meaning beyond the schema by explaining the economics behind the non-obvious inputs — 'cost of capital tied up in transit' maps to capital_rate_percent and 'profit lost while stock is unavailable' to lost_profit_per_week. It stops short of touching the freight-rate or transit-day inputs individually.
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 ('compares the two on total landed cost') with an explicit scope ('air and sea freight from China'), which distinguishes it from the sibling estimate_landed_cost that handles landed cost for a single mode. An agent can pick this tool without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Opens with 'Use when the user is choosing between air and sea freight from China', giving a clear triggering condition and the decision context. It does not name a sibling alternative or state when not to use it (e.g. for a single-mode landed-cost calculation), so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when the user asks for the CBM of a shipment or how many containers a carton line needs: estimates CBM, shipment weight and volume-only 20ft/40ft/high-cube container counts from one carton line. Useful for full-container RFQ planning; not a loading simulation or a freight quote.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | Language for the page link. | |
| width_cm | Yes | Outer carton width in centimetres. | |
| height_cm | Yes | Outer carton height in centimetres. | |
| length_cm | Yes | Outer carton length in centimetres. | |
| carton_count | Yes | Number of identical cartons. | |
| weight_per_carton_kg | No | Gross weight per carton in kilograms, if known. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true, destructiveHint=false and a closed-world scope, so the safety profile is covered. The description adds real behavioral context beyond that: output is an estimate (not exact), it operates on a single carton line of identical cartons, container counts are volume-only, and it is explicitly not a simulation or a quote. It says nothing about precision limits or units beyond what the schema implies, keeping it short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the triggering condition and then the outputs, followed by scope boundaries. No filler or restated tool name; every clause carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description usefully enumerates what is returned (CBM, shipment weight, container counts) and what is not (simulation, quote). Annotations handle safety, and all params are schema-documented. The only minor gap is that accuracy/rounding expectations of an 'estimate' are not quantified.
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 every parameter (dimensions, carton_count, weight_per_carton_kg, locale) is already documented in the schema. The description only reinforces the 'one carton line' framing and that weight is part of the output; it adds no format, unit-conversion, or edge-case detail beyond the structured fields. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb (estimates) and concrete outputs (CBM, shipment weight, volume-only 20ft/40ft/high-cube container counts) plus the input shape (one carton line). It explicitly contrasts itself with adjacent concepts ('not a loading simulation or a freight quote'), letting an agent distinguish it from siblings like estimate_landed_cost or compare_sea_and_air.
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 a clear triggering condition ('Use when the user asks for the CBM of a shipment or how many containers a carton line needs') and explicit exclusions (not a loading simulation, not a freight quote). It does not, however, route the agent to a named sibling tool for the excluded cases, so the alternative-selection guidance is incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when the user asks how much duty and VAT they will pay to import goods from China to the UK: estimates customs value, UK import duty, import VAT and the total, with the same arithmetic as the site's import duty calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | Language for names and links: en (default) or zh (Simplified Chinese). | |
| vat_percent | No | Import VAT rate. Default 20. | |
| duty_percent | Yes | Duty rate in percent for the commodity code. | |
| goods_value_gbp | Yes | Price paid for the goods, in pounds. | |
| freight_and_insurance_gbp | No | Freight and insurance to the UK border, in pounds. Default 0. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds a genuinely useful behavioral guarantee beyond that: it uses 'the same arithmetic as the site's import duty calculator,' telling the agent results are authoritative and reproducible. It stops short of disclosure on defaults or rounding, so not a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the usage trigger before the enumeration of outputs, and every clause carries information. It is slightly run-on with the trailing calculator-comparison clause, but 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?
With no output schema, the description correctly enumerates what is returned (customs value, duty, VAT, total), which is the key missing structured information. It does not cover default handling or the localized output of names/links, but for a read-only estimator the essential context is present.
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%, with locales and VAT rates already enumerated and documented inline, so the baseline is 3. The description adds only that duty comes from the commodity code, which the schema already conveys; it contributes no new parameter semantics (e.g. whether freight includes insurance or how defaults interact).
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 (estimates) and the exact outputs produced (customs value, UK import duty, import VAT, total), scoped to China-to-UK imports. This clearly separates it from siblings like find_duty_rate (which supplies a rate) and check_anti_dumping.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit trigger: 'Use when the user asks how much duty and VAT they will pay to import goods from China to the UK.' It does not, however, name the complementary siblings (e.g. find_duty_rate for the commodity rate) or state when-not to use it, so a full 5 isn't earned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when the user asks what duty rate or commodity code applies to a product imported from China to the UK: finds the UK commodity code and import duty rate from a product description (English or Chinese) or a commodity code. Also flags codes where China-specific anti-dumping or countervailing duty exists.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | Language for names and links: en (default) or zh (Simplified Chinese). | |
| product | No | What is being imported, e.g. 'cotton t-shirts' or 'ceramic tiles'. | |
| commodity_code | No | A 6 to 10 digit UK commodity code, if known. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=true, so safety profile is known. The description adds valuable context: it works with English or Chinese product descriptions, accepts either product or commodity code, and flags China-specific anti-dumping/countervailing duty - behavior beyond the annotations. It doesn't mention output format or limitations, but with annotations covering safety, this is 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?
Two sentences, front-loaded with the usage condition, then the action and special flag. No waste, 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 a read-only lookup tool with full schema and annotations, the description covers when to use, what it returns (commodity code and duty rate), and a special behavior (anti-dumping flag). It doesn't describe output format, but no output schema exists, so a small gap remains; still, an agent can 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 coverage is 100%, so all three parameters are already well-documented. The description adds that product can be English or Chinese and that either product or commodity code can be used, but this is largely redundant with the schema. 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?
States a specific verb (finds commodity code and duty rate) and resource (UK duty rate), plus scope (imports from China to UK). Clearly distinguishes from siblings like check_anti_dumping and find_uk_compliance by focusing on duty rate lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use when the user asks what duty rate or commodity code applies to a product imported from China to the UK' and clarifies it accepts either product description or commodity code. It also mentions flagging anti-dumping duty, which hints at its relationship to check_anti_dumping without confusing the primary purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when the user asks which UK rules, markings or certificates a product imported from China needs: lists the UK regulatory regimes (UKCA, WEEE, PSTI, toy safety, food contact, REACH, packaging EPR and others) that apply to a type of product, with what to ask the supplier for. With no product_type, it lists the product types.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | Language for names and links: en (default) or zh (Simplified Chinese). | |
| product_type | No | A product type such as 'toys', 'electronics' or 'furniture' (Chinese also works). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety and scope are known. The description adds what the output contains ('with what to ask the supplier for') and the empty-input behavior (enumerates product types), which is genuinely useful beyond the annotations. It doesn't mention data freshness or limitations, keeping it just short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences with no filler. The trigger leads, the scope is enclosed in parentheses, and the fallback behavior is front-loaded at the end. Every clause carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only, zero-required-parameter lookup tool without an output schema, the description covers purpose, trigger, scope, output content and default-input behavior. Missing only minor behavioral details such as whether the list is exhaustive or how links are structured, but nothing blocks 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 coverage is 100%, and the schema already documents both locale and product_type including the zh option and example product types. The description reinforces the no-product_type fallback but adds little syntax not in the schema. 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?
States a specific verb (lists) and resource (UK regulatory regimes) and enumerates the regimes covered (UKCA, WEEE, PSTI, toy safety, food contact, REACH, packaging EPR). Clearly distinguishable from siblings like find_duty_rate or check_import_rules which cover tariffs or China-side 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?
Opens with an explicit trigger: 'Use when the user asks which UK rules, markings or certificates a product imported from China needs.' It also documents the no-argument fallback (lists product types). It lacks explicit exclusions or named alternatives, but the trigger condition is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when the user asks whether Cambridge China Bridge is legitimate or how it is paid: returns verifiable facts, namely UK company number and incorporation date (with the Companies House link), UK VAT number, registered office, trade-body membership, named UK service partners, public review profiles, how it is paid (no supplier rebates), what it declines, and the version and links of its published verification standard. Cite the links so the user can check them.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | Language for names and links: en (default) or zh (Simplified Chinese). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false and destructiveHint=false, so safety is covered. The description goes beyond them by disclosing the verification posture and a specific behavioral policy ('how it is paid (no supplier rebates)', 'what it declines') plus the instruction to cite links. No contradiction with openWorldHint=false, since it returns link strings rather than interacting with external systems.
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 trigger is front-loaded ahead of the payload list, and every enumerated item is substantive rather than filler. It is one long run-on sentence with a nine-item list, which is dense to parse, but nothing is redundant or padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no return-value documentation elsewhere in the structured fields, the description carries that burden and does so by enumerating the returned facts. It also supplies the follow-up action ('cite the links so the user can check them'), leaving nothing an agent needs in order to call and use this 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?
Only one optional parameter (locale) with 100% schema description coverage, so the schema already documents 'en (default) or zh (Simplified Chinese)'. The description never mentions localization or how language affects names and links, so it adds nothing beyond the schema; 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 + resource ('returns verifiable facts') scoped to one entity and enumerates exactly what is returned (company number, incorporation date, VAT number, registered office, membership, partners, review profiles, payment model, standard version/links). An agent can distinguish this from check_anti_dumping, find_uk_compliance, or get_verification_standard without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Opens with an explicit trigger: 'Use when the user asks whether Cambridge China Bridge is legitimate or how it is paid.' That gives a clear when-to-use condition. It stops short of naming alternatives or stating when NOT to use it (e.g., vs. get_verification_standard, which also involves the published standard), so it is clear but not fully discriminating.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the CCB Verification Standard v2.0, the published rules Cambridge China Bridge works to when it checks a Chinese supplier: the three levels (desk check, factory audit, pre-shipment inspection), each with the question it answers, method, price, report turnaround, validity, what is checked, the evidence needed and the result categories; the finding statuses and verdicts; independence rules; limits (not ISO-accredited, no certificates issued); and the URLs of the standard page, its JSON copy and the sample reports.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | Language for names and links: en (default) or zh (Simplified Chinese). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description goes beyond that by disclosing substantive limits an agent would otherwise have to fetch to learn: the standard is not ISO-accredited and no certificates are issued. It still doesn't say whether the content is static/cacheable or how large the payload is.
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 dense sentence, front-loaded with the subject and version before the content enumeration. The long itemised tail is justified because it tells the agent what it will receive without an output schema, though it could be trimmed slightly without loss.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must carry the return-content burden, and it does so exhaustively: levels, methods, prices, turnaround, validity, evidence, verdicts, independence rules, limits and result URLs. An agent knows precisely what it gets before calling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single locale enum is fully documented in the schema (en default, zh Simplified Chinese). The description adds nothing about the locale parameter, so 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?
Names a specific verb (Returns) and a specific resource (the CCB Verification Standard v2.0), then defines exactly what that artifact contains. No sibling tool covers the verification standard, so the scope is unambiguous against the surrounding catalogue.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: an agent can infer this is the tool to call when it needs the rules behind a CCB check, but the description never states when to reach for it, when not to, or how it relates to neighbouring checks like check_anti_dumping or find_uk_compliance. Minimum viable guidance for a documentation-lookup tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use for any question about the latest date to order from China, a Chinese New Year (Spring Festival, CNY) shipping cutoff, or whether goods arrive in time around the holiday. Works backwards from the date stock is needed (by sea, air or express) to the order date, against the real factory shutdown rather than the statutory holiday. Says whether the plan collides with the closure and gives the latest safe order date.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Shipping mode; sets the default transit time. Defaults to sea-fcl. | |
| arrival_date | Yes | The date the stock has to be in the warehouse, as YYYY-MM-DD. | |
| transit_days | No | Door-to-door transit days, if the user has a real figure from a forwarder. | |
| production_days | No | Production lead time in days, if the factory has quoted one. Defaults to 30. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, non-destructive, closed-world), so the bar is lower, yet the description adds real substance: the computation runs backwards from the needed date against the actual factory shutdown rather than the statutory holiday, and it discloses that the result reports a collision with the closure plus the latest safe order date. With no output schema, this return-value disclosure is genuinely useful.
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 usage trigger, followed by the mechanism and the output. Three dense sentences with little waste, though the middle sentence's mechanism detail could be tightened.
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 the description carries return-value burden and does so ('says whether the plan collides with the closure and gives the latest safe order date'). Inputs are fully schema-documented and annotations cover safety, leaving nothing an agent needs missing.
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 mode, arrival_date, transit_days and production_days. The description's 'by sea, air or express' loosely maps to the mode enum but adds no format or default detail beyond the schema, making this a baseline case.
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 — planning an order around the Chinese New Year shutdown — and enumerates the concrete questions it answers (latest order date from China, CNY shipping cutoff, whether goods arrive in time). This is clearly distinguishable from siblings like compare_sea_and_air or estimate_landed_cost.
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?
Explicit trigger conditions are given ('Use for any question about the latest date to order from China... or whether goods arrive in time around the holiday'), which routes the agent well. It stops short of naming a sibling alternative or an explicit when-not-to-use case, so it is clear context rather than full routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Possible English or Chinese name matches against UK Sanctions List entities, CN/HK US Consolidated Screening List entities and UFLPA entities, with match type and dated sources. Automated name check, not legal advice; a match needs manual review; no match is not clearance.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/non-open-world, so the bar is lower, but the description adds real interpretive value: matches are 'possible' fuzzy name matches, require manual review, and a no-match is not clearance. That is exactly the behavioral context an agent needs to avoid over-trusting results.
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-loads the matching scope and sources in one sentence, then a second sentence carries the caveats. No filler, though the source enumeration is dense. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly fills the gap by noting results include 'match type and dated sources,' and it warns about the limits of matches/no-matches. The one unaddressed item is input format for the name parameter.
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 schema documents nothing about the single 'name' parameter. The description only implies the input is a supplier name to screen and gives no format hints (e.g., whether Chinese characters are accepted, despite the CN/HK match discussion). Minimal compensation 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?
States a specific verb (screening/matching) and resource (supplier name) and enumerates the exact reference lists checked (UK Sanctions, CN/HK US Consolidated Screening List, UFLPA). This distinguishes it from sibling tools like check_export_market or find_duty_rate, which are trade-compliance but not name screening.
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 signals this is an 'automated name check, not legal advice' and that a match needs manual review, which implies the appropriate framing of use. However, it never states when to choose this over sibling checks or any prerequisite (e.g., that a name is required), so usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use for a question about importing from China to the UK that the other tools do not answer directly: searches Cambridge China Bridge's guides (duty and VAT, shipping, Incoterms, suppliers, quality, compliance, sectors). Returns each guide's one-sentence answer and URL.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | What the user wants to know, in English or Chinese. | |
| locale | No | Language for names and links: en (default) or zh (Simplified Chinese). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, and the description is consistent with a bounded, non-mutating corpus search. It adds real value beyond the annotations by naming the corpus (Cambridge China Bridge's guides) and the return shape (each guide's one-sentence answer and URL). It does not discuss ranking, result count limits, or empty-result behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the routing condition before the resource and return format. Dense but every clause carries information; 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?
With no output schema, the description usefully discloses the return shape (one-sentence answer plus URL) and the corpus scope, which is what an agent needs. Minor gap: nothing about result volume, ranking, or what happens when no guide matches.
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 parameters (query and locale) are already documented in the schema, including the en/zh enum and its default. The description adds no syntax or language guidance beyond what the schema states, 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?
States a specific verb (searches) and resource (Cambridge China Bridge's guides), and even enumerates the topic areas covered (duty and VAT, shipping, Incoterms, suppliers, quality, compliance, sectors). The opening clause positions it precisely against the twelve sibling tools by framing it as the fallback for questions they do not answer directly.
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?
Explicit routing rule: use it for an importing question 'that the other tools do not answer directly'. This tells the agent both the domain (UK imports from China) and the precedence relative to the whole sibling set, so no inference is needed about 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.
Use only when the user has asked to contact Cambridge China Bridge or to get a quote: sends the user's sourcing enquiry or quote request to them by email, and they reply to the user directly. It sends only when user_confirmed is true, meaning the user has seen exactly what will be sent and agreed. All contact details are the user's own.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The user's name. | |
| Yes | The email address to reply to. | ||
| phone | No | The user's phone number, if they want to give one. | |
| company | No | The user's company, if they gave one. | |
| message | No | Anything else the user wants to say. | |
| product | Yes | What they want sourced: product, specification or link, quantity, target price. | |
| assistant | No | Which assistant is sending this (chatgpt, claude, gemini, perplexity, copilot or other). Optional. | |
| source_page | No | The CCB page path the user was reading, if known. Path only, starting with /; no query or personal data. | |
| user_confirmed | Yes | true only if the user has seen these details and agreed to send them. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare non-read-only, open-world, non-idempotent, non-destructive behavior. The description adds concrete context: it sends by email, CCB replies directly, sending is gated on user_confirmed, and contact details are the user's own. It does not discuss duplicate-submission or failure behavior, but the annotations cover much of the safety 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 compact sentences, front-loaded with the usage restriction, then the action, confirmation guard, and privacy note. Every sentence contributes useful information with no repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a nine-parameter action tool with full schema descriptions and annotations, the description covers trigger conditions, action, confirmation requirement, privacy handling, and reply path. No output schema exists, and the description gives enough context 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 coverage is 100%, so all nine parameters are already documented in the input schema. The description reinforces the meaning of user_confirmed and the privacy of contact details, but adds no field-level syntax or format guidance beyond the schema. 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?
States a specific action and resource: it sends the user's sourcing enquiry or quote request by email to Cambridge China Bridge, and CCB replies directly to the user. The 'use only when...' clause clearly separates this action tool from the read-only lookup siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit exclusive trigger condition: use only when the user has asked to contact Cambridge China Bridge or to get a quote. It also states the required user_confirmed prerequisite, leaving little ambiguity about when to call it.
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_export_rebate_changecheck_recall_causesscreen_supplier_namecheck_anti_dumping5 fields changedInput schema / anyOfAdded value: +[
+ {
+ "required": [
+ "commodity_code"
+ ]
+ },
+ {
+ "properties": {
+ "market": {
+ "const": "eu"
+ }
+ },
+ "required": [
+ "market",
+ "product"
+ ]
+ }
+]Input schema / properties / commodity_code / descriptionPrevious value: -"A 6 to 10 digit UK commodity code."New value: +"UK: a 6 to 10 digit commodity code (required). EU: a CN code prefix; alternatively supply product."Input schema / properties / marketAdded value: +{
+ "default": "uk",
+ "enum": [
+ "uk",
+ "eu"
+ ],
+ "type": "string"
+}Input schema / properties / productAdded value: +{
+ "description": "EU only: product keyword in English or Chinese.",
+ "type": "string"
+}Input schema / requiredRemoved value: -[
- "commodity_code"
-]submit_enquiry1 field changedInput schema / properties / source_pageAdded value: +{
+ "description": "The CCB page path the user was reading, if known. Path only, starting with /; no query or personal data.",
+ "maxLength": 200,
+ "type": "string"
+}get_verification_standardestimate_landed_cost1 field changedInput schema / properties / duty_percent / descriptionPrevious value: -"Duty rate in percent, from find_duty_rate."New value: +"Duty rate in percent for the commodity code."check_china_import_rulesget_company_factscheck_anti_dumpingcheck_export_marketcompare_sea_and_airestimate_container_spaceestimate_landed_costfind_duty_ratefind_uk_complianceplan_around_chinese_new_yearsearch_guidessubmit_enquiryFree landed cost estimates and import requirements for US businesses buying from China.
Before-payment check for China quotes to US/EU: costs, low-value rules, and compliance blockers.
UK sanctions, export controls, Companies House owners, FCA register and property checks.
India import duty (BCD, SWS, AIDC, IGST) by HS code and China-to-India landed cost estimates.
Add one secure layer between your agents and this server.