Skip to main content
Glama

pallet_plan

Compute cases per pallet and pallets per container for any case size, pallet standard, and container type, then compare palletized vs floor-loaded cube utilization and handling trade-offs.

Instructions

Optimize PALLETIZATION across the full chain product → case → pallet → container (distinct from the box→container load optimizer). Give a case (carton) size & weight, a pallet standard (EUR 1200×800, EUR2 1200×1000, US/GMA 48×40, AU 1165) and a container, and it computes: cases per pallet (best layer pattern from both case orientations + pinwheel × layers, capped by the pallet weight AND the container height), pallets per container (floor footprint × single-vs-double-stack under the ceiling, capped by payload), and the % container CUBE UTILISATION. It then contrasts PALLETIZED vs FLOOR-LOADED: floor-loading reclaims the ~12–18% cube a pallet wastes (deck + top-air + footprint rounding) but is ~4× slower to handle and bruises more cargo — the real trade-off, quantified in extra cases and cube points. Pass a total case count for the pallets/containers your shipment needs. Honest (regla 7): INDICATIVE rectangular-packing geometry capped by weight/height — not a stow guarantee; real patterns depend on crush strength, interlocking and overhang. PREMIUM: pay per call with x402 (USDC on Base) or a prepaid key.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
case_length_mmNoCase (carton) length in mm. Optional; default 400.
case_width_mmNoCase width in mm. Optional; default 300.
case_height_mmNoCase height in mm. Optional; default 250.
case_weight_kgNoCase weight in kg. Optional; default 12.
palletNoPallet standard: 'EUR' (1200×800), 'EUR2' (1200×1000), 'US' (48×40), 'AU' (1165). Optional; default EUR.
container_typeNoContainer '20ft'/'40ft'/'40HC'/reefer. Optional; default 40HC.
reeferNoReefer container. Optional; default false.
allow_double_stackNoAllow double-stacking pallets if height permits. Optional; default true.
total_casesNoTotal shipment case count → pallets & containers needed. Optional.
Behavior5/5

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

With no annotations, the description fully discloses behavior: it is indicative (not a stow guarantee), capped by weight/height, and details limitations like crush strength, interlocking, and overhang. It also mentions premium pricing (pay per call). This is highly transparent.

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 dense but not overly verbose; it front-loads the main purpose and then efficiently covers inputs, outputs, comparisons, limitations, and pricing. Every sentence adds value, though slightly long for a tool description.

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?

For a complex tool with 9 optional parameters and no output schema, the description covers purpose, all input semantics, output computation, trade-offs, limitations, and pricing. It is self-contained and fully contextual.

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 descriptions for all parameters. The description adds context on how inputs are used (e.g., 'best layer pattern from both case orientations + pinwheel × layers'), but does not significantly extend the schema's own parameter descriptions. 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 optimizes palletization across the full chain, computes cases per pallet, pallets per container, cube utilization, and contrasts with floor-loaded. It distinguishes itself from a 'box→container load optimizer', likely a sibling tool, making its unique purpose very clear.

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 specifies required inputs (case size, pallet standard, container) and outputs, indicating when to use the tool. It contrasts with floor-loaded and mentions the trade-off, but does not explicitly list alternative tool names or state when not to use it. Still, it provides solid guidance.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Baneado98/freight-pulse'

If you have feedback or need assistance with the MCP directory API, please join our Discord server