Skip to main content
Glama

kubik-tools

by io.github.markopolovic
OverviewAdmin

Check Truck Fit

check_truck_fit
Read-onlyIdempotent

Checks whether a list of cargo pieces fits a named vehicle. Two capacity limits always checked: loading metres (Lademeter, LDM, Stellplätze) and, if weight is given, payload (Zuladung, Nutzlast). When every piece ALSO carries height_cm, a third, stronger check runs too: a real 3D placement simulation (the SAME stacking/shelf-packing engine kubik.tools' own planner uses, not an approximation) -- this becomes the authoritative fits verdict, since it can correctly say "fits" for a load that stacks well even when the raw floor-footprint LDM math alone would have said "doesn't fit". Still not Ladungssicherung (load securing) or axle-load distribution.

Vehicle profiles (vehicle_id -> German name): "semi_136" = Sattelzug/Sattelauflieger 13,6 m (colloquially also "40-Tonner"), "curtain_136" = Planensattel 13,6 m, "flatbed_136" = Pritsche 13,6 m, "rigid_75" = 7,5-Tonner, "midi_12" = 12-Tonner/Koffer-Lkw, "rigid_18" = 18-Tonner, "rigid_26" = 26-Tonner (3-Achser), "drawbar_40" = Hängerzug, "sprinter_l3h2" = Mercedes Sprinter L3H2 (3,5t), "ducato_l4h2" = Fiat Ducato L4H2 (3,5t), "cont_20"/"cont_40"/"cont_40hc" = 20-/40-/40-Fuß-HC-Container. Cargo like a Gitterbox/Rollbehälter is just another piece by footprint -- no separate cargo-type parameter needed.

Units: length_cm/width_cm/height_cm per piece in centimetres (Länge/Breite/Höhe in cm), weight_kg_per_piece in kilograms (Gewicht in kg). height_cm is optional -- omit it and only the LDM/payload check runs; weight_kg_per_piece is optional too -- if omitted, the payload check is honestly skipped, not guessed. rotatable (default true) says whether a piece may be turned 90° on the floor to fit; fragile (default false) marks a piece nothing heavier should stack on top of, unless it's genuinely load-bearing.

Three modes, by what's given: (1) vehicle_id + pieces -> full fit check; if it does NOT fit, the response additionally includes recommended_vehicles -- the smallest fitting alternatives by payload, e.g. cargo that overloads a 7,5-Tonner might fit a 12-Tonner or 18-Tonner instead (suggest, never auto-pick). (2) vehicle_id alone, no pieces -> that vehicle's own payload_kg/max_ldm_m/deck_width_cm, a plain spec lookup (e.g. "wie viele Stellplätze hat ein Standard-Sattelzug" or "maximale Zuladung Sattelzug"). (3) neither given, or pieces given with no vehicle_id -> the full vehicle list, filtered to fitting ones when pieces were given. An unrecognized vehicle_id also returns the full list -- it never assumes which vehicle you mean.

Worked example: 6 Europaletten (120x80cm), 4.8 tonnes total, against vehicle_id "rigid_75" -- loading metres (2.5 LDM) are well within the 6.2m limit, but 4800kg exceeds the 3500kg payload, so fits=false, limiting_constraint="payload", recommended_vehicles lists "midi_12" (12-Tonner) and "rigid_18" (18-Tonner) first -- the smallest vehicles that hold 4.8t.

Edge cases: if no vehicle profile fits the given cargo at all, says so honestly ("exceeds all vehicle profiles") rather than recommending an impossible option. Utilisation percentages are uncapped on purpose (an overloaded plan reads "137%", not a reassuring clamped "100%"). Maximum 100 piece lines.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
piecesNoList of cargo pieces (up to 100 line items), optionally omitted entirely to just look up a vehicle's specs (with vehicle_id) or list all vehicles (without). Use quantity to combine identical pieces rather than repeating rows.
vehicle_idNoVehicle profile id to check against or look up (e.g. "semi_136" = Sattelzug 13,6 m, "rigid_75" = 7,5-Tonner). If omitted or not recognized, the response lists every available vehicle instead of guessing.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed3 schema fields changed
    • addedInput schema / properties / pieces / items / properties / fragile
      Added value: +{
+  "description": "Whether this piece is fragile -- nothing should stack on it unless the item below is genuinely load-bearing (only used by the placement simulation). Defaults to false.",
+  "type": "boolean"
+}
    • addedInput schema / properties / pieces / items / properties / height_cm
      Added value: +{
+  "description": "Height of one piece, in centimeters (Höhe in cm). Optional -- if every piece in the request has it, a real 3D placement simulation runs too, not just the LDM/floor-space formula.",
+  "type": "number"
+}
    • addedInput schema / properties / pieces / items / properties / rotatable
      Added value: +{
+  "description": "Whether this piece may be turned 90° on the floor to fit (only used by the placement simulation, i.e. only when height_cm is given). Defaults to true.",
+  "type": "boolean"
+}
  2. Added

TDQS

A4.8/5.0
Behavior5/5

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

The description discloses far beyond the annotations: it details the two always-run checks (LDM and payload), the condition for the 3D simulation, that it uses the same engine as kubik.tools, and that the simulation's verdict is authoritative. It also reveals edge-case behaviors like uncapped utilisation percentages, the 'exceeds all vehicle profiles' message, the maximum of 100 pieces, and that recommendations are suggestions only. No contradictions with the readOnlyHint or idempotentHint annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Although lengthy, the description is efficiently structured with clear paragraphs for each concern: core checks, mode explanations, units, vehicle list, worked example, and edge cases. Each sentence adds necessary detail, and the use of line breaks and bullet-like formatting (e.g., 'Three modes:') enhances readability. No fluff or redundancy.

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?

Given the tool's complexity—multiple modes, optional parameters, simulation behavior, and domain-specific terminology—the description is fully complete. It covers all user intents, error handling (unrecognized vehicle_id), and even provides a worked example and explicit statements about what the tool does not do (load securing, axle loads). The presence of an output schema would have reduced the burden, but as is, nothing logically necessary is left out.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description significantly enriches the parameter documentation. It explains the interplay between fields (e.g., height_cm being required for the 3D simulation), clarifies that weight_kg_per_piece omission skips the payload check, and defines semantics for fragile and rotatable with practical context. The worked example (Europaletten vs rigid_75) demonstrates how parameters interact and what the output will be, adding value well beyond the schema definitions.

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 opens with a precise statement: 'Checks whether a list of cargo pieces fits a named vehicle.' It specifies the resource (cargo pieces and vehicle) and distinguishes this tool from its siblings (e.g., calculate_loading_metres, calculate_chargeable_weight) by clarifying it performs a full fit check, including a 3D simulation when possible, and by explaining what it is not (load securing, axle-load distribution).

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 thoroughly explains when to use the tool in three distinct modes based on input presence (full check, spec lookup, or list all). It gives explicit guidance on behavior when vehicle_id is missing or unknown and clarifies non-goals ('still not Ladungssicherung'). However, it does not explicitly name sibling tools as alternatives, although the intended use is clearly delineated through the modes.

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

All kubik-tools toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources