3dpacking-mcp
This server plans how a shipment fits into containers, trucks, or pallets using a real 3D bin-packing solver.
Describe cargo in plain English: quantities, dimensions, weights, and constraints (fragile, non-tiltable, max stack height, preferred container type).
Get back which containers/trucks are needed, how full each is (volume used), items that didn't fit, and counts of empty gaps.
Receive a link to an interactive 3D load plan (drag, zoom, color-coded by piece type).
Choose solver speed (fast/normal/thorough) and stability (75–100) for stacking rules.
Handles mixed pallets, non-standard dimensions, weight limits, and optimal container mixes.
Works via hosted endpoint (with OAuth or API key) or local npm package.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@3dpacking-mcpPack 50 boxes of 60x40x30 cm into a 20ft container"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
3DPACK.ING MCP server
Container and truck load planning for AI assistants. Describe a shipment in plain English; get back the containers it fits in, how full each one is, what did not fit, and a link to an interactive 3D load plan.
Backed by the 3DPACK.ING solver — the same one behind the web planner. Asked "will 500 cartons fit in a 40-foot", an assistant without this will do arithmetic on volumes, which ignores stacking rules, orientation and weight limits and overstates what fits by a wide margin on real cargo.
Install
Hosted (no install)
The server runs at https://3dpack.ing/mcp over streamable HTTP. Add the address to
your assistant and sign in with your 3DPACK.ING account when it asks — OAuth, the way
Claude, ChatGPT and Claude Code connect to any service. A free account works, on its
free monthly packs.
Claude (web, desktop): Settings → Connectors → Add custom connector → paste
https://3dpack.ing/mcp and choose sign-in.
ChatGPT (developer mode): add the same address with OAuth.
Claude Code:
claude mcp add --transport http 3dpacking https://3dpack.ing/mcp
# then /mcp → AuthenticateWith an API key instead of signing in. Pass the key and the account it belongs to in the query string:
https://3dpack.ing/mcp?apiKey=your-key&username=your-usernameor keep the key out of the URL: X-API-Key: your-key (or Authorization: Bearer your-key, or X-3dpacking-Api-Key) with ?username=your-username in the URL. Claude's
connector dialog only sends approved header names, so there use x-api-key. The shared
demo account is ?apiKey=test&username=test.
A request with no credentials at all is answered 401 with a pointer to the sign-in
metadata (/.well-known/oauth-protected-resource/mcp), which is what makes a client
show the login.
Local (npm)
Claude Desktop — add to claude_desktop_config.json:
{
"mcpServers": {
"3dpacking": {
"command": "npx",
"args": ["-y", "@3dpacking/mcp-server"]
}
}
}Claude Code:
claude mcp add 3dpacking -- npx -y @3dpacking/mcp-serverIt works immediately, with no account — the first call runs against a shared demo account on the free plan. For your own limits, sign up at https://3dpack.ing/login and add:
{
"mcpServers": {
"3dpacking": {
"command": "npx",
"args": ["-y", "@3dpacking/mcp-server"],
"env": {
"THREEDPACKING_API_KEY": "your-key",
"THREEDPACKING_USERNAME": "your-username"
}
}
}
}Both must be set together — the API rejects a key without a username.
The 3D plan inside Claude
In hosts that support MCP Apps
— Claude on the web and desktop — the answer comes with the load drawn under it in 3D:
drag to turn, scroll to zoom, one colour per kind of piece, a pager for loads that take
several containers. The view is ui://3dpacking/load-plan-<hash>.html (named after its contents, so a changed view is never served from a host cache), drawing the placements
the tool result carries in _meta (so they reach the view, not the model). It needs
your own key: the shared demo account gets the answer and the link, not the
placements. Other hosts get the same answer as text with the link.
Related MCP server: @kubova/mcp
The tool
pack_shipment — one required argument, prompt, describing the cargo in plain
English, and two optional settings: a speed of fast, normal or thorough, and a
stability of 75 to 100.
stability is how much of a box must rest on what is underneath it, as a percentage of
its own footprint. Omit it for 75, the standard rule, which lets a quarter of a box
overhang and packs the most. Raise it for cargo that must not lean — drums, glass,
anything top-heavy — and use 100 when every stacked box has to sit fully supported. It
is the one constraint the prompt cannot carry, because it governs how the solver stacks
rather than what is being shipped, and a higher value fits fewer items.
Things it understands:
Pack 50 boxes of 60x40x30 cm into a 20ft container
Load 100 fragile items 80x60x40cm, max stack 3, into a 40ft high cube
Ship mixed pallets: 10x euro pallets, 15x US pallets, best container mix
Ship 24 pcs 200.3x120.2x100.2 cm (non-tiltable), optimal mix of 40ft and 20ftWhat comes back:
Everything fits: 1 container.
Container 1 (589.3 x 235 x 239 cm internal)
items: 50
of which: 50x Boxes
used: volume 10.9%
5 empty gaps left
Interactive 3D load plan: https://3dpack.ing/app?g=6c4b9488-...Notes on the shaping
The API returns the geometry of every unfilled cuboid in every container, with coordinates. That is what the 3D viewer needs and it is most of the payload on a real shipment. Spending a model's context on the coordinates of empty space, when the link opens a picture of exactly that, is a poor trade — so the summary keeps the count of gaps and drops the geometry. On a small pack that is 791 bytes down to 341; on a large one it is the difference between a usable answer and a flooded context.
A plan limit is not reported as an error. The API returns HTTP 500 for
NotSubscribed, the same status it uses for a solver crash; left alone, an assistant
reads that as "the service is broken" and tells the user to try again later, when what
actually happened is that they asked for a Pro feature. This server sorts the two
apart and relays the offer.
Anything that answers with non-JSON — a proxy, a VPN, a corporate egress allowlist — is reported as a network problem naming what actually replied, rather than as a packing failure. Only one of those is something the user can fix.
Environment
Variable | Purpose |
| Your API key. Falls back to the shared demo account. |
| The account the key belongs to. Required with the key. |
| Override the endpoint — staging, self-hosted, or a stub. |
Development
npm install
npm run smoke # calls the live solver with demo credentials and checks the shapesmoke.js is deliberately not mocked for the live checks. The thing that will break
this package is 3dpack.ing changing the shape of its answer, and no amount of mocking
catches that. Run it before publishing. To exercise the success path without spending
a calculation, point THREEDPACKING_ENDPOINT at a stub.
Licence
MIT.
Available Tools
1 toolpack_shipmentPack a shipment into containers or trucksAInspect
Work out how a shipment fits into shipping containers, trucks or pallets, using a real 3D bin-packing solver. Describe the cargo in plain English -- quantities, dimensions, weights, and any constraints such as fragile, non-tiltable, max stack height or a preferred container type -- and get back which containers are needed, how full each one is, anything that did not fit, and a link to an interactive 3D load plan.
Use this instead of estimating from volume. Volume arithmetic ignores stacking rules, orientation and weight limits, and overstates what fits by a wide margin on real cargo.
| Name | Required | Description | Default |
|---|---|---|---|
| speed | No | How hard the solver should look for a better arrangement. Omit to let it choose. Use 'fast' for a quick feasibility check, 'thorough' when the packing quality matters. | |
| prompt | Yes | The shipment, in plain English. Include quantities, dimensions with units, and weights if known. Examples: "Pack 50 boxes of 60x40x30 cm into a 20ft container"; "Load 100 fragile items 80x60x40cm, max stack 3, into a 40ft high cube"; "Ship mixed pallets: 10x euro pallets, 15x US pallets, best container mix". Truncated at 4000 characters. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility. It discloses the tool uses a solver, returns container needs, fullness, non-fitting items, and an interactive 3D plan. It also warns about volume overestimation, providing valuable behavioral context without contradicting any annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two paragraphs, each serving a distinct purpose. The first explains functionality and output, the second gives usage guidance. Every sentence adds value, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is present, but the description explicitly lists returned information (containers needed, fullness, non-fits, link to 3D plan). It also covers input requirements and constraints, making it contextually complete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 value by explaining how to phrase the 'prompt' parameter (quantities, dimensions, weights, constraints) and provides examples. However, the 'speed' parameter is only described in the schema, not in the main description, so it doesn't fully enhance that parameter's semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Work out how a shipment fits into shipping containers, trucks or pallets' using a 'real 3D bin-packing solver'. It specifies the resource (shipment into containers/trucks/pallets) and the action (work out), making it distinct from generic estimation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool: 'Use this instead of estimating from volume', and contrasts with volume arithmetic. It also provides guidance on input description with examples and constraints, making the usage context clear.
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 tool update
v0.1.0- First observed
pack_shipment
TDQS
Scored across 1 tool
With only one tool, there is no possibility of confusion or overlap. The single tool's purpose is clearly defined in its description.
The tool name 'pack_shipment' follows a clear verb_noun pattern, which is a good convention. However, with only one tool, there is no broader pattern to assess for consistency.
A single tool for a domain like 3D packing feels thin, as users might expect additional capabilities such as container management or multi-shipment optimization. The count is at the low end of the borderline range.
The tool covers the core packing operation comprehensively, but the server lacks auxiliary tools for activities like validating container specifications or comparing alternative packing strategies. This leaves some gaps in the overall workflow.
Maintenance
Related MCP Connectors
Pack cargo into containers & onto pallets; a verifiable 3D loading plan. Free tier + REST API.
Plan optimal container & truck loads: 3D layouts, utilization, centre of gravity, crush checks.
Calculate required trucks or containers, verify shipment fit, and manage Haulista loading plans.
How many identical cartons fit in a container or space, where they go, plus a 3D loading plan.
Related MCP Servers
AlicenseNot gradedqualityFmaintenanceEnables AI agents to manage global shipping operations, including rate comparison, shipment creation, label purchasing, tracking, pickup scheduling, address validation, billing, and analytics, via natural language.57 npmMIT
@kubova/mcpofficial
AlicenseAqualityDmaintenanceLets AI agents pack shipping containers using the Kubova calculator, with tools for container loading and API key verification.415 npmMIT- AlicenseNot gradedqualityCmaintenancePlan optimal container & truck loads: 3D layouts, right-size the container mix, and check utilization, centre of gravity, crush protection and securing across 200+ equipment types.11 npmMIT
- AlicenseNot gradedqualityDmaintenanceConnects AI assistants to CargoEffe for automated cargo loading plan design, offering tools to manage containers, cargo items, and load plans.MIT