Skip to main content
Glama

FreightUtils MCP Server

by io.github.SoapyRED

UK Duty & VAT Calculator

uk_duty_calculator
Read-onlyIdempotent

Estimate UK import duty and VAT for a commodity code using the LIVE GOV.UK Trade Tariff — rates are fetched per request, not from a static table. The CIF value is composed from customs_value + freight_cost + insurance_cost; duty = CIF x the duty rate for the origin country; VAT (typically 20%) applies on the duty-inclusive value.

Provide commodity_code (6-10 digits), origin_country (ISO-2) and customs_value in GBP; freight_cost, insurance_cost and incoterm are optional refinements.

Behavior: live lookup plus deterministic arithmetic on the returned rate; an unknown or non-declarable commodity code errors with HMRC's message (a 6-digit code may need extending to its 8/10-digit declarable line); origin-dependent measures the tariff cannot resolve automatically surface in warnings. 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: commodity_code and description, origin country, cif_value, duty_rate (+ percent), duty_amount, vat_rate, vat_amount, total_import_taxes, total_landed_cost and warnings under result; validity.as_of marks the live-rate timestamp; plus confidence, _source and citation (the FreightUtils v1 response envelope).

Limitations: an estimate, not a customs ruling — excise, quotas, anti-dumping measures, reliefs and origin-proof requirements can change the outcome; confirm with a customs broker or HMRC before relying on it.

Related: hs_code_lookup (find the 6-digit code first), incoterms_lookup (who actually pays these costs).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
incotermNoIncoterm basis
freight_costNoFreight cost in GBP (default 0)
customs_valueYesCustoms value in GBP
commodity_codeYesUK tariff commodity code (6-10 digits)
insurance_costNoInsurance cost in GBP (default 0)
origin_countryYesISO 2-letter country of origin (e.g. "CN", "US")

Output Schema

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

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the readOnlyHint/idempotentHint annotations, the description discloses live fetch behavior, deterministic arithmetic, HMRC error messages, origin-dependent warning surfacing, rate limiting details (429 retry_after_seconds and Retry-After header), and response envelope properties like validity.as_of and _source. 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?

The description is densely informative but well-structured: purpose, formula, inputs, behavior, returns, limitations, related tools. Every sentence adds functional value, and key information is front-loaded in the first sentence. No filler or repetition.

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?

Given the tool's complexity, the description covers all essential aspects: live data source, calculation logic, required and optional inputs, error/rate-limit behaviors, output structure, limitations, and related tools. The output schema and annotations further enrich context, but the description is fully self-sufficient.

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?

While schema coverage is 100%, the description adds critical semantic relationships: it defines CIF as customs_value + freight_cost + insurance_cost and explains how duty and VAT are calculated from these components. This goes beyond the individual parameter descriptions and clarifies how parameters interact.

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 and resource: 'Estimate UK import duty and VAT for a commodity code using the LIVE GOV.UK Trade Tariff'. It clearly distinguishes itself from siblings by emphasizing live rates fetched per request and explicitly relating to hs_code_lookup and incoterms_lookup for different steps.

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?

Provides explicit usage context: required vs optional parameters, formula for CIF, error scenarios, rate limits with actionable retry guidance, and alternatives like get_subscribe_link for higher limits or hs_code_lookup to find the code first. Limitations and when-not-to-use are clearly stated.

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