Plan a Container Load from ChatGPT or Claude: Load Planning for AI Agents
By Kubova Team

Large language models are great at language and weak at geometry. Ask one to fit 1,300 cartons into a 40-foot container and it will guess. But give that same assistant a packing tool it can call, and it becomes genuinely useful: it gathers your cargo, hands the numbers to an engine that does the real 3D math, and shows you a load plan you can act on — all inside the chat. This is what makes Kubova different from a static calculator: the same engine is available through a REST API and a Model Context Protocol (MCP) server, so your AI agent can plan loads directly.
Why load planning is a perfect job for an AI agent
Container load planning sits in an awkward spot for most teams. It is too fiddly to do well by hand, the inputs already live in an order or a spreadsheet, and the output — “does this fit in one container, and how?” — is exactly the kind of question people now ask an assistant in plain language. Three properties make it a natural fit for automation:
- The inputs are structured. Cartons have dimensions, quantities and weights. An agent can read them from an email, a PO or an ERP record and pass them straight through.
- The answer is deterministic and verifiable. Unlike open-ended advice, a load plan is a concrete artifact: a count, a fill rate, a 3D layout. It can be checked.
- The result drives a decision. One container or two? Which container type? Re-quote the customer? The plan feeds the next action immediately.
How it works: prompt → tool call → 3D plan
The pattern is the same whether the assistant lives in a chat window or inside your own software. There are three steps.
- 1The assistant gathers cargo + containerFrom your message (or an order it already has access to) it extracts each product’s carton size, quantity and weight, and the target container.
- 2It calls the packing toolInstead of guessing, the assistant invokes the packing tool — over the REST API, or as an MCP tool call — passing the structured cargo and container.
- 3It returns a real planThe engine places every carton in 3D, respects the container’s real inner size, door and payload limit, and returns the placed count, the fill rate, the total weight, a 3D layout and a shareable PDF. The assistant summarizes it in the conversation.
You: “I have 800 cartons of 60×40×30 cm at 12 kg and 500 of 50×50×50 cm at 9 kg. Does it fit in one 40-foot High Cube?”
→ the assistant calls the packing tool with those two cargo lines and the 40 HC container…
Assistant: “Yes — all 1,300 cartons fit in one 40 HC at ~91% volume use, ~18.5 t total (under the payload limit). Here is the 3D plan and a PDF you can send to your forwarder.”
Three things teams automate with it
Connecting it: REST API and MCP
There are two ways to give an assistant the packing tool. Pick based on where the assistant runs.
1. REST API — for your own software and agents
If you are building the agent (an ERP step, a website bot, a custom assistant), call the packing endpoint directly and render the result. A request carries your cargo lines and the container; the response carries the placed plan.
POST /api/v1/pack
Authorization: Bearer <your-api-key>
{
"cargos": [
{ "name": "Carton A", "lengthCm": 60, "widthCm": 40,
"heightCm": 30, "quantity": 800, "weightKg": 12 },
{ "name": "Carton B", "lengthCm": 50, "widthCm": 50,
"heightCm": 50, "quantity": 500, "weightKg": 9 }
],
"containers": ["40hc"]
}
→ placed counts, fill rate, total weight, 3D placementsSee the full request and response schema in the API docs.
2. MCP server — for assistants like Claude, ChatGPT and Cursor
The Model Context Protocol lets an assistant discover and call tools through a standard interface. Point an MCP-compatible client at the Kubova MCP server and the assistant gains a packing tool (and a report tool) it can invoke on its own — no bespoke integration per client.
// MCP client config (conceptual)
{
"mcpServers": {
"kubova": {
"command": "npx",
"args": ["kubova-mcp"],
"env": { "KUBOVA_API_KEY": "<your-api-key>" }
}
}
}
// the assistant can now call: pack_containers, generate_reportSetup details are in the MCP guide. Both paths use the same engine, so a plan from the API and a plan from MCP are identical.
What the agent needs to give good results
A plan is only as good as its inputs. From building and running this engine, three things separate a useful result from a misleading one:
- Real weights, not just sizes. On dense cargo, the payload limit is hit before the container is full. Without weights, a volume-only answer over-promises.
- Outer carton dimensions. Use the shipping carton, including any protrusion — not the product’s nominal size.
- Rotation and stacking rules. Telling the engine what may turn or stack (and what must not) changes the achievable fit, especially for mixed loads.
The honest part: a plan you can actually load
Automation only helps if the number is real. Kubova never overflows container dimensions to make a fill rate look better, and every plan respects real inner sizes and weight limits. So when an assistant tells your customer “it fits in one container,” that answer survives contact with the warehouse — which is the whole point of letting an agent send it.
Give your AI agent a packing tool
REST API and MCP server are available on the Pro plan. Start free, no card required.
Related reading
- Open the 3D container loading calculator — the same engine, in the browser.
- API reference and MCP setup guide.
Frequently asked questions
Can ChatGPT or Claude actually plan a container load?
Not on their own — a language model cannot compute a valid 3D packing plan from reasoning alone. But when the assistant can call a packing tool through an API or an MCP server, it can hand off the cargo and container details, receive a real plan back (counts, fill rate, weight, a 3D layout and a PDF), and present it in the conversation. The assistant orchestrates; the packing engine does the math.
What is an MCP server and why does it matter for logistics?
The Model Context Protocol (MCP) is an open standard that lets AI assistants call external tools in a consistent way. A logistics MCP server exposes packing as a tool the assistant can invoke, so the same load-planning capability works across MCP-compatible clients without custom glue code for each one.
What information does the AI need to produce a usable load plan?
For each product: outer carton dimensions (length, width, height), quantity, and unit weight — plus the container type or its inner dimensions and payload limit. Optional but valuable: whether items may be rotated or stacked, and whether they go onto pallets. With those inputs the engine returns a physically valid plan; without weights it cannot warn you when weight, not volume, is the real limit.
Is this just a CBM (volume) estimate?
No. A CBM estimate divides total cargo volume by container volume and ignores door size, stacking, orientation and weight. A tool-backed plan places each carton in 3D, respects real container and weight limits, and never overflows the container to inflate the numbers — so the count it returns is one you can actually load.
Where does AI-driven planning still need a human?
The engine optimizes geometry and weight. It does not know cargo fragility, load-securing and bracing requirements, dangerous-goods segregation, customs rules, or carrier-specific constraints. Treat the plan as a fast, accurate first draft that a person reviews before loading.
Who: Written and reviewed by the Kubova team, who build and operate the packing engine described here.
How: Drafted with AI assistance for research and structure; the technical claims, examples and product details are owned and verified by the team.
Why: To help logistics and engineering teams decide whether to let an AI agent plan their loads — not to chase a keyword. Published 2026-06-08.