Jithox EU Import Preflight

Check EU import measures for a classification

check_eu_import_measures

Read-only

For a candidate TARIC code + origin, list EU-level import measures from a dated snapshot: third-country duty, tariff preferences, prohibitions/restrictions, surveillance. A restriction hit is a 'not_ready' signal to review, not a legal determination; compound/unknown measures return 'needs_review'; no snapshot → 'unavailable'. Classifications/measures are CANDIDATES for a declarant to confirm; only a BTI binds. 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
`code`	No	Candidate TARIC/CN code.
`date`	No	ISO date to evaluate (defaults to today).
`itemCount`	No	Number of items (optional).
`goodsValueEur`	No	Customs value in EUR (optional).
`originCountry`	No	ISO alpha-2 country of origin.
`destinationCountry`	No	ISO alpha-2 EU destination.

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.4/5.0

Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

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?