3D Bin Packing over MCP: "How Many Pallets Do I Need?"

The Integration Backlog Problem

Here is the pattern we have watched play out repeatedly. A logistics team finds a packing API, runs a trial, and the numbers look good — 12% fewer pallets, say. Everyone agrees. Then the request enters the IT backlog, where it competes with the ERP upgrade, the carrier integration and a security audit. Eighteen months later the sponsor has moved roles and the trial is a memory.

The optimization was never the bottleneck. Getting the data into the optimizer, in the right shape, from wherever it actually lives — that is the bottleneck. And where it actually lives is very often a spreadsheet, a PDF from a customer, or an order confirmation email.

What MCP Changes

The Model Context Protocol is an open standard for connecting AI assistants to external tools. An MCP server advertises what it can do; an assistant like Claude discovers those tools and calls them when a conversation calls for it. Register a server once and it is available in every subsequent conversation.

Packing optimization turns out to be an unusually good fit for this, for four reasons:

• The interface is narrow. Items and bins in, a packing plan out. There is no state to manage and no multi-step workflow to get wrong.
• It is deterministic and read-only. The tool computes and returns. It cannot dispatch a truck, overwrite an order or send an email. That makes it safe to expose to an agent in a way that most enterprise tools are not.
• The messy part is exactly what language models are good at. Turning "24 cases of the 40 × 30 × 25 SKU and 6 of the big ones" into a clean JSON item array is data wrangling, not arithmetic. That is the step that used to require a developer.
• The answer is a number, not a judgement. The optimizer does the part the model would be bad at. The model does the part the optimizer cannot do. Neither is asked to guess.

Our server currently exposes pack_cuboid_items, which is our packToMixedBins engine: pack a set of items into a mix of available bin types, minimising the metric you care about. Every parameter from the REST endpoint is available through the tool.

{
  "method": "tools/call",
  "params": {
    "name": "pack_cuboid_items",
    "arguments": {
      "bins": [
        { "type": "EUR", "width": 1.2, "depth": 0.8, "height": 1.8, "maxWeight": 1000 },
        { "type": "block", "width": 1.2, "depth": 1.0, "height": 1.8, "maxWeight": 1200 }
      ],
      "items": [
        { "id": "SKU-A", "width": 0.4, "depth": 0.3, "height": 0.25, "weight": 6 }
      ]
    }
  }
}

What People Actually Ask It

We expected people to use it as a calculator. What they mostly do is argue with it — and that turns out to be the more valuable use.

"Paste this order. How many pallets?"

The baseline case. A planner drops in a block of order lines copied out of the ERP, the assistant normalises them into items, calls the tool, and reports the pallet count and utilisation. No CSV template, no field mapping, no ticket.

"What if we used the 1200×1000 pallets instead?"

This is the one that changes behaviour. Scenario comparison used to mean a developer writing a script. In a conversation it costs one sentence, so people run five variations instead of none — and occasionally find that a pallet type they never use is the right one for a whole product family.

"The customer wants to add 40 more units. Does it still fit?"

A question with a real deadline attached, usually asked while someone is on the phone. Getting a defensible answer in thirty seconds rather than "I'll check and call you back" is worth more operationally than a percentage point of utilisation.

"Which of last month's shipments were the worst?"

Batch analysis over historical orders, to find the SKUs and box sizes that consistently ship air. This is the analysis that justifies a packaging assortment change, and it is normally a small data project. Here it is an afternoon.

Where MCP Is the Wrong Tool

We would rather say this plainly than have you discover it later. MCP is not how you should run production packing.

• High volume belongs on the REST API. If you are packing ten thousand orders a night, call the endpoint directly. It is faster, cheaper and fully deterministic.
• An assistant in the loop is an assistant in the loop. The optimizer's answer is exact, but the item list the model assembled from your paste is worth a glance before you book freight on it.
• It is not a substitute for integration. It is the thing that lets you prove the value is real, in a week, so the integration is an easy decision instead of a speculative one.

That last point is really the whole argument. Most packing optimization projects die because nobody can demonstrate the benefit before committing to the work. MCP inverts that order.

Getting Connected

The server is authenticated with your existing Packing Optimizer credentials and registers like any other remote MCP server in Claude Desktop, Cursor or Windsurf. Setup is a URL and a credential; there is nothing to install and nothing to host.

Roadmap-wise, the obvious next step is exposing our cylinder packing and bin selection engines the same way. If one of those is what you need, tell us — it moves up the list.

Frequently Asked Questions

What is an MCP server?

The Model Context Protocol is an open standard for connecting AI assistants to external tools and data. An MCP server advertises a set of tools; an assistant discovers them and calls them when a conversation requires it. You register a server once and it is available in every later conversation, in any MCP client — Claude Desktop, Cursor, Windsurf and others.

Why connect packing optimization to an AI assistant at all?

Because the calculation was never the hard part. Getting real order data into the right JSON shape is, and that step normally needs a developer. A language model does it from a pasted spreadsheet block in seconds, then hands the clean input to a deterministic solver. The model does the parsing; the optimizer does the maths. Neither is asked to guess.

Is the packing result generated by the AI?

No, and this distinction matters. The pallet count, utilisation figures and item coordinates all come from the same solver that backs our REST API. The assistant only assembles the request and presents the response. What is worth a second look is the item list the model built from your paste, not the optimization itself.

Can I use MCP for production packing?

For high-volume automated flows, no — call the REST endpoint directly. It is faster, cheaper and has no assistant in the loop. MCP is for exploration, planning, ad-hoc questions and scenario analysis, and for demonstrating the benefit is real before anyone commits engineering time.

Which tools does the Packing Optimizer MCP server expose?

Today, pack_cuboid_items, which is the packToMixedBins engine with every parameter from the REST endpoint available. Cylinder packing and bin selection are the obvious next candidates; if one of those is what you need, tell us and it moves up the list.

Send us a message.

Name

Email

Subject

Message

Close Send message