Skip to main content
Glama

Combined Nomenclature description

cn_describe
Read-onlyIdempotent

Describe a CBAM-related Combined Nomenclature code: label, hierarchy, sub-codes, and cross-year differences. Accepts 2-8 digit CN or 10-digit TARIC codes; not legally binding.

Instructions

The Combined Nomenclature description of a code in CN 2026 or CN 2025: label, self-explanatory text, the hierarchy above it (section, chapter, heading, subheading), its sub-codes, and whether the other year differs. Covers chapters 25, 28, 31, 72, 73, 76 and headings 2601 and 2716 (where the CBAM goods are); other codes return found=false. Not legally binding: the binding CN is the Official Journal text of Commission Implementing Regulation (EU) 2025/1926 (CN 2026) or 2024/2522 (CN 2025).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
yearNoCN version, default 2026
cn_codeYesCN code, 2 to 8 digits (or a 10-digit TARIC code), with or without spaces or dots: '7208 51 20', '72085120', '7208.51.20', '7208'

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, non-destructive behavior, but the description adds real context beyond them: the full shape of the response, the found=false failure mode for uncovered codes, the other-year diff field, and the non-binding legal caveat with the authoritative source cited.

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?

Front-loads the returned payload, then coverage limits, then the legal disclaimer. Dense but each sentence carries distinct, actionable information; the disclaimer is arguably the least essential clause but is relevant for a customs tool.

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?

With no output schema, the description fully carries the burden of describing return values and failure semantics, and it also documents the supported-code scope and authoritative-source caveat. An agent has everything needed to call and interpret it.

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?

Schema coverage is 100% and both parameters (year enum, cn_code format examples) are already fully documented in the schema. The description adds no syntax or semantics beyond what the structured fields provide, so the baseline 3 applies.

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?

Names a specific resource (CN code description) and enumerates exactly what it returns: label, text, hierarchy, sub-codes, cross-year delta. This is clearly distinct from siblings like compare_origins and cbam_scope.

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?

Defines the operative scope precisely: covers chapters 25, 28, 31, 72, 73, 76 and headings 2601/2716, with other codes returning found=false. That effectively tells the agent when this tool will and won't yield data, though it doesn't route to an alternative tool for out-of-scope codes.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.