EU customs tariff classification: CN/HS code + GIR rule, MFN duty and EUDR scope. Sourced.
Scored across 2 tools
The two tools are cleanly separated: one handles free-text product classification, the other handles lookups for an already-known CN code. There is no overlap in input or purpose.
Both tools follow a consistent klassio_verb_noun pattern (classify_article, lookup_cn_code). The naming is uniform, predictable, and clearly indicates the action and resource.
Two tools is on the thin side for a server covering tariff classification and EUDR, but the scope is narrow enough that classification plus code lookup covers the core use case. It feels minimal rather than excessive.
The core workflow is covered: classify an unknown product and look up details for a known code, including EUDR scope and duties. Minor gaps exist, such as no batch classification or code search, but these do not break the primary use case.
Single-product classification. Accepts a free-text description plus optional structured hints (materials, intended_use, category, origin/destination country). POPULATE EVERY HINT YOU HAVE — materials/intended_use/category materially improve retrieval and candidate quality vs a description-only call (e.g. description:"Funko POP Vinyl", category:"Figurines", materials:["PVC plastic"], intended_use:"decorative collectible figure" reliably surfaces ch. 95). Returns top-3 CN candidates, EUDR scope, MFN duty, a bilingual reasoning_md narrative, a gap_analysis flagging missing inputs, and a tri-state status (confident / review_recommended / manual_review_required). Trust status for review-routing — do not re-derive your own confidence threshold. PAT-authed callers also receive prior_decisions[] from the org dictionary history.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Return reasoning in a single language: drops the redundant rationale_* field for the other and (with compact_rules) collapses the shared rule pool to this language. Absent = bilingual (default). | |
| dry_run | No | First half of the BYOM eval loop: with dry_run:true retrieval + prompt-build run but the judge is NOT called — returns candidates_top10 + request_token only, no judge spend. Judge with your own model (e.g. fan out across subagents to parallelise), then call klassio_submit_classification_verdict. Prefer this over the inline judge for bulk eval/scoring. | |
| include | No | L3 opt-ins. 'compact_rules' hoists per-candidate rule bodies into a shared top-level classification_rules pool (candidates carry rule_ids[] instead). 'truncate_rules' truncates the pool bodies to ~240 chars (use with compact_rules). Default = master shape (per-candidate bilingual classification_rules, no pool). | |
| category | No | Your internal product-taxonomy label, e.g. "Figurines", "Vacuum Cleaner Accessories". Folded into the retrieval query to anchor the right chapter (e.g. "Figurines" pulls ch. 95 toys instead of ch. 39 raw polymer). Populate whenever you have one. | |
| materials | No | Constituent materials, e.g. ["PVC plastic","vinyl"] or ["wood","MDF"]. Strongly improves retrieval — a material-poor description retrieves weaker candidates. Populate whenever known. | |
| current_cn | No | ||
| description | Yes | ||
| origin_iso2 | No | Country of origin (ISO 3166-1 alpha-2, e.g. "CN"). Improves duty/FTA and EUDR country-risk context and disambiguates origin-sensitive headings. | |
| intended_use | No | Function / end use, e.g. "decorative collectible figure" or "kitchen cabinet door panel". Disambiguates products whose bare name misleads (a "Funko POP Vinyl" reads as raw vinyl without it). Populate whenever known. | |
| destination_iso2 | No | Import destination country (ISO 3166-1 alpha-2, e.g. "SE"). Adds destination-specific measure/declaration context. | |
| omit_system_prompt | No | Dry-run only: omit the re-sent judge system prompt from dry_run_prompt.system (set null) to save ~3k tokens per call. prompt_version is still returned so a caller can validate a system cached via klassio_get_judge_system_prompt. Does NOT change request_token. Default false (system included). | |
| omit_raw_candidates | No | Dry-run only: omit the diagnostic dry_run_prompt.raw_candidates pool. Default false (raw_candidates included). The BYOM submit path re-runs retrieval, so omitting this does not affect request_token. |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| taric_gap | No | |
| candidates | Yes | |
| confidence | Yes | |
| query_used | Yes | |
| result_ref | Yes | |
| taric_code | No | |
| gri_applied | Yes | |
| judge_debug | Yes | |
| taric_basis | No | |
| gap_analysis | Yes | |
| judge_winner | Yes | |
| rationale_en | Yes | |
| rationale_sv | Yes | |
| reasoning_md | Yes | |
| dry_run_prompt | No | |
| taric_measures | No | |
| judge_runner_up | Yes | |
| prior_decisions | No | |
| taric_candidates | No | |
| mfn_across_leaves | No | |
| retrieval_quality | No | |
| recommended_action | No | |
| classification_rules | No | |
| judge_quota_remaining | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior. The description adds behavioral context: tri-state status semantics, gap_analysis for missing inputs, and PAT-authed prior_decisions[] . No contradiction with 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?
Dense but economical: purpose first, then usage emphasis with concrete example, then outputs, status authority, and auth-dependent extras. Every sentence earns its place; no fluff.
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 12-param tool with rich output schema, the description covers scope, hint population, return semantics, review routing, and auth-dependent behavior. Remaining params (lang, dry_run, include, current_cn) are well documented in the schema, so nothing important is missing.
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 83%, so the schema already documents most parameters. The description adds real value with the Funko POP example, explaining how category/materials/use combine to surface the right chapter, and strongly signals which optional fields are worth populating.
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?
Description opens with 'Single-product classification', a precise verb+resource, and immediately lists inputs and outputs: top-3 candidates, EUDR scope, MFN duty, bilingual reasoning, gap analysis, tri-state status. This clearly distinguishes it from the sibling klassio_lookup_cn_code even without naming it.
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?
Gives strong usage guidance: 'POPULATE EVERY HINT YOU HAVE' and explains that materials/intended_use/category materially improve retrieval vs description-only. Also advises trusting `status` for review routing. It doesn't explicitly say when to choose klassio_lookup_cn_code instead, so 'when-not' is missing, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fast lookup for a known CN code. Returns the canonical description (SV + EN), chapter heading, applicable classification rules, EUDR Annex I scope (in_scope + is_ex), and the MFN duty headline. Pass include=["reasoning"] to also receive the bilingual reasoning_md narrative.
| Name | Required | Description | Default |
|---|---|---|---|
| cn_code | Yes | ||
| include | No |
| Name | Required | Description |
|---|---|---|
| duty | No | |
| eudr | No | |
| found | Yes | |
| cn_code | Yes | |
| message | No | |
| reasoning_md | No | |
| description_en | No | |
| description_sv | No | |
| cn_code_display | No | |
| classification_rules | No | |
| chapter_description_en | No | |
| chapter_description_sv | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint, idempotentHint, and destructiveHint=false already provided, there is no contradiction and no need for side-effect warnings. The description adds behavioral value by revealing that include=['reasoning'] changes the response to append a bilingual reasoning narrative, and by characterizing the operation as a fast deterministic lookup.
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?
Two compact sentences carry purpose, output summary, and the single optional parameter behavior. No filler, redundancy, or tautology.
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 read-only, idempotent two-parameter lookup with an output schema present, the description is complete: it names the required input, the returned fields, and the optional include flag. Nothing needed to call the tool correctly is missing.
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 0%, so the description must supply parameter meaning; it explains include=['reasoning'] precisely, and identifies cn_code as the known CN code being looked up. The valid digit-length alternatives are left to the schema pattern, which is an acceptable structured constraint.
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 operation ('lookup') on a concrete resource ('a known CN code') and enumerates what is returned. The word 'known' signals that this is a direct code lookup rather than a classification task, helping distinguish it from klassio_classify_article.
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?
'Fast lookup for a known CN code' clearly tells the agent when to call this tool: when the code is already known. It does not explicitly say 'use klassio_classify_article when the code is unknown,' so it lacks a full when-not/alternative statement, but the context is strongly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
klassio_classify_articleklassio_lookup_cn_codePractitioner-verified EU customs facts: classification, duty, origin, procedures. x402.
EU customs-trade & industrial-production statistics (Eurostat Comext/PRODCOM)
Classify, validate & verify HS codes and access tariff compliance data for cross-border trade
Classify products to official HS codes and validate supplier codes before customs submissions
Add one secure layer between your agents and this server.
