---
name: classify-product
description: Research a product against the current Tariff Code Compliance knowledge graph. Use for HS, HTS, tariff-code, or customs-classification recommendations.
---

# Classify Product

Use this workflow when a user asks for a tariff classification or tariff-code recommendation. The result is research support for the current conversation, not legal advice or a binding customs ruling.

## Boundaries

- Tariff Code Compliance tools only read tariff evidence. The user decides whether and how to use the recommendation. Do not claim it is legal advice or a binding legal determination.
- Keep this workflow's output focused on classification. The research may encounter duty-rate information in the graph, but do not include duty rates, fees, taxes, landed cost, or calculations of those amounts in a classification response. Duty analysis belongs in a separate workflow.
- Treat tool results as evidence. Explain uncertainty and recommend review by a qualified customs professional when the decision is material.
- Send the relevant product, destination, and classification facts needed for the MCP workflow. Do not send a full conversation, personal information, credentials, authentication secrets, or unrelated catalog data.
- Never assume that a tariff system, version, node kind, identifier scheme, or relation exists. Discover the current runtime contract first.

## First-use starter request

The connector, public guide, and Claude walkthrough use the exact request delimited below.

<!-- TCC_CLASSIFY_PRODUCT_STARTER_REQUEST_BEGIN -->
Classify this product for import into [destination country or customs territory]:

[product description]

Ask the user for the import destination if it was omitted. Ask the user for the entire product description if it was omitted. Then ask only for any other missing product facts that could change the classification. Use Tariff Code Compliance to discover the currently enabled tariff system that covers the destination and its exact active version, then research the relevant classification nodes and graph evidence. Return the tariff system and exact version, recommended code and description, product facts used, supporting evidence, rejected alternatives and why they do not fit, assumptions, and remaining uncertainty. If the destination is not covered or the facts or evidence are insufficient, return the unresolved candidates and focused follow-up questions instead of forcing a code.

Tariff Code Compliance tools only read tariff evidence. Treat the recommendation as non-binding research support, not legal advice or a binding customs ruling. The user decides whether and how to use it.

Keep this response focused on classification. Do not include duty rates, fees, taxes, landed cost, or calculations of those amounts.

Use only the customer-facing `reference` and `references` fields returned by Tariff Code Compliance when naming graph evidence. For every relevant recommended, ancestor, candidate, or rejected code and every decisive note, exclusion, term, or annotation, render a Markdown link in the exact form `[<reference.label>](<reference.url>)` only when `reference.url` is present, substituting both values verbatim from that returned reference. When `reference.url` is absent, show `reference.label` as plain text with readable official provenance; never guess or hand-build a link. Never print or transform node IDs, `system_version_id`, source or storage keys, UUIDs, or page or continuation tokens, including values beginning `ent:`, `sysv:`, or `NATIONAL_`. If an entity-specific reference is unavailable, use the returned exact system/version reference under the same URL-present rule; do not expose the opaque value.
<!-- TCC_CLASSIFY_PRODUCT_STARTER_REQUEST_END -->

## Workflow

1. Determine the destination jurisdiction or intended tariff system. If the user has not supplied one, ask a focused follow-up before researching a code.
2. Call `list_tariff_systems`. Select only an enabled system returned by the runtime. Use that system's returned default version unless the user explicitly requests another available version. U.S. HTS may be the only available system; do not offer planned systems as available choices.
3. Call `describe_tariff_system` with that system and version. Use its returned profile and `guide_markdown` as reference data for the available node kinds, identifier schemes, relations, locales, and properties.
4. Gather the material product facts needed to distinguish plausible classifications. Prefer focused questions about:
   - what the product is and its principal function;
   - material or composition, including meaningful percentages when relevant;
   - construction, form, dimensions, capacity, or power source when relevant;
   - intended use and users;
   - whether it is a complete product, part, set, kit, mixture, or retail package;
   - destination-specific facts identified by the tariff-system guide.
5. Research narrowly with the MCP tools. For a discovered `US_HTS` system and exact version, use `search_hts` for lexical provision and note discovery and `semantic_search_hts` separately for conceptual product descriptions. Use `search_nodes` for classification-code prefixes or classification terms under the selected system's guide, not as a universal notes search. Use `resolve_nodes` for known source keys or typed identifiers, `get_node` for authoritative node detail, and `list_node_edges` or `traverse_nodes` for bounded hierarchy, notes, exclusions, definitions, rates, and cross-references. Verify every serious search candidate in that same exact graph version before recommending it.
6. Compare realistic alternatives. Do not choose a code from a label match alone. Trace the supporting hierarchy and relevant notes or exclusions available in the selected graph.
7. Stop when the evidence is sufficient for a recommendation, or when missing material facts prevent a defensible choice.

## Sufficient-information response

Return a structured result containing:

- selected tariff system and exact version;
- recommended classification code and readable linked label;
- concise reasoning tied to the product facts and MCP evidence;
- important supporting notes, exclusions, relations, or provenance;
- rejected alternatives and why each was rejected;
- assumptions and uncertainty;
- a reminder that the recommendation is non-binding research support, not legal advice or a binding ruling, and that the user controls downstream use.

Keep this response focused on classification. Do not include duty rates, fees, taxes, landed cost, or calculations of those amounts.

## Insufficient-information response

When confidence is not sufficient, do not force a single answer. Return:

- selected tariff system and exact version, if known;
- unresolved candidate classifications and the evidence supporting each;
- the material facts still needed to distinguish them;
- focused follow-up questions, ordered by decision value;
- any alternatives already rejected and why;
- the current uncertainty and the same non-binding research-support boundary.

Keep this response focused on classification. Do not include duty rates, fees, taxes, landed cost, or calculations of those amounts.

## Tool discipline

- HTS search is US-specific; never substitute it for an unsupported destination. Discover destination coverage first and explain unavailable coverage without promising planned systems.
- Both HTS searches accept the selected `system`, exact `version`, `query`, optional `kinds`, `scope`, and `limit`, not `effective_at` or page tokens. Scope is `{type: "general_note" | "gri" | "chapter", number: string}`; `"*"` is supported for general-note and chapter families, not GRI. To search all chapter and section notes, combine `scope: {type: "chapter", number: "*"}` with `kinds: ["note"]`. Scope intersects kinds before ranking; narrow only when evidence justifies excluding other provisions.
- Search rank and semantic similarity identify candidates, not legal applicability or confidence. Empty results or an unavailable selected-version index do not prove no relevant provision exists. State the gap, and label any separately chosen graph or lexical research rather than silently substituting a different mode or version.

Use only the customer-facing `reference` and `references` fields returned by Tariff Code Compliance when naming graph evidence. For every relevant recommended, ancestor, candidate, or rejected code and every decisive note, exclusion, term, or annotation, render a Markdown link in the exact form `[<reference.label>](<reference.url>)` only when `reference.url` is present, substituting both values verbatim from that returned reference. When `reference.url` is absent, show `reference.label` as plain text with readable official provenance; never guess or hand-build a link. Never print or transform node IDs, `system_version_id`, source or storage keys, UUIDs, or page or continuation tokens, including values beginning `ent:`, `sysv:`, or `NATIONAL_`. If an entity-specific reference is unavailable, use the returned exact system/version reference under the same URL-present rule; do not expose the opaque value.

- Use the exact `system` and `version` returned by discovery on every version-scoped call.
- Keep search terms specific. If a search is too broad, narrow it instead of retrying unchanged.
- Treat opaque node IDs and page tokens as tool-call inputs only, never customer-facing evidence.
- Follow continuation tokens only when another page is necessary for the decision.
- Respect traversal bounds. If a result is truncated, narrow the relation, direction, or starting nodes.
- Send the product, tariff, and classification facts needed for the workflow. Do not send personal information, credentials, authentication secrets, or unrelated data to Tariff Code Compliance.

## Interactive research panel

When `render_research_panel` is available and the host supports its UI, use it as a quiet research companion after meaningful research steps and chat answers. Ask all clarification in chat; the panel is not a questionnaire. Pass the selected system and exact version, known product facts and open checks, up to four concise milestones (preserving relevant earlier steps), one short `nextStep`, and up to three researched candidates with assessments and `leading`, `alternative`, or `set-aside` states. Include their relevant evidence node IDs. For already researched CBP rulings, optionally pass up to two exact ruling numbers with concise model comparisons in `rulings` and associate them through each candidate's `rulingNumbers`. The server retrieves source records and links for the on-demand Authority Notebook; never supply source text or URLs. Milestones, states and comparisons are research interpretation, not verified legal findings. Keep chat concise: explain what changed or ask the next material question rather than repeating the panel's tables.

The tariff-system dropdown reflects actual runtime availability and may contain only U.S. HTS. A system change starts fresh research under that system's default version; never carry candidates or conclusions across systems or versions. For a request specifically about an HS-level code, research the applicable six-digit provision and shared chapter evidence available within the selected U.S. HTS version, clearly identifying that source. Do not imply that a separate HS dataset or another country's national tariff system was queried, or that truncating a national code establishes a classification.

After a conversational answer, research the remaining distinction and render an updated trail preserving known facts and candidate reasons, including alternatives set aside when useful. An explicit source question from the notebook is a follow-up in the existing conversation. Treat product facts and assessments as user/model context, not authoritative tariff evidence. If the tool or UI is unavailable, continue with the evidence-backed text workflow; do not claim a panel was displayed. Updates occur after research steps; do not claim continuous streaming or persistence beyond the host's current research result. Hydrated evidence is metered research, so the same account-recovery rules apply.

## First response and account recovery

Start with the missing destination or product description, then the highest-value distinguishing fact. If those facts are already present, begin the research without repeating an intake form. Use customer language rather than a tool inventory or internal graph terminology.

If a research tool is denied for account access or credits, call `get_account_status` on the existing connection. Explain its safe `access_message` and returned `profile_url`; do not expose account IDs. Pause paid research calls until a fresh status confirms access and credits are available. If status itself is unavailable, explain the blocker without guessing the balance or retrying paid tools. For an authentication failure, direct the user to reconnect through the client's normal connection controls. Never request passwords or tokens, send verification emails, buy credits, or change billing or authentication settings.