Cambridge China Bridge — China sourcing

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

Annotations already mark this as read-only and non-destructive; the description adds important behavioral context: the tool queries the live UK Trade Tariff and intentionally omits the rate because it depends on the exporter. This tells the agent what to expect and prevents false assumptions about output.

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 two purposeful sentences with no filler. The first sentence front-loads the tool's scope and data source; the second delivers the key limitation. Every word 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 low-complexity existence check, the description, schema, and annotations cover the required inputs, the live read-only nature, and the key limitation about rates. With no output schema, a more explicit pointer to an alternative rate-lookup tool would make it fully complete, but nothing essential for correct invocation 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 100%, so the schema already documents both parameters fully. The description adds little beyond the schema for parameter semantics; it mentions commodity codes but does not provide additional meaning over the structured field descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: it checks whether a UK anti-dumping or countervailing measure applies to Chinese goods on a commodity code, using the live UK Trade Tariff. This clearly differentiates it from siblings like find_duty_rate by focusing on measure existence rather than a 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 description provides clear context for when to use this tool: when determining whether a UK anti-dumping/countervailing measure applies to goods from China on a commodity code. It does not explicitly name an alternative for rate lookup, but the emphatic 'Deliberately gives no rate' guides the agent away from using it for rate calculations.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral detail: it returns status 'not-verified' with no guessing for countries not researched, and it explicitly states whether a missed requirement can be rectified on arrival. This goes beyond the annotations and helps the agent set expectations.

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 bit long but each sentence earns its place: the first explains the core functionality with a list of factors, the second adds the not-verified behavior, and the third gives the no-argument usage. It is front-loaded with purpose and structured logically, though it could be tightened slightly without losing 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 there is no output schema, the description adequately covers what the tool returns: the deciding factors, the rectification possibility, and the not-verified status for un-researched countries. It also handles the optional parameter usage. No critical information seems missing for an agent to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already provides a full description for the only parameter (country), including the omission behavior. The description reinforces this with 'Call with no country to list the researched markets', but adds no new semantic detail beyond the schema. With 100% schema coverage, 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 clearly states the tool's purpose: to report what decides whether an import from China can happen in a destination country, listing specific factors (standards regulator, bank, trade licence, etc.). This is a specific verb+resource that distinguishes it from siblings like check_anti_dumping and find_duty_rate, which focus on duties and tariffs rather than the full import-governance picture.

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 clear usage context: call with a destination country to get the import-governance factors, and call with no country to list researched markets. It also warns that un-researched countries return a not-verified status. While it doesn't explicitly contrast with sibling tools, the purpose statement makes it clear this is for regulatory/financial import barriers, not for duties or shipping.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds useful context by listing the specific cost components included (duty on freight, capital cost in transit, lost profit) and disclosing the extra output: the weekly lost profit at which the routes cost the same. This goes beyond what annotations provide.

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

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

Two sentences with no filler. The main purpose is front-loaded, the key distinction from a freight-quote comparison is stated, and the additional breakeven output is clearly presented in the second sentence.

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 tool with 10 parameters but no output schema, the description explains the core computation and the notable additional return value. It does not detail the full output format, but it gives enough context for an agent to understand what the tool produces and what inputs are conceptually involved.

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 baseline is 3. The description does add conceptual meaning by connecting duty, capital cost, and lost profit to the calculation, but it does not materially improve parameter-level understanding beyond the schema descriptions.

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 uses a specific verb and resource pair: 'Compare air and sea freight on total landed cost.' It clearly distinguishes this from a single-mode estimator like estimate_landed_cost by emphasizing the comparative nature and the 'rather than on the freight quote' framing.

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 conveys the intended use case—comparing two freight modes on total landed cost—and implicitly rules out using it for a single-mode estimate. However, it does not explicitly name alternatives such as estimate_landed_cost or state when not to use this tool, leaving some selection inference to the agent.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations: it clarifies that results are 'volume-only' estimates based on a single carton line, not stowage-accurate loading plans. This prevents the agent from over-promising accuracy to the user. The modest extra context earns a 4 given the low bar set by the annotations.

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

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

Two sentences with zero wasted words. The first sentence front-loads the verb, resource, and outputs; the second pinpoints usage and exclusions. Every clause earns its place and the description is easy to scan in tool listings.

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 calculator with six well-documented parameters and a complete safety annotation set, the description is sufficient. It lists the outputs an agent can expect (CBM, weight, container counts) even without an output schema. Minor gaps like assumed container dimensions or output rounding are not critical for correctly invoking the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with every parameter already documented with units and meaning (e.g., 'Outer carton length in centimetres'). The description adds no parameter-specific syntax or format details beyond the schema, only reinforcing that inputs represent a single identical-carton line. This is the baseline 3 where the schema carries the weight.

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 uses a specific verb ('Estimate') and names the exact outputs (CBM, shipment weight, volume-only 20ft/40ft/high-cube container counts) plus the input scope ('from one carton line'). It also distinguishes itself from related false-friend tools by explicitly stating it is 'not a loading simulation or a freight quote'. This gives an agent a clear, unambiguous understanding of the tool's role.

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 usage context ('Useful for full-container RFQ planning') and states what the tool is not ('not a loading simulation or a freight quote'). While it doesn't name specific sibling alternatives, the positive use case plus exclusions gives an agent enough guidance to select it over broader estimation or quoting tools.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the behavioral context that it mirrors the site's import duty calculator arithmetic, which is useful. It does not disclose details like rounding, currency conversion assumptions, or whether the estimate is binding, but with annotations covering the read-only nature, a 3 is appropriate.

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 core purpose and the key constraint (from China, same arithmetic as the site calculator). No wasted words; every part 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 estimation tool with 100% schema coverage and no output schema, the description is nearly complete. It could mention that the result is an estimate and not a binding quote, but the annotations and schema already cover the safety profile and parameters. The cross-reference to find_duty_rate helps the agent chain tools correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all five parameters. The description adds the context that duty_percent comes from find_duty_rate, which is a useful cross-reference, but it does not add meaning beyond the schema for the other parameters. Baseline 3 is correct.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Estimate') and resource ('customs value, UK import duty, import VAT and the total'), and distinguishes it from siblings by specifying the origin ('from China') and the arithmetic parity with the site's import duty calculator. It clearly differentiates from find_duty_rate and other 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 implies when to use this tool: when estimating landed cost for imports from China, and the schema references find_duty_rate as the source for duty_percent, which gives a clear context. However, it does not explicitly state when not to use it or name alternatives, so it falls short of a 5.

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

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

Annotations already provide readOnlyHint=true and openWorldHint=true, and the description adds useful behavioral context: it accepts English or Chinese input, returns the commodity code and import duty rate, and flags codes with China-specific anti-dumping/countervailing duty. This goes beyond the annotations without contradicting them.

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 two focused sentences with no filler. The first sentence states the primary action and inputs, and the second adds the important China-specific flag behavior. Key information is front-loaded and 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?

Since there is no output schema, the description adequately conveys what the agent will receive: a commodity code, import duty rate, and a flag for China-specific anti-dumping/countervailing duty. It is complete for most use cases, though it does not mention behavior when both product and commodity_code are supplied or when no match is found.

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 description does not need to redefine the parameters. It adds minor context by clarifying that the product description can be in English or Chinese and that the source country is China, but this does not substantially extend the schema's existing parameter documentation.

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 uses a specific verb ('Find') and a concrete resource ('UK commodity code and import duty rate'), and clearly states the accepted input forms: product description in English or Chinese, or a commodity code. It also adds a distinctive behavior—flagging China-specific anti-dumping or countervailing duty—which separates it from sibling tools like 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?

The description implies when to use the tool: to look up a UK duty rate and commodity code from a product description or code, and to see China-specific AD/CVD flags. However, it does not explicitly name alternatives or state when not to use it, such as when only a detailed anti-dumping check is needed rather than a general duty-rate search.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the behavioral nuance of the optional product_type parameter (default behavior), which is useful context beyond the schema. No contradictions with annotations.

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

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

Two sentences, front-loaded with the main action, and no wasted words. The optional-call instruction is placed at the end, but the structure is clear and efficient.

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 lookup tool with two optional parameters and no output schema, the description covers what it does, the scope, and the usage nuance. Nothing essential is missing for an agent to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with both parameters documented. The description adds value by explaining the effect of omitting product_type (lists product types), which is not in the schema. This goes beyond a bare baseline of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('List'), a clear resource ('UK regulatory regimes'), and a scope ('product imported from China'), plus the deliverable ('what to ask the supplier for'). It clearly distinguishes itself from sibling tools like find_duty_rate or check_anti_dumping by focusing on 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?

The description provides an explicit usage note: 'Call with no product_type to list the product types.' It does not explicitly name alternatives or say when not to use it, but the purpose is self-evident and the sibling list shows distinct domains, so an agent can infer correct usage. This is adequate but not fully explicit.

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

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

Annotations already signal read-only and non-destructive behavior. The description adds meaningful behavioral detail: it uses the real factory shutdown rather than the statutory holiday, and it reports both collision status and the latest avoiding order date. This goes beyond the annotations without contradicting them.

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 front-load the calculation approach and then specify the two outputs, with no filler or repetition of schema details. 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?

The description covers the core algorithm, the main outputs, and the key CNY nuance, which is enough for an agent to understand the tool despite no output schema. It does not detail return formatting or edge cases, but the schema handles inputs and defaults, so the definition is reasonably complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents mode, arrival_date, transit_days, and production_days adequately. The description adds no new parameter-level semantics beyond tying 'date stock is needed' to arrival_date, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific operation—working backwards from the required stock date to the latest China order date—and explicitly defines the two outputs: whether the plan collides with the CNY closure and the latest safe order date. It is clearly distinguished from siblings like estimate_landed_cost and 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?

The description clearly communicates its context: planning China orders around the actual CNY factory shutdown. It does not name alternatives or give explicit when-not-to-use guidance, but no sibling tool directly competes for this task, so the context is sufficient.

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

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

Annotations already declare readOnlyHint=true and non-destructive behavior, so the safety profile is covered. The description adds useful behavioral context by specifying the output format (one-sentence answer and URL), which is beyond what the schema or annotations convey.

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: two sentences that first state the search scope and then immediately state the return format. Every clause earns its place, with no redundancy or 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 simple, read-only search tool with no output schema, the description covers the resource, scope, and return value. It is slightly incomplete around edge behaviors like zero results or result limits, but annotations and schema already cover the core safety and parameter needs.

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 parameters are already fully documented. The description adds topic-domain examples that help agents craft a query, but it does not meaningfully extend the schema's parameter definitions, so the baseline score 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 uses a specific verb ('Search'), names the exact resource (Cambridge China Bridge's guides to importing from China to the UK), lists topical subdomains, and states the return value (each guide's one-sentence answer and URL). This clearly separates it from the sibling calculators and checkers.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use for general guide lookups across import topics, but it does not explicitly say when to prefer search_guides over more specific siblings like find_duty_rate, find_uk_compliance, or estimate_landed_cost. Usage context is present but no exclusions or alternative routing are given.

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

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

Annotations already indicate this is a mutating, non-idempotent, open-world action. The description adds meaningful behavioral context: an email is actually sent, the recipient replies directly to the user, and the agent must never invent contact details. This goes beyond the annotation flags without contradicting them.

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 action and outcome, the usage condition, and the data-provenance constraint. The most important operational guidance is front-loaded, with no redundant 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 tool with 8 parameters and no output schema, the description covers the essential context: what happens, who replies, when to call, and the confirmation requirement. It does not describe error or failure behavior, but the external-reply outcome is clear and the schema covers parameter details.

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 each parameter. The description reinforces the key semantic constraint that all fields must come from the user and that user_confirmed requires prior agreement, but it does not add substantial per-parameter meaning 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?

The description states a specific verb ('Send'), a specific resource ('sourcing enquiry or quote request to Cambridge China Bridge'), and the delivery mechanism ('by email'). It also clarifies the expected outcome ('they reply to the user directly'), which clearly distinguishes it from the sibling research/check 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 gives explicit when-to-call guidance: 'Only call this when the user has asked to contact them'. It also specifies the required precondition: show the user exactly what will be sent and get their agreement. This is direct, actionable usage guidance.

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