FreightUtils MCP Server

Chargeable Weight Calculator

chargeable_weight_calculator

Read-onlyIdempotent

Calculate air freight chargeable weight — the greater of actual gross weight and volumetric weight, which is what airlines bill. Volumetric weight (kg) = (L x W x H in cm) / divisor; the IATA-standard divisor is 6,000 (1 CBM = 166.67 kg), while express integrators (DHL, FedEx, UPS) typically use 5,000.

Behavior: deterministic; per-piece volumetric weight is rounded to 2 decimal places before totalling; basis reports which weight governs ("volumetric" = cargo is light for its size, "actual" = dense). Air mode only — sea W/M (1 CBM = 1,000 kg) is covered by consignment_calculator with mode=sea. Missing or non-positive inputs error with the failing parameter named. 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: chargeable_weight_kg, basis, volumetric_weight_kg (total and per piece), gross_weight_kg, cbm, ratio, factor and pieces under result; normalized_input echoes the interpreted inputs and any defaults applied; plus confidence, _source and citation (the FreightUtils v1 response envelope).

Related: cbm_calculator (volume only), consignment_calculator (multi-line, all modes), uld_lookup (the equipment the freight flies in).

Input Schema

TableJSON Schema

Name	Required	Description
`factor`	No	Volumetric divisor (default: 6000)
`pieces`	No	Number of identical pieces (default: 1)
`width_cm`	Yes	Width in centimetres
`height_cm`	Yes	Height in centimetres
`length_cm`	Yes	Length in centimetres
`gross_weight_kg`	Yes	Actual gross weight in kilograms

Output Schema

TableJSON Schema

Name	Required	Description	Default
`ok`	Yes
`result`	Yes
`_source`	Yes
`citation`	Yes
`validity`	No
`warnings`	No
`confidence`	Yes
`blocking_errors`	No
`envelope_version`	Yes
`normalized_input`	No

TDQS

A4.9/5.0

Behavior5/5

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

Beyond the annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false), the description discloses deterministic behavior, rounding to 2 decimals, the meaning of 'basis', error behavior for invalid inputs, and the 429 rate-limit response details. This adds substantial context that annotations alone do not provide.

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 thorough yet well-organized, with the core purpose in the first sentence, followed by behavior, constraints, errors, and related tools. Every sentence adds value, and the structure is front-loaded with the most critical information. No fluff 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 (rounding, divisor variants, error handling, rate limits, output envelope), the description covers all essential aspects. It explains the result fields (including basis, ratio, etc.) and points to the output schema context, making it complete for an agent to invoke and interpret results correctly.

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?

Schema coverage is 100%, so the baseline is 3. The description adds further meaning by explaining the factor parameter as a divisor with IATA vs. express values, and pieces as identical units. It also clarifies rounding behavior that affects interpretation of results. This exceeds baseline without needing to repeat schema descriptions.

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: 'Calculate air freight chargeable weight — the greater of actual gross weight and volumetric weight', and then explicitly differentiates from sibling tools by noting the sea alternative in consignment_calculator and related volume/equipment tools. This is a model of purpose clarity.

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?

It clearly states the intended use (air freight) and explicitly excludes sea freight, pointing to consignment_calculator with mode=sea. It also names related tools (cbm_calculator, uld_lookup) for adjacent needs, providing strong when-to-use vs. when-not-to-use guidance.

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 tools Inspect

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.

Chargeable Weight Calculator

Input Schema

Output Schema

TDQS

Glama MCP Gateway

TDQS

Resources