customswise

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 important behavioral traits: it is 'guidance only, not binding advice,' 'high-risk cases are flagged for expert escalation,' and there is a cost of '$0.25 per call, paid automatically via x402 (USDC micropayment over HTTP 402).' This goes well beyond a simple read-only claim, though it could add a bit more about the format of the answer or any data persistence.

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 longer than a two-sentence summary but earns its length by covering purpose, use cases, topics, disclaimers, and cost. It is front-loaded with the main action and well-organized. Minor redundancy exists (the examples could be trimmed), but overall it is structured 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?

Given the tool's complexity (natural-language Q&A with one free-text parameter), the description covers purpose, when to use, example topics, non-binding nature, high-risk escalation, and cost. No output schema exists, but the return is an answer, which is implied. It is sufficiently complete for an agent to decide when and how to invoke it, though a note on response format would make it fully complete.

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

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

The input schema already describes the single parameter 'q' with examples, so schema coverage is 100%. The description adds some context by framing the question as 'general EU/Italy customs question' and listing example topics, but it largely reiterates what the schema provides. Baseline of 3 is appropriate since the schema does the heavy lifting.

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: 'Ask a general EU/Italy customs question in natural language and get a practitioner-verified answer.' It provides a specific verb+resource+result and lists concrete topic examples (import documentation, duties from China, transfer of residence, temporary admission, Italy-San Marino). It also distinguishes from siblings by positioning itself as the generalist tool versus the specialized 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?

Explicit usage guidance is given: 'Use it when you don't know which specialised tool fits, or for procedural 'how do I…' questions.' This directly addresses when to choose this tool over the specialized siblings (check_restrictions, classify_product, get_origin_rule, etc.), providing clear decision criteria.

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

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

With no annotations, the description carries full burden and succeeds: it discloses expert verification, mandatory escalation for high-risk topics (never autonomous), guidance-only non-binding advice, and the $0.25 per-call x402 USDC micropayment. These are critical behavioral traits beyond what a simple tool description would 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?

Four sentences, each with a distinct purpose: main function, input/output, usage context, escalation/payment/limitations. Information is front-loaded, and no sentence is redundant. Appropriate length for a tool with payment and escalation nuances.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no annotations, the description adequately covers input types, result categories, expert review, escalation behavior, non-binding status, and cost. An agent has enough information to decide whether and how to invoke this tool, including cost awareness before committing to a paid call.

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 for both parameters ('q' and 'lang') is 100%, so baseline is 3. The description adds concrete example inputs for 'q' ('drone with camera', '8525', 'export to Russia') that clarify the range of valid queries. It doesn't add context for 'lang', but the schema already specifies 'en'/'it' defaults.

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 performs EU import/export restriction screening, accepting a product, HS code, or country as input and returning prohibitions, licence requirements, sanctions exposure, and dual-use flags. It distinguishes itself from siblings like get_tariff (tariff rates) or classify_product (HS classification) by focusing on restrictions and legal movement.

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 says to use it 'to check whether goods can legally move before you ship,' providing a clear usage context. It doesn't name alternative sibling tools for different use cases, and the high-risk escalation note is more about tool behavior than a 'when not to use' guideline. Hence, not a perfect 5.

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

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

With no annotations, the description carries the full burden and does so well. It discloses the cost ($0.50 per call, paid via x402), the non-binding nature (not BTI/ITV), expert verification, and escalation for ambiguous cases. This gives the agent a clear picture of side effects, limitations, and operational 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?

The description is concise but information-dense, with each sentence earning its place: purpose, input, use case, legal disclaimer, and cost. It is front-loaded with the core capability and well-structured for an agent to parse.

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 and no annotations, the description covers all essential context: what output to expect (heading, reasoning, restriction flags), when to use, limitations, cost, and escalation path. This is complete for an AI agent to select and invoke the tool 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 schema already details what 'q' and 'lang' accept. The description reinforces that 'q' should be a plain-language product description but adds no new syntax or format details beyond what the schema provides.

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 what the tool does: it provides expert-verified EU/Italy customs classification support, given a product description, returning HS/CN tariff heading orientation, reasoning, and restriction flags. It distinguishes from siblings by focusing specifically on classification with a licensed customs professional review.

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 to use it before shipping cross-border to avoid wrong HS codes, and notes that ambiguous cases are escalated. It gives clear context but does not explicitly compare to alternatives such as 'ask_customs' or 'get_tariff', so it earns a 4 rather than 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?

With no annotations, the description carries the full burden. It discloses cost ($0.50), payment mechanism (x402), non-binding nature ('Guidance only'), and expert review. It does not mention rate limits or authentication, but these are less critical for a simple paid query.

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

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

The description is three sentences, front-loaded with the core purpose, followed by usage guidance and cost/caveat. Every sentence adds value without 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?

The description explains what the tool returns (rules of origin and proof methods), when to use it, and cost. With no output schema, it gives a clear sense of the response. It could be more explicit about response format or limitations, but it is sufficient for a 2-param 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?

Both parameters are fully documented in the schema (100% coverage), including examples for 'q' and default for 'lang'. The description adds no new parameter semantics, 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?

The description clearly states the tool's function: 'get the applicable rule of origin' for EU trade agreements, with specific examples of outputs (tariff-shift, EUR.1, REX). This distinguishes it from siblings like get_tariff (tariff rates) and classify_product (HS classification).

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 explicit usage context: 'Use it to determine whether goods qualify for a reduced/zero preferential duty and what documentation is required.' It does not name alternatives or exclusion criteria, but the context is unmistakable.

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 transparency burden and does so admirably. It discloses cost per call, payment method, expert review, non-binding guidance, and escalation for complex cases.

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 multi-sentence but every sentence adds value: purpose, usage, escalation, cost, and disclaimer. It is front-loaded and compact with no 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?

For a simple 2-parameter tool with no output schema, the description comprehensively covers what the tool returns, use conditions, cost, and limitations. It is more than sufficient for an AI agent to invoke 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 input schema covers 100% of parameters with examples, so the description doesn't need to add much. It implies 'chosen regime' maps to q but provides no additional semantics beyond the schema's 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 clearly states the tool explains EU special customs procedures, listing specific regimes (inward processing, outward processing, returned goods relief, temporary admission). It distinguishes from sibling tools by focusing on procedures rather than tariffs, origins, or classifications.

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 when to use the tool ('Use it to understand how to suspend or reclaim duty/VAT...') and flags complex regime structuring for expert escalation, implying when not to rely solely on this tool. It doesn't name alternative sibling tools, but the context is clear.

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

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

With no annotations provided, the description carries full weight. It discloses fallback behavior (always returns normalized code/VAT/link), cost via HTTP 402, and the advisory nature of duty rates. This is rich behavioral detail.

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 longer than ideal (6 sentences) but each sentence conveys necessary info: purpose, return behavior, usage, caveat, cost, example. It is well-structured and front-loaded with the core purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, so the description must explain return values, which it does thoroughly. It also covers limitations (rates change), cost, and payment mechanism, making it complete for the tool's complexity.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds an example code but does not add meaning beyond the schema's parameter descriptions. No compensation needed.

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 it returns import duty and Italian VAT for EU HS/CN codes, with specific detail on outputs. It distinguishes from siblings like classify_product by focusing on duty/VAT lookup rather than classification.

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 says to use it to estimate landed cost or confirm duty on a classified good, giving clear context. However, it does not explicitly contrast with sibling tools or state when not to use it, 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?

With no annotations, the description supplies full behavioral context: it is FREE, returns live counts per category, specifies tool pricing and supported languages, and notes that all answers are expert-reviewed. This is rich disclosure for a read-only catalog tool; there are no hidden side effects.

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 efficient: each sentence adds a distinct piece of information—purpose, contents, usage instruction, and verification. No redundancy or filler, and the key instruction 'Call this FIRST' is prominently placed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (no params, no output schema), the description is remarkably complete: it covers what the tool does, what it returns, its cost, languages, and its role in the workflow. An agent has everything needed to invoke it correctly and interpret the results.

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 the schema is empty. The description goes beyond schema by detailing the exact output structure (counts, tools, prices, languages), which is highly informative for a parameterless catalog. Baseline for zero parameters is 4, and the description fully compensates.

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

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

The description clearly identifies the tool as a FREE directory of available content, explicitly enumerating the categories returned (classification, duty, restrictions, origin, procedures, FAQ). It distinguishes itself from sibling paid tools by positioning itself as a discovery catalog rather than a domain-specific answer tool.

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 instructs 'Call this FIRST to discover the paid tools and confirm verified content exists before spending,' providing unambiguous when-to-use guidance. It frames the tool as a prerequisite to the paid tools, making it clear this should be the entry point.

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