Klassio — EU customs tariff (CN/HS) classification + EUDR

klassio_classify_article

Read-onlyIdempotent

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.

Input Schema

TableJSON Schema

Name	Required	Description
`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.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`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

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 18, 2026

TDQS

A4.5/5.0

Behavior4/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

All Klassio — EU customs tariff (CN/HS) classification + EUDR tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?