Skip to main content
Glama

FreightUtils MCP Server

by io.github.SoapyRED

ICS2 Stop-Words Checker

ics2_check
Read-onlyIdempotent

Check a goods description against the official EU ICS2 stop-words list — terms the European Commission deems too vague or generic for an entry summary declaration (ENS) goods-description field (data element 18 05 000 000).

Pass description=. Behavior: deterministic term matching against the in-force EU list; each flagged term carries a note (a standalone stop-word means automatic rejection, an embedded one means make the description more specific); clean=true means no listed term matched — it does NOT guarantee acceptance, and no binary accepted/rejected verdict is given. Rate-limited (anonymous use: 25 requests/day per IP): a 429 error body carries retry_after_seconds and a Retry-After header — back off and retry, or call get_subscribe_link for higher limits.

Returns: the description echo, flagged[] (term + note), clean, caveat and disclaimer under result, plus a _source citing the EU list and legal basis, plus confidence, _source and citation (the FreightUtils v1 response envelope).

Limitations: STRICTLY a reference check — not an ENS filing, not a customs-compliance determination, not legal advice; the EU list is non-exhaustive and updated periodically.

Related: hs_code_lookup (commodity codes — a different field of the ENS), uk_duty_calculator (duty/VAT, unrelated to ENS screening). Use BEFORE filing an ENS — for customs/documentation teams, brokers and agents building filing pipelines.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
descriptionYesThe goods description to check against the EU ICS2 stop-words list.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
okYes
resultYes
_sourceYes
citationYes
validityNo
warningsNo
confidenceYes
blocking_errorsNo
envelope_versionYes
normalized_inputNo

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, and the description adds substantial behavioral detail: deterministic term matching, flagged terms with notes, the meaning of clean, no binary verdict, rate limits, 429 error handling with retry_after_seconds, and periodic list updates. 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but well-structured: purpose, behavior, return format, limitations, and related tools are separated into clear sections. It is front-loaded with the primary function. Though verbose, each sentence earns its place; only minor redundancy exists in describing the return envelope when output schema is present.

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?

Despite having an output schema, the description thoroughly explains return fields, limitations, rate limits, legal disclaimers, and the non-exhaustive nature of the list. It provides complete context for an agent to invoke the tool correctly and interpret results.

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 the schema description already states 'The goods description to check against the EU ICS2 stop-words list.' The description's 'Pass description=<goods description>' is redundant with the schema. No additional parameter semantics are provided beyond what the schema already offers.

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?

The description opens with a specific verb+resource: 'Check a goods description against the official EU ICS2 stop-words list', clearly scoping the tool to a distinct function. It explicitly differentiates from siblings by naming hs_code_lookup and uk_duty_calculator as covering different fields of ENS screening.

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

Usage Guidelines5/5

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

Explicitly states when to use ('Use BEFORE filing an ENS') and what the tool is not for ('not an ENS filing, not a customs-compliance determination, not legal advice'). It also provides alternatives: 'call get_subscribe_link for higher limits' and names hs_code_lookup/uk_duty_calculator for other purposes.

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

All FreightUtils MCP Server toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.3/5.0
Disambiguation3/5

The tools cluster into clear domains and the descriptions are detailed, but there are several overlapping pairs: consignment_calculator vs shipment_summary, cbm_calculator vs unit_converter, and validate vs resolve_reference all have fuzzy boundaries. An agent could plausibly mis-select between the composite calculators or between identifier-handling tools despite the helpful cross-references.

Naming Consistency4/5

Naming is mostly consistent: reference tools use *_lookup, calculation tools use *_calculator, and checks use *_check. Exceptions like validate, resolve_reference, nearest_airport, and shipment_summary break the dominant pattern slightly, but all names are snake_case and generally predictable.

Tool Count3/5

At 25 tools, this sits at the heavy end of the range for an MCP server. The broad freight/logistics scope justifies many of them, but several single-purpose calculators could have been consolidated or grouped, making the surface feel larger and more redundant than necessary.

Completeness4/5

The server covers ADR dangerous-goods rules, multi-modal freight calculations, equipment lookups, identifier validation, customs/trade data, and emissions estimation. Minor gaps exist—no routing/geocoding, no SCAC/BIC coverage, no customs filing—but core freight-reference and calculation workflows are well supported.

Resources