Jithox EU Import Preflight

Estimate low-value import cost

estimate_low_value_import_cost

Read-only

Estimate the landed cost for a low-value consignment (intrinsic value ≤ EUR 150) to an EU state on a given date: EUR 150 duty relief until 2026-06-30, then the temporary EUR 3-per-item duty from 2026-07-01, plus destination import VAT. All amounts are candidates; missing data is returned as 'missing', never guessed. TARIC carries no national VAT/excise — those are separate. Every result carries its source, retrieval time and validity window.

Input Schema

TableJSON Schema

Name	Required	Description
`items`	No	The consignment items.
`asOfDate`	No	ISO date that selects the duty regime.
`currency`	No	ISO 4217 currency of the values.
`iossUsed`	No	Whether IOSS is used for VAT (optional).
`originCountry`	No	ISO alpha-2 origin (optional).
`destinationCountry`	No	ISO alpha-2 EU destination.
`destinationVatRatePercent`	No	Destination VAT rate % (optional).

Output Schema

TableJSON Schema

Name	Required	Description	Default
`data`	Yes
`billing`	Yes
`product`	Yes
`receipt`	Yes
`decision`	Yes
`retryable`	Yes
`capability`	Yes
`provenance`	Yes
`generatedAt`	Yes
`limitations`	Yes
`schemaVersion`	Yes
`receiptEnvelope`	No
`decisionCategory`	Yes

TDQS

A4.7/5.0

Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

All Jithox EU Import Preflight tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.7/5.0

Disambiguation5/5

Each tool targets a distinct aspect of the preflight workflow: classification, measures, cost, EORI validation, and receipt generation. There is no overlap in purpose, and the descriptions reinforce the boundaries. An agent can accurately select the right tool for a given step.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with snake_case: check_, estimate_, prepare_, search_, validate_. This makes the tools predictable and easy to navigate. No mixed conventions or ambiguous verbs.

Tool Count5/5

Five tools is well-scoped for an EU import preflight service. Each tool earns its place by covering a key step in the workflow, from product classification to cost estimation and evidence generation. There is no bloat or missing essential function.

Completeness5/5

The tool surface covers the full preflight lifecycle: search codes, check measures, estimate cost for low-value consignments, validate EORI, and bundle results into a signed receipt. The descriptions explicitly call out out-of-scope areas (national VAT/excise) so gaps are intentional. No dead ends or missing critical operations for the stated purpose.

Resources

Need Help?