Skip to main content
Glama
Sign In

container-loading

by io.github.lxxmng
OverviewDiscussionsAdmin

export_plan

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.

Input Schema

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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema 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"
+}
  2. Changed4 schema 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"
+}
  3. First observed

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.

All container-loading toolsInspect
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