Skip to main content
Glama
Storno CLI

Storno CLI

Official
by stornoro

nc_codes_search

Read-onlyIdempotent

Search NC/NACE classification codes by code number or description to classify goods for e-Transport declarations. Returns matching codes with their descriptions.

Instructions

Search NC (Combined Nomenclature / NACE) classification codes by code number or description. NC codes are used in e-Transport declarations for goods classification. Returns matching codes with their descriptions.

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum results to return (max 100, default: 30)
searchYesSearch query (NC code number or description text)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.17

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered. The description still contributes the return shape ('matching codes with their descriptions') in the absence of an output schema, but says nothing about result ordering, empty-result behavior, or how partial/fuzzy matching works.

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?

Three short sentences, front-loaded with the verb and resource, followed by domain context and the return shape. No filler, no repetition of schema fields.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter read-only lookup with 100% schema coverage and no output schema, the description covers purpose, domain context, and return content adequately. Only matching behavior (partial vs exact, case sensitivity) is left unaddressed.

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%, so both parameters (search, limit) are already documented in structured data. The description restates the search semantics (code number or description text) but adds no matching-behavior detail beyond the schema, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Search) and resource (NC / Combined Nomenclature / NACE classification codes) plus the lookup keys (code number or description). It also clarifies the domain purpose (e-Transport goods classification). It does not name any sibling (e.g. cpv_codes_search, vat_category_codes_list) that could be confused with it, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The mention that NC codes are used in e-Transport declarations implies when the tool is relevant, but there is no explicit when-to-use/when-not-to-use statement or directive to pick this over cpv_codes_search or the anaf_nomenclator_* tools. Usage is inferable but not guided.

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

Deploy Server

Other Tools