Click on "Install 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., "@hansatic-mcp Pack 12 pallets into a 13.6m trailer"
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.
Give your AI agent the ability to pack trucks and shipping containers. This MCP server wraps the Hansatic packing API: submit a cargo manifest, get back a physically valid layout — placements with rotation, stacking, fragility, weight and axle constraints respected — plus the freight billing metrics that matter: LDM (loading meters), linear feet, and EUR pallet positions.
"Pack 14 machine crates and 8 EUR pallets into a 13.6m curtainsider" → a validated 3D load plan with 5.25 LDM, in one tool call.
Get an API key (free): hansatic.com → sign in → click your name → API → Generate key. Every account includes 25 free sandbox packs/month — no subscription needed to try it.
Add the server to your MCP client:
Claude Code
claude mcp add hansatic -e HANSATIC_API_KEY=hk_live_... -- npx -y hansatic-mcpClaude Desktop (claude_desktop_config.json)
{
"mcpServers": {
"hansatic": {
"command": "npx",
"args": ["-y", "hansatic-mcp"],
"env": { "HANSATIC_API_KEY": "hk_live_..." }
}
}
}Cursor (.cursor/mcp.json) — same shape as Claude Desktop.
Related MCP server: @kubova/mcp
Tool | What it does |
| Optimize a cargo manifest into a vehicle. Async under the hood; returns the finished layout + metrics in one call (typically 5–30s). Production accounts get a |
| All built-in trucks, trailers and containers with interior dimensions and payload — the valid |
| Poll a job by id (only for very large manifests that outlive the tool timeout). |
Units: metric (mm/kg) by default; pass units: "imperial" for in/lb —
results come back in the same units.
Sandbox vs production: non-enterprise keys sandbox automatically (full
result, nothing persisted). Enterprise keys create a real plan in the
workspace, editable at the returned plan_url.
The engine is validated continuously against real dispatcher layouts — see how the algorithm is measured.
REST API, OpenAPI spec and full docs: hansatic.com/en/docs
MIT licensed. The optimization engine runs server-side at hansatic.com.
Check the status/result of a packing job by id (only needed if pack_cargo timed out on a very large manifest).
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | The job id returned by pack_cargo |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description adds behavioral context (timeout scenario) but lacks details like read-only nature, idempotency, or error handling.
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?
Single, front-loaded sentence with no fluff. Every word earns its place.
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?
Adequate for a simple 1-param tool with no output schema. Tells when to use and what it does, but missing response format details.
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 100%. Description of job_id matches schema exactly, no added semantics beyond indicating it comes from pack_cargo.
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?
Clear verb+resource: 'Check the status/result of a packing job'. Distinguishes from siblings: pack_cargo creates the job, list_vehicles is unrelated.
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 states when to use: 'only needed if pack_cargo timed out on a very large manifest', implying not to use otherwise and linking to sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available trucks, trailers and shipping containers with their interior dimensions (mm) and max payload (kg). Use the returned codes as the "vehicle" argument of pack_cargo.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses what the tool returns (list with dimensions/payload) and how the output is used. For a simple list operation, this is sufficient; no side effects are mentioned but none are expected.
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?
Two sentences, front-loaded with action and resource, zero waste. Every sentence adds value: first states purpose, second provides usage guidance.
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?
Given no parameters and no output schema, the description is complete for a list tool. It explains what is returned and how to use the results. Could optionally mention if the list is exhaustive, but not necessary.
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?
Tool has zero parameters, so baseline is 4 according to rubric. The description adds context about the list content (dimensions and payload), which is beneficial.
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 verb 'List', specifies the resource 'all available trucks, trailers and shipping containers', and details the output attributes (interior dimensions and max payload). It distinguishes itself from siblings by explicitly linking to pack_cargo.
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?
The description explicitly instructs to use the returned codes as the 'vehicle' argument of pack_cargo, providing clear context on when to use this tool (before pack_cargo). It lacks explicit when-not-to-use scenarios, but the guidance is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Optimize how cargo is loaded into a truck, trailer or shipping container. Returns a physically valid layout (placements with x/y/z and rotation, respecting stacking, fragility, weight and axle constraints) plus the freight billing metrics: LDM (loading meters), linear feet, EUR pallet positions and total weight. Submits an async job and waits for the result — typically 5-30 seconds. Use list_vehicles first if you are unsure of the vehicle code.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Plan name (production mode) | |
| items | Yes | The cargo manifest | |
| units | No | How item numbers are read AND returned: mm/kg (default) or in/lb | |
| sandbox | No | Force sandbox mode (nothing persisted). Omit to let the account tier decide: enterprise accounts create a real plan with a shareable link, others sandbox automatically. | |
| vehicle | Yes | Vehicle code, e.g. CURTAINSIDER_136 (13.6m curtainsider) or 40HC (40ft high-cube container). Get valid codes from list_vehicles. | |
| objective | No | Minimize loading meters (default) or billed pallet positions | |
| ldm_limit_m | No | Restrict the load to the first N loading meters (trucks) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool submits an async job and waits 5-30 seconds, mentions sandbox mode for non-persistent testing, and explains the return metrics. It does not contradict any annotations (none exist) and adequately informs about the tool's behavior.
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, with every sentence adding value. It front-loads the primary purpose and immediately follows with key behavioral details and a practical tip. No wasted words.
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?
Given the complexity (7 parameters, nested items, async, no output schema), the description provides a good overview of the layout output and metrics. It covers the async wait time and the prerequisite. While it could detail error handling or the exact return structure, it is sufficient for an agent to understand the tool's role.
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%, but the description adds meaningful context beyond the schema, such as the meaning of output metrics (LDM, linear feet, etc.), units interpretation, and sandbox behavior. This helps the agent understand the purpose of parameters and expected results.
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 optimizes cargo loading, returns a physically valid layout and billing metrics. It is distinct from its siblings (check_job, list_vehicles) which handle job status and vehicle listing respectively.
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?
The description advises using list_vehicles first if unsure about the vehicle code, providing a clear prerequisite. It also mentions the async nature and typical wait time. However, it lacks explicit guidance on when not to use this tool or alternatives beyond the sibling hint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0check_joblist_vehiclespack_cargoScored across 3 tools
Each tool has a clearly distinct purpose: list_vehicles retrieves vehicle options, pack_cargo submits an optimization job, and check_job monitors that job. There is no overlap or ambiguity.
All three tools follow a consistent verb_noun pattern with snake_case: check_job, list_vehicles, pack_cargo. The naming is predictable and clear.
With only 3 tools, the scope is narrow but well-defined. Each tool serves an essential step in the cargo packing workflow without unnecessary extras.
The domain of cargo packing is fully covered: listing available vehicles, computing an optimal pack, and checking on an async job. No obvious gaps are present.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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.
Load planning for containers, trucks and pallets from a plain-English description; 3D plan link.
Plain-English shipment input for freight & logistics: containers your cargo fits, 3D load plan.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/1aleksa/hansatic-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
