customswise

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

With no annotations present, the description carries the full burden and does well: it discloses that answers are 'practitioner-verified,' that it is 'guidance only, not binding advice,' that high-risk cases are flagged for escalation, and that there is a $0.25 cost paid automatically via x402. It could add more about response format or failure handling, but the key behavioral caveats are covered.

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 longer than minimal, but every sentence earns its place: the main action, the scope, the usage guidance, the caveat, and the cost. It is front-loaded with the primary purpose and keeps important operational details after the core routing 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 natural-language Q&A tool with no output schema, the description gives the agent enough to decide whether to call it and what to expect: scope, coverage examples, routing trigger, advisory nature, escalation behavior, and pricing. It does not specify return structure, but that is less critical for this general query 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?

The schema already provides 100% coverage on the single `q` parameter with examples. The description adds value beyond the schema by framing the input as a 'general EU/Italy customs question in natural language' and enumerating the topical scope, which helps the agent craft appropriate queries.

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: 'Ask a general EU/Italy customs question in natural language and get a practitioner-verified answer.' It clearly situates the tool as a generalist fallback by naming the specialized sibling category ('when you don't know which specialised tool fits'), distinguishing it from the more targeted 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 explicitly tells the agent when to use it: 'Use it when you don't know which specialised tool fits, or for procedural 'how do I…' questions.' It does not explicitly list alternatives by name or state when not to use it, but the generalist-versus-specialist framing provides a clear routing heuristic.

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

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

With no annotations, the description carries the full disclosure burden and does it well. It discloses non-binding guidance status, mandatory expert escalation for high-risk topics such as Russia/sanctions and dual-use, and a real monetary cost paid via x402. These are exactly the behavioral traits an agent needs to know but cannot infer from the schema or 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?

Every sentence earns its place: purpose, input/output, use case, escalation rule, non-binding disclaimer, and cost. The core purpose is front-loaded and the tool's unique constraints are stated without fluff. It is longer than average but only because it covers more necessary ground.

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 no output schema and no annotations, this description is unusually complete. It covers what results to expect, how to structure queries, what will not be answered autonomously, that the output is non-binding guidance, and that each call costs money. An agent has everything needed to invoke it correctly and warn users appropriately.

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 concrete examples for q ('drone with camera', '8525', 'export to Russia') and explains that q can be a product, HS code, or country. This meaningfully enriches the schema's already decent parameter description, though lang is left entirely to the schema.

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

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

The description names a specific resource (EU import/export restrictions) and a clear verb (screen/check), enumerating concrete outputs: prohibitions, licence requirements, sanctions exposure, and dual-use flags. It is clearly distinguishable from siblings like classify_product or get_tariff, which cover classification and tariff data rather than restriction 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 states a concrete use case: 'Use it to check whether goods can legally move before you ship.' This gives clear context for when the tool applies. It does not explicitly name alternative tools or state when not to use it, but the restriction-focused scope plus the escalating-never-answer rule provides enough guidance for an agent to route appropriately.

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

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

With no annotations, the description carries the full behavioral burden. It discloses the expert-review process, non-binding nature, escalation of ambiguous cases, and the $0.50 x402/USDC micropayment over HTTP 402. This is unusually transparent.

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 well-structured: purpose first, then usage context, then caveats, then cost. Each sentence adds necessary information and there is no filler or redundancy.

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?

Despite no output schema, the description enumerates the return contents: heading orientation, reasoning/notes, and restriction flags. It also covers cost, legal caveat, escalation behavior, and fully leverages the schema for parameters. Nothing critical is missing for an agent to invoke and interpret the result.

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

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

The schema already covers both parameters fully, including the q description and lang default. The tool description restates the plain-language input concept but adds no parameter-specific meaning beyond the schema, so the baseline score 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 action and resource: it classifies a product into a likely HS/CN tariff heading and returns reasoning and import-restriction flags. It clearly distinguishes this tool from generic tariff lookup by emphasizing expert review, signature, and guidance-only status.

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

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

It gives clear usage context: use before shipping cross-border to avoid wrong HS codes, and explicitly warns it is not a legally binding BTI/ITV. However, it does not name sibling tools such as get_tariff or ask_customs or explain when to prefer them.

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

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

No annotations are provided, so the description carries the full burden. It discloses the expert-reviewed nature, non-binding guidance caveat, and the $0.50 per-call cost paid via x402 micropayment. These are meaningful behavioral traits beyond the basic operation, though it does not cover every possible limitation.

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 moderately long but front-loaded with the core purpose and output. The cost and payment details are relevant for the agent's decision-making, and the caveat about non-binding advice is important. Each sentence contributes, though some marketing language could be trimmed.

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 sufficiently explains what the tool returns: the applicable rule of origin and proof method (EUR.1, statement on origin, or REX). It also covers cost, language options via schema, and the non-binding nature. This is adequate 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 coverage is 100%, so the baseline is 3. The description adds value by giving concrete examples for the 'q' parameter ('olive oil' or 'EU-South Korea EUR.1') and clarifying that it accepts a product or an agreement, which aids the agent in forming correct queries.

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 function: providing expert-verified preferential rules of origin for EU trade agreements, including the applicable rule and proof documentation. It explicitly says to use it to determine whether goods qualify for reduced/zero preferential duty, which distinguishes it from sibling tools focused on tariffs, classification, or procedures.

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

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

The description gives a clear use case: determining origin qualification and required documentation. It does not explicitly mention when not to use it or name alternatives among the siblings, so it stops short of full exclusion guidance.

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

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

No annotations are provided, so the description carries the full burden, and it does so well. It discloses the $0.25 paid call via x402/HTTP 402, states that it is guidance only and not binding advice, explains output contents, and notes expert escalation for complex cases. No contradiction with annotations 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?

The description is moderately sized and front-loaded with the core purpose. There is slight redundancy between 'Expert-verified' and 'reviewed by a licensed customs professional,' but each sentence contributes operational or legal context such as payment, non-binding nature, and escalation.

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 compensates by listing what is returned: purpose, eligibility conditions, required documents, and practical notes. It also covers cost, language, scope, and escalation. The main gap is that the exact response format/structure is not described.

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%; both 'q' and 'lang' already have clear descriptions and examples in the schema. The description adds no parameter-level meaning beyond what the input schema provides, so the baseline of 3 is appropriate.

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

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

The description clearly identifies a specific verb+resource: it returns expert-verified explanations of EU special customs procedures and enumerates the covered regimes (inward processing, outward processing, returned goods relief, temporary admission). It is clearly distinct from sibling tariff/origin/classification tools, though it does not explicitly name or contrast a sibling.

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

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

The description gives a clear usage context: 'Use it to understand how to suspend or reclaim duty/VAT when goods are processed, repaired or temporarily moved across the EU border.' It also flags that complex regime structuring is escalated, but it does not explicitly state when not to use the tool or name alternative siblings.

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

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

With no annotations provided, the description carries the full burden and does well: it explains fallback behavior (returns a normalized code, Italian VAT rate, and TARIC link even when a practitioner-verified duty is unavailable), the automatic x402 payment model, and the non-binding reference nature of the data. This goes well beyond a bare operation statement.

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 information-dense but every major point earns its place: purpose, fallback behavior, primary use case, data volatility caveat, pricing/payment method, and an example. It is slightly long, but the density is justified; key purpose is front-loaded in the first 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?

There is no output schema, so the description reasonably covers what the caller receives: duty when available, normalized code, Italian VAT rate, and a TARIC deep link. The payment mechanism and example round out the practical context needed to invoke the tool correctly. A fully formal return structure is missing, but the description is sufficient for an agent to use 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%, so the baseline is 3. The description adds a concrete example code and clarifies that the returned code is normalized/validated, but it does not materially expand on the parameter definitions already present in the schema.

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

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

The description opens with a specific verb and resource: 'Expert-verified import duty and Italian import VAT for any EU HS/CN code.' This cleanly distinguishes get_tariff from siblings like classify_product, get_origin_rule, and check_restrictions by naming the exact data domain (duty/VAT) and input type (HS/CN code).

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 explicitly tells the agent when to use it: 'Use it to estimate landed cost or confirm the duty on a classified good.' While it does not name alternative sibling tools or say when not to use it, the use cases are concrete and clearly scoped, and the caveat about rates changing adds a practical boundary.

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

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

With no annotations, the description carries the full burden, and it does well: it discloses that the tool is FREE, that it reports current availability ('available right now'), and that all answers are reviewed by a licensed customs professional. It does not mention rate limits or exact response format, but for a zero-parameter discovery tool these are not significant omissions.

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

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

The description is compact and front-loaded with the most important signal ('FREE') and the core purpose. Every sentence earns its place: the category list is specific, the 'Call this FIRST' instruction is actionable, and the expert-review note reinforces trust without padding.

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 zero-parameter catalog tool with no annotations or output schema, the description is complete: it names the categories, the per-category data returned (count, tool, price, languages), the intended usage order, and the verification quality. An agent has everything needed to call it and interpret the reason for doing so.

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 tool has zero parameters and 100% schema coverage, so the baseline is 4. The description appropriately explains what the tool returns without needing to document parameters, and it adds useful semantic framing about the catalog being the entry point to paid tools.

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 this is a directory of everything CustomsWise can answer, with a specific verb ('Returns') and a precise list of what is returned per category: count of verified entries, serving tool, price, and supported languages. This fully distinguishes it from the sibling tools like get_tariff or classify_product, which are the paid tools it catalogs.

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

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

The description explicitly says 'Call this FIRST to discover the paid tools and confirm verified content exists before spending,' which gives a clear entry-point use case and frames the paid tools as the next step. It does not name specific alternatives or state when not to use it, so it stops just short of full exclusion guidance.

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