Skip to main content
Glama
Sign In

container-loading

by io.github.lxxmng
OverviewDiscussionsAdmin

Server Details

Plan optimal container & truck loads: 3D layouts, utilization, centre of gravity, crush checks.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Uptime
99.9% over 79 days
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL
Repository
lxxmng/loadingmcp-mcp
GitHub Stars
1
Server Listing
loadingmcp-mcp
ChatGPT
–
Claude
–

TDQS

A4.3/5.0

Scored across 6 tools

Disambiguation4/5

Each tool has a distinct anchor: plan_load (exact plan), suggest_containers (quick estimate), list_equipment (reference data), import_packing_list (ingest), export_plan (work order), export_dg_paperwork (DG docs). The main overlap is suggest_containers vs plan_load and export_plan vs plan_load, but the descriptions explicitly cross-reference and say which to use when, which mitigates the confusion.

Naming Consistency5/5

All six tools follow a consistent snake_case verb_noun pattern (plan_load, list_equipment, import_packing_list, export_plan, export_dg_paperwork, suggest_containers). No mixed casing or inconsistent verb styles.

Tool Count5/5

Six tools is well within the sweet spot and each covers a distinct stage of the workflow: reference data, planning, estimation, ingest, work-order export, and DG paperwork. No obviously redundant or filler tools for the stated scope.

Completeness4/5

The surface covers the full pipeline: list equipment, estimate, plan, import a packing list, and export both a work order and DG paperwork, with a round-trip mentioned. Minor gaps exist — no way to adjust or override an existing plan (e.g. pin a container, force equipment) or re-plan locked containers, but agents can work around by re-invoking plan_load.

Available Tools

6 tools
export_dg_paperworkAInspect

Draft the dangerous-goods paperwork for a load from its cargo lines: an IMDG 5.4.1 transport-document description per DG line (UN, proper shipping name, class, PG, marine pollutant), the 5.3 placards + marks required, and the 5.4.2 container/vehicle packing-certificate statements. Input is a "loadingmcp.packing-list" document. This is a DRAFT from the curated DGL — it lists the fields a DG-competent person must still complete (flash point, net explosive mass, unverified PSN) and is never signed.

NameRequiredDescriptionDefault
packingListYesA loadingmcp.packing-list document with DG-bearing lines (unNumber/hazmatClass/packingGroup/marinePollutant). See docs/INTEGRATION.md.

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description fully discloses the tool's behavioral traits: it's a draft generator from a curated DGL, lists fields a DG-competent person must complete (flash point, net explosive mass, unverified PSN), and is never signed. This goes beyond a simple action statement and informs the user about limitations and safety-critical caveats.

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 three sentences, front-loaded with the primary purpose, and every sentence is informative (outputs, input, draft caveats). No fluff or repetition; it is appropriately detailed without being verbose.

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 lacking an output schema, the description clearly explains what the tool returns: the specific transport-document description, placards/marks, and packing-certificate statements. It also covers the draft nature and the fields left for human completion, giving a complete picture of the tool's behavior and output.

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?

The schema has 100% coverage for the single parameter packingList, so the baseline is 3. The description adds value by reinforcing that the input is a 'loadingmcp.packing-list' document and explicitly stating the payload is derived 'from its cargo lines,' which helps the agent understand the expected structure despite the opaque schema.

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 specifies a precise action ('Draft the dangerous-goods paperwork') with a clear resource ('for a load from its cargo lines') and enumerates the exact outputs (IMDG 5.4.1 transport-document description, 5.3 placards, 5.4.2 packing-certificate statements). This clearly differentiates it from sibling tools like export_plan or import_packing_list.

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?

The description gives clear context on when to use the tool: it takes a 'loadingmcp.packing-list' document and produces DG paperwork. It doesn't explicitly state when not to use it or name alternatives, but the purpose is specific enough that a user can infer the appropriate scenario.

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

export_planAInspect

Export a load as a machine-readable LOADING WORK ORDER: a numbered stuffing sequence (which SKU, where, in what order and orientation), the securing/bracing action list, a securing shopping list per container (securingBom: straps, airbags, timber, bars, with quantities, specs and the work-order steps each goes to; recommendations to verify with the carrier), the key declarable figures (VGM, axle load, centre of gravity), and an optional per-retailer inbound-packaging check (Amazon FBA / Walmart). Feed it to a WES/TMS, a robotic palletiser, or a printable worker sheet. A real API key packs it with the production PackingSolver optimizer (the same plan plan_load returns for the same cargo); the public demo key uses the offline preview packer; engine in the result says which one ran. This is decision support to MEET published retailer/carrier specs — verify in your own portal; it is not a retailer certification.

NameRequiredDescriptionDefault
modeNoTransport mode for auto right-size (ignored when equipmentCode is given).sea
itemsYesCargo lines to load
retailersNoRetailer inbound-packaging profiles to check the load against.
equipmentCodeNoEquipment code, e.g. 40HC (see list_equipment). Omit to auto right-size.

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries the behavioral disclosure burden and does well: it explains that a real API key uses the production PackingSolver optimizer while the public demo key uses the offline preview packer, and that `engine` in the result reveals which ran. It also warns that output is decision support requiring verification rather than retailer certification. It does not explicitly state that the operation is non-destructive or discuss auth/rate-limit constraints beyond the API-key distinction.

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 front-loaded with the core purpose and contains no obvious filler; every sentence carries operational information. However, the first sentence is very dense and runs long, which makes the definition harder to scan than a more structured list would be.

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?

There is no output schema, so the description must explain return content, and it does: stuffing sequence, securing action list and BOM, VGM/axle-load/centre-of-gravity figures, retailer packaging checks, and the `engine` discriminator. For a complex export tool with no annotations, this is complete enough for an agent to call it and interpret the result.

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 description coverage is already 100%, so the baseline is 3 and the description need only add value beyond the schema. It adds some context for the retailer check ("Amazon FBA / Walmart") and mentions the engine choice, but it does not materially explain `mode`, `equipmentCode`, or the `items` fields beyond what the schema already documents.

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 states a specific verb and artifact: "Export a load as a machine-readable LOADING WORK ORDER", then enumerates exactly what that includes (stuffing sequence, securing actions/BOM, declarable figures, optional retailer checks). It also distinguishes this from plan_load by clarifying that it returns the same plan plan_load produces, so an agent can tell what it is and what it is not.

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?

It gives clear usage context by naming downstream consumers: "Feed it to a WES/TMS, a robotic palletiser, or a printable worker sheet", and it explains the real-API-key vs public-demo-key behavior. It does not explicitly compare itself to export_dg_paperwork or state when to prefer plan_load versus export_plan, so there are no explicit exclusions or alternative-selection rules.

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

import_packing_listAInspect

ERP/TMS on-ramp: take a versioned "loadingmcp.packing-list" document (a WMS/ERP export — cargo lines + equipmentCode) and return a load plan + a container manifest. Parsing is fail-explicit: an invalid document returns the exact per-line issues, never a silently-dropped row. Pairs with plan_load's output for a full round-trip.

NameRequiredDescriptionDefault
packingListYesA loadingmcp.packing-list document: { format: "loadingmcp.packing-list", formatVersion, equipmentCode, jurisdiction?, lines: [...] }. See docs/INTEGRATION.md.

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries the burden and does well by disclosing fail-explicit behavior ('returns the exact per-line issues, never a silently-dropped row') and the return payload (load plan + container manifest). It doesn't cover side effects or permissions, but for an import/parse operation this is reasonably transparent.

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?

Two sentences, front-loaded with the core purpose, and every clause adds value. No repetition of schema or annotations.

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?

The tool has one nested parameter and no output schema, so the description compensates by stating the output ('load plan + container manifest') and the failure mode. It could state more about the output structure or prerequisites, but it's sufficient for an agent to use the tool correctly.

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 description coverage is 100%, so the schema already documents the packingList object thoroughly. The description adds contextual flavor ('WMS/ERP export' and versioned) but does not significantly expand upon the schema's parameter definitions.

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 clearly states the tool's function: take a versioned 'loadingmcp.packing-list' document and return a load plan and container manifest. The verb 'take' and resource are explicit, and it distinguishes itself from siblings by being the 'ERP/TMS on-ramp'.

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?

It provides clear context for when to use ('ERP/TMS on-ramp') and explicitly references sibling tool plan_load for a full round-trip. However, it doesn't explicitly state when not to use it or alternative scenarios.

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

list_equipmentAInspect

List the standard container, truck, ULD and pallet types LoadingMCP can plan loads into, with internal dimensions (mm) and max payload (kg).

NameRequiredDescriptionDefault
categoryNoOptional category filter

TDQS

A4/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It states what the tool lists but does not explicitly mention read-only behavior, absence of side effects, or any limitations. For a simple list operation, this is acceptable but minimal; it could be improved by adding 'does not modify any data' or similar.

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 a single, front-loaded sentence with no fluff. It efficiently communicates what the tool does and what it returns, earning a perfect score for conciseness.

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?

The description covers the tool's purpose and output content (dimensions and payload), which is sufficient for a simple list tool with one optional parameter and no output schema. It could mention that omitting category returns all types, but the schema already implies the filter is optional, so the description is adequately complete.

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%: the only parameter 'category' is fully described with an enum and 'Optional category filter'. The description adds no extra meaning beyond what the schema already provides, so the baseline score of 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?

The description clearly states the verb 'List' and the specific resource (standard container, truck, ULD and pallet types) along with the output content (internal dimensions in mm and max payload in kg). This distinguishes it from sibling tools like suggest_containers or plan_load, which have different purposes.

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?

The phrase 'LoadingMCP can plan loads into' gives useful context: this tool lists the equipment types supported for load planning. However, it does not explicitly state when to use this tool versus alternatives or when not to use it. The context is clear but lacks direct comparisons with sibling tools.

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

plan_loadAInspect

Compute a 3D load plan for cargo into a container or truck: containers used, utilization (volume & payload %), centre of gravity, crush-protection violations, and a securing checklist (round cargo that rolls, soft cargo that slumps). Cargo type drives realism — drums/pipes hex-nest, big bags/sacks load on top and are never crushed. Omit equipmentCode to auto right-size to the cheapest container that fits. A real API key runs the production PackingSolver optimizer; the public demo key uses the offline preview packer.

NameRequiredDescriptionDefault
vgmNoSOLAS Verified Gross Mass declaration (else a tare+cargo estimate is reported)
modeNoTransport mode — scopes auto right-size to usable equipment (sea→containers, road→trucks, air→ULDs). Ignored when equipmentCode is given.sea
itemsYesCargo lines to load
topUpNoAlso return `topUp`: for each cargo line, how many MORE units still fit in the same containers with every unit placed and the load still ready (e.g. "+6 of SKU A, fill 82%"). Takes longer, since it re-plans the load per line.
freightNoFreight cost per unit: split the ocean freight for this load (rate per container x containers used) across the cargo lines, per line and per unit, so it can go into product cost. Uses the indicative market rate for the lane (20GP/40GP/40HC, real API key) or your ratePerContainer. Indicative, not a quote. No rate = freight.available false with a reason.
massLimitsNoAustralian mass tier (default general). hml = HVNL Higher Mass Limits for AU (tri-axle 22.5 t, 6-axle combination 45.5 t; needs an HML route, road-friendly suspension and mass accreditation) or the NT road-friendly-suspension limits for AU-NT. Ignored elsewhere.
jurisdictionNoRoad jurisdiction for the axle / gross-weight compliance check (default EU). Set CN for China GB 1589 drayage limits, AU for Australian HVNL general mass limits (NSW, Vic, Qld, SA, Tas, ACT), AU-WA for Western Australia, AU-NT for the Northern Territory. Australian jurisdictions also secure to the HVNL Sch 7 loading performance standards.
vesselMotionNoIMO CSS Annex 13 vessel motion + stowage position. When set, the sea leg uses the position-dependent DYNAMIC acceleration field (a container on deck forward sees a far harsher case than one low amidships) instead of the flat sea-area coefficient.
equipmentCodeNoEquipment code, e.g. 40HC (see list_equipment). Omit to auto right-size.
sequenceStopsNoDelivery-stop sequencing: with ≥2 distinct deliveryStop values, zone the load nose→doors in reverse delivery order.
vehicleTareKgNoYour road vehicle tare in kg (container: prime mover + chassis/skeletal; truck: the truck). Replaces the nominal tare in the gross check (AU default 14,100 kg, elsewhere 11,600 kg for a container combination).
complyingSteerAxleNoAU only: the prime mover is an HVNL complying steer axle vehicle (6.5 t steer, 44 t combination). Default false.

TDQS

A4.1/5.0
Behavior4/5

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

No annotations, so the description carries the full burden — and it discloses real behavioral traits: cargo `type` changes packing physics (hex-nesting vs never-crushed top loads), and critically that a real API key runs the production PackingSolver while the demo key silently falls back to an offline preview packer (results differ). It does not mention cost/latency beyond 'takes longer' for topUp, nor limits on item counts.

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-loaded with the output inventory, then behavioral notes, in roughly five dense sentences with no filler. Slightly overloaded with stacked parentheticals ('drums/pipes hex-nest, big bags/sacks load on top'), but every sentence carries information an agent needs.

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 12-param, deeply nested tool with no output schema and no annotations, the description covers the return surface (containers, utilization, CoG, violations, checklist) and the two behavioral traps (auto right-size, demo vs production solver). The many domain-specific params (vgm, vesselMotion, freight, massLimits) are left entirely to the schema, which is acceptable given 100% coverage.

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 description coverage is 100%, so the schema already documents all 12 parameters including nested vgm/vesselMotion/freight. The description adds only marginal semantics beyond that (the equipmentCode omission behavior and the realism effect of `type`), and says nothing about vgm, jurisdiction, massLimits, or vesselMotion. 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?

Specific verb+resource ('Compute a 3D load plan for cargo into a container or truck') followed by a concrete enumeration of what the plan contains: containers used, utilization, centre of gravity, crush violations, securing checklist. An agent can distinguish this from export_plan or suggest_containers without opening schemas.

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?

Gives actionable routing guidance for the key parameter choice ('Omit equipmentCode to auto right-size to the cheapest container that fits') and points to list_equipment for codes. It does not state when to prefer this over suggest_containers (pre-flight sizing) or export_plan (downstream paperwork), so no explicit exclusions.

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

suggest_containersAInspect

Given total cargo volume (m³) and weight (kg), suggest how many of which container to use — a quick volume/weight estimate. For an exact, dimension-aware plan with utilization, CoG and securing, use plan_load (which can also auto right-size).

NameRequiredDescriptionDefault
volumeM3YesTotal cargo volume in cubic metres
weightKgYesTotal cargo weight in kilograms

TDQS

A4.5/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full burden. It discloses that the tool provides a 'quick volume/weight estimate', implying approximate results, and points to plan_load for exact calculations. It does not disclose potential edge cases or output format details, but the core behavioral trait (approximation) is transparent.

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?

Two compact sentences, the first explains the purpose and inputs, the second provides an alternative. No wasted words, extremely efficient.

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 low complexity (two simple numeric inputs), the description fully explains its purpose, usage context, and alternative. It does not need to explain return values in detail because the output's nature ('suggest how many of which container') is clearly implied. The absence of annotations and output schema does not leave major gaps.

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% with clear descriptions for both parameters (volume in cubic metres, weight in kilograms). The description restates the same units but adds no new meaning or constraints beyond the schema, so baseline 3 is appropriate.

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 clearly states the tool's function: given volume and weight, it suggests container types and counts. It distinguishes itself from plan_load by explicitly noting this is a quick estimate, while plan_load is exact and dimension-aware.

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 explicitly states when to use this tool ('quick volume/weight estimate') and when to use the alternative plan_load for exact, dimension-aware planning. This is a clear usage guideline with a named alternative.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 2 tool updates
    • Changedexport_plan1 field changed
      • addedInput schema / properties / items / items / properties / thisSideUp
        Added value: +{
+  "default": false,
+  "description": "Must stay upright — restricts the packer to upright orientations",
+  "type": "boolean"
+}
    • Changedplan_load7 fields changed
      • addedInput schema / properties / complyingSteerAxle
        Added value: +{
+  "description": "AU only: the prime mover is an HVNL complying steer axle vehicle (6.5 t steer, 44 t combination). Default false.",
+  "type": "boolean"
+}
      • addedInput schema / properties / freight
        Added value: +{
+  "description": "Freight cost per unit: split the ocean freight for this load (rate per container x containers used) across the cargo lines, per line and per unit, so it can go into product cost. Uses the indicative market rate for the lane (20GP/40GP/40HC, real API key) or your ratePerContainer. Indicative, not a quote. No rate = freight.available false with a reason.",
+  "properties": {
+    "basis": {
+      "description": "Split by cargo volume (default), weight, or chargeable (the larger of the two shares per line).",
+      "enum": [
+        "volume",
+        "weight",
+        "chargeable"
+      ],
+      "type": "string"
+    },
+    "currency": {
+      "description": "ISO 4217 code. Labels ratePerContainer (default USD); with a market rate it must match the lane currency (no conversion).",
+      "type": "string"
+    },
+    "destination": {
+      "description": "Port of discharge, UN/LOCODE (e.g. AUMEL). Needed for a market rate.",
+      "type": "string"
+    },
+    "origin": {
+      "description": "Port of loading, UN/LOCODE (e.g. CNSHA). Needed for a market rate.",
+      "type": "string"
+    },
+    "ratePerContainer": {
+      "description": "Your own rate per container. When given, no market rate is looked up.",
+      "exclusiveMinimum": 0,
+      "type": "number"
+    }
+  },
+  "type": "object"
+}
      • changedInput schema / properties / jurisdiction / description
        Previous value: -"Road jurisdiction for the axle / gross-weight compliance check (default EU). Set CN for China GB 1589 drayage limits."New value: +"Road jurisdiction for the axle / gross-weight compliance check (default EU). Set CN for China GB 1589 drayage limits, AU for Australian HVNL general mass limits (NSW, Vic, Qld, SA, Tas, ACT), AU-WA for Western Australia, AU-NT for the Northern Territory. Australian jurisdictions also secure to the HVNL Sch 7 loading performance standards."
      • changedInput schema / properties / jurisdiction / enum
        Previous value: -[
-  "EU",
-  "US",
-  "CN"
-]New value: +[
+  "EU",
+  "US",
+  "CN",
+  "AU",
+  "AU-WA",
+  "AU-NT"
+]
      • addedInput schema / properties / massLimits
        Added value: +{
+  "description": "Australian mass tier (default general). hml = HVNL Higher Mass Limits for AU (tri-axle 22.5 t, 6-axle combination 45.5 t; needs an HML route, road-friendly suspension and mass accreditation) or the NT road-friendly-suspension limits for AU-NT. Ignored elsewhere.",
+  "enum": [
+    "general",
+    "hml"
+  ],
+  "type": "string"
+}
      • addedInput schema / properties / topUp
        Added value: +{
+  "description": "Also return `topUp`: for each cargo line, how many MORE units still fit in the same containers with every unit placed and the load still ready (e.g. \"+6 of SKU A, fill 82%\"). Takes longer, since it re-plans the load per line.",
+  "type": "boolean"
+}
      • addedInput schema / properties / vehicleTareKg
        Added value: +{
+  "description": "Your road vehicle tare in kg (container: prime mover + chassis/skeletal; truck: the truck). Replaces the nominal tare in the gross check (AU default 14,100 kg, elsewhere 11,600 kg for a container combination).",
+  "exclusiveMinimum": 0,
+  "type": "number"
+}
  2. 6 tool updates
    • Addedexport_dg_paperwork
    • Changedexport_plan4 fields changed
      • removedInput schema / additionalProperties
        Removed value: -false
      • removedInput schema / properties / items / items / additionalProperties
        Removed value: -false
      • addedInput schema / properties / items / items / properties / quantity / maximum
        Added value: +9007199254740991
      • addedInput schema / properties / items / items / properties / unNumber
        Added value: +{
+  "description": "UN number (e.g. \"UN1263\") — derives the IMDG class/PG/segregation/stowage/EmS from the DGL.",
+  "type": "string"
+}
    • Addedimport_packing_list
    • Changedlist_equipment1 field changed
      • removedInput schema / additionalProperties
        Removed value: -false
    • Changedplan_load14 fields changed
      • removedInput schema / additionalProperties
        Removed value: -false
      • removedInput schema / properties / items / items / additionalProperties
        Removed value: -false
      • addedInput schema / properties / items / items / properties / compatibilityGroup
        Added value: +{
+  "description": "Class-1 explosives compatibility group (A–S).",
+  "type": "string"
+}
      • addedInput schema / properties / items / items / properties / deliveryStop / maximum
        Added value: +9007199254740991
      • addedInput schema / properties / items / items / properties / limitedQuantity
        Added value: +{
+  "description": "Shipped as a limited quantity (IMDG 3.4) — exempt from most segregation except vs class 1/7.",
+  "type": "boolean"
+}
      • addedInput schema / properties / items / items / properties / marinePollutant
        Added value: +{
+  "description": "Marine pollutant (IMDG 2.10 / MARPOL Annex III). Derived from the DGL.",
+  "type": "boolean"
+}
      • addedInput schema / properties / items / items / properties / packingGroup
        Added value: +{
+  "description": "IMDG packing group. Derived from the UN number when unNumber is set.",
+  "enum": [
+    "I",
+    "II",
+    "III"
+  ],
+  "type": "string"
+}
      • addedInput schema / properties / items / items / properties / quantity / maximum
        Added value: +9007199254740991
      • addedInput schema / properties / items / items / properties / segregateFromGroups
        Added value: +{
+  "description": "IMDG segregation groups to keep this substance away from (its DGL column-16b provisions).",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
      • addedInput schema / properties / items / items / properties / segregationGroups
        Added value: +{
+  "description": "IMDG 2.7.2.5 segregation groups this substance belongs to.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
      • addedInput schema / properties / items / items / properties / subsidiaryHazards
        Added value: +{
+  "description": "IMDG subsidiary hazard classes, e.g. [\"6.1\", \"8\"].",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
      • addedInput schema / properties / items / items / properties / unNumber
        Added value: +{
+  "description": "UN number, e.g. \"UN1263\" or \"1263\". When set, the engine DERIVES the IMDG class, packing group, subsidiary risks, marine-pollutant status, segregation groups, stowage category and EmS from the curated Dangerous Goods List — no need to hand-enter each. Explicit DG fields override the derived ones.",
+  "type": "string"
+}
      • addedInput schema / properties / vesselMotion
        Added value: +{
+  "description": "IMO CSS Annex 13 vessel motion + stowage position. When set, the sea leg uses the position-dependent DYNAMIC acceleration field (a container on deck forward sees a far harsher case than one low amidships) instead of the flat sea-area coefficient.",
+  "properties": {
+    "bGmFactor": {
+      "description": "Explicit IMO CSS Annex 13 B/GM correction factor (fallback when bOverGm absent).",
+      "exclusiveMinimum": 0,
+      "type": "number"
+    },
+    "bOverGm": {
+      "description": "Beam / metacentric-height ratio B/GM; derives the Annex 13 transverse B/GM correction.",
+      "exclusiveMinimum": 0,
+      "type": "number"
+    },
+    "lengthFraction": {
+      "description": "Longitudinal stowage position as a fraction of ship length from the aft perpendicular (0=aft, 1=fore).",
+      "maximum": 1,
+      "minimum": 0,
+      "type": "number"
+    },
+    "lengthM": {
+      "description": "Ship length between perpendiculars (m); with speedKn, derives the Annex 13 length/speed correction (50–300 m).",
+      "exclusiveMinimum": 0,
+      "type": "number"
+    },
+    "lengthSpeedFactor": {
+      "description": "Explicit IMO CSS Annex 13 length/speed correction factor (fallback when lengthM/speedKn absent).",
+      "exclusiveMinimum": 0,
+      "type": "number"
+    },
+    "speedKn": {
+      "description": "Service speed (kn); pairs with lengthM.",
+      "exclusiveMinimum": 0,
+      "type": "number"
+    },
+    "stowageZone": {
+      "description": "Vertical stowage zone.",
+      "enum": [
+        "onDeckHigh",
+        "onDeckLow",
+        "tweendeck",
+        "lowerHold"
+      ],
+      "type": "string"
+    }
+  },
+  "required": [
+    "lengthFraction",
+    "stowageZone"
+  ],
+  "type": "object"
+}
      • removedInput schema / properties / vgm / additionalProperties
        Removed value: -false
    • Changedsuggest_containers1 field changed
      • removedInput schema / additionalProperties
        Removed value: -false
  3. 1 tool update
    • Changedplan_load5 fields changed
      • addedInput schema / properties / items / items / properties / bulky
        Added value: +{
+  "default": false,
+  "description": "Bulky/awkward — never takes a load on top and needs handling clearance",
+  "type": "boolean"
+}
      • addedInput schema / properties / items / items / properties / deliveryStop
        Added value: +{
+  "description": "Multi-drop delivery-stop order (1 = first delivered, loaded last at the doors). ≥2 distinct stops + sequenceStops zones the load nose→doors.",
+  "exclusiveMinimum": 0,
+  "type": "integer"
+}
      • addedInput schema / properties / items / items / properties / thisSideUp
        Added value: +{
+  "default": false,
+  "description": "Must stay upright — restricts the packer to upright orientations",
+  "type": "boolean"
+}
      • addedInput schema / properties / jurisdiction
        Added value: +{
+  "description": "Road jurisdiction for the axle / gross-weight compliance check (default EU). Set CN for China GB 1589 drayage limits.",
+  "enum": [
+    "EU",
+    "US",
+    "CN"
+  ],
+  "type": "string"
+}
      • addedInput schema / properties / sequenceStops
        Added value: +{
+  "default": false,
+  "description": "Delivery-stop sequencing: with ≥2 distinct deliveryStop values, zone the load nose→doors in reverse delivery order.",
+  "type": "boolean"
+}
  4. 4 tool updates
    • First observedexport_plan
    • First observedlist_equipment
    • First observedplan_load
    • First observedsuggest_containers

Related MCP Connectors

Related MCP Servers

  • 3dpacking-mcp

    OnurGumus
    A
    license
    A
    quality
    B
    maintenance
    Enables AI assistants to plan container and truck loads from plain-English shipment descriptions, returning fitted containers, utilization, non-fitting items, and interactive 3D load plans.
    1
    114 npm
    MIT

  • hansatic-mcp

    1aleksa
    A
    license
    A
    quality
    D
    maintenance
    Enables AI agents to pack trucks and shipping containers by generating validated 3D load plans with metrics like LDM, linear feet, and pallet positions through the Hansatic packing API.
    3
    7 npm
    MIT

  • Load Planner MCP

    bayraak
    A
    license
    A
    quality
    B
    maintenance
    Enables optimal freight-mode selection (air, sea-LCL, full container) by solving 3D bin-packing, cost optimization, and delivery-risk analysis behind two tools: solve for deterministic planning and explain for hallucination-proof natural-language narration of results.
    2
    MIT
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources