Jithox EU Import Preflight

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

Beyond annotations (readOnlyHint=true, destructiveHint=false), the description adds valuable behavioral context: it returns statuses like 'not_ready', 'needs_review', and 'unavailable', notes that results are non-binding candidates, and states that every result includes source and validity window. This enriches the agent's understanding 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?

The description is four sentences, front-loaded with the core action, and each subsequent sentence adds value (status behavior, legal caveats, metadata). It is efficient, though slightly dense, so a 4 is deserved.

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 tool is adequately described for an agent to invoke correctly: it covers inputs, outputs, limitations, and safety profile. The output schema (implied) handles return value details, so the description doesn't overburden itself. This level of detail is sufficient for a 6-parameter 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?

Input schema has full descriptions for all 6 parameters, so the description doesn't need to add parameter details. It reinforces 'candidate TARIC code + origin' and 'dated snapshot' but adds no new meaning beyond the schema, 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 lists EU-level import measures for a candidate TARIC code and origin, naming specific measure types. This distinguishes it from siblings like search_taric_codes or estimate_low_value_import_cost, which serve different purposes.

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 usage context (checking measures for classification) and provides a clear exclusion: TARIC carries no national VAT/excise, indicating when not to rely on this tool. However, it does not explicitly name alternative sibling tools, 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?

Beyond readOnlyHint and destructiveHint, the description discloses key behaviors: all amounts are candidates, missing data is returned as 'missing' (never guessed), and every result carries source, retrieval time, and validity window. This significantly enhances transparency for a calculation tool.

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, front-loaded with purpose, and every sentence adds value: scope, date rules, missing-data policy, TARIC limitation, and result metadata. No redundant or wasted words.

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 tool is complex (7 params, layered duty rules), but the description covers the core calculation logic, exceptions, data handling, and output guarantees. With an output schema present, return values need not be described. The description is sufficiently complete for an agent to understand what this tool does and how to 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 baseline is 3. The description adds meaning by defining 'low-value' (≤ EUR 150), explaining the date-dependent duty relief and EUR 3 fee (relevant to asOfDate), and clarifying that TARIC does not include national VAT/excise (relevant to taricCandidate and destinationVatRatePercent). This enriches parameter understanding beyond 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 clearly states the tool estimates landed cost for low-value consignments (≤ EUR 150) to an EU state, with specific verb 'estimate' and resource 'landed cost'. It distinguishes from siblings by focusing on cost calculation rather than checking measures, preparing receipts, searching codes, or validating EORI.

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?

Provides clear context: low-value consignments to EU states on a given date. It implies when to use (within the EUR 150 threshold) but does not explicitly name alternatives or exclusions. The caveat about TARIC lacking national VAT/excise adds partial usage 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?

Beyond the annotations (readOnlyHint=true, destructiveHint=false), the description discloses important behavioral traits: idempotency, Ed25519 signing, commitment to inputs/sources/times/dates, and the scope of attestation (checks, not compliance outcomes). This significantly enriches the agent's understanding of the tool's side effects and guarantees.

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 but efficient. It front-loads the primary action and packs critical details (idempotent, signed, read-only, legal disclaimer) into two coherent sentences with no filler. Every clause serves a 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?

Given the tool's moderate complexity (two parameters, nested bundle object, output schema present) and rich annotations, the description is complete. It covers purpose, behavior, limitations, and the non-decision status, leaving no significant ambiguity for an agent deciding to invoke it.

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% (both bundle and createdAt have detailed descriptions). The description adds meaning by explaining that the bundle contains preflight results and that the receipt commits to inputs, sources, retrieval times, and validity dates, which clarifies the expected content of the 'bundle' parameter beyond the schema's brief mention.

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 specifies a clear action ('Bundle the preflight checks ... into one idempotent Ed25519-signed receipt') and resource (receipt). It distinguishes itself from sibling tools by focusing on packaging all preflight checks into a single attestation, rather than performing individual checks like EORI validation or cost estimation.

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 the tool (after preflight checks, to create provable evidence) and explicitly states exclusions ('not a customs decision or clearance', 'not customs/tax/legal advice'). It does not explicitly name alternative tools, but the sibling list makes it clear that individual check tools are alternatives for specific checks.

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?

Beyond the annotations (readOnly, non-destructive), the description adds significant behavioral details: it returns 'needs_review' or 'unavailable', never invented codes, always includes source, retrieval time, and validity window, and clarifies that only a BTI binds. This provides rich context not captured in annotations, and aligns with 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 three sentences, front-loaded with the core purpose in the first sentence. Each subsequent sentence adds crucial caveats and behavioral guarantees without redundancy, making it highly concise and well-structured.

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, the description covers return conditions (needs_review/unavailable), data provenance (dated snapshot, source, retrieval time, validity), limitations (BTI binding, no VAT/excise), and safety (never invented). The output schema handles return structure, so the description is comprehensive.

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 parameters are already described (productDescription and knownProperties). The description only restates 'plain-language product description' without adding new semantics for either parameter. It does not clarify how knownProperties influences ranking or evidence, so it stays at baseline.

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: returning candidate TARIC/CN codes from a plain-language product description, ranked with evidence. This distinguishes it from sibling tools which handle measures, cost estimation, preflight receipts, and EORI validation, making the purpose unambiguous.

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 usage: from a plain-language product description, get candidate codes. It also provides when-not guidance by stating TARIC carries no national VAT/excise, signaling users should seek separate tools for those. However, it does not explicitly name alternative sibling tools, so it lacks explicit exclusions/alternatives.

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?

Beyond the annotations (readOnlyHint, openWorldHint, destructiveHint), the description discloses critical behavior under provider outage or unknown status, stating it returns 'unavailable'/'needs_review' and never a false 'invalid'. It also clarifies the configuration dependency and disclaims legal/customs decision authority, adding substantial transparency.

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, and every sentence contributes unique value (function, edge-case behavior, limitations). No redundant or filler content exists.

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 single-parameter input, existing output schema, and annotations, the description covers the key operational aspects: conditional behavior, provider unavailability, the meaning of structural validity, and disclaimers. It is sufficiently complete for an agent to understand when and how to use it.

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 fully describes the 'eori' parameter with an example and length constraints (100% coverage). The description does not add further parameter-level semantics beyond the schema, so the baseline of 3 is appropriate.

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

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

The description explicitly states the tool performs a 'structural check' and, conditionally, an 'authoritative existence check' of an EORI number. This clearly differentiates it from siblings that handle import measures, costs, receipts, and tariff codes.

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 that this is a read-only preflight used for EORI validation, and it cautions against relying on structural validity as proof of customs authorisation. However, it does not explicitly name alternative tools for exclusion, 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.