A
licenseNot graded
qualityC
maintenancePlan 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.
16
MIT
kubik-tools
Server Details
Freight calculators (weight, metres, vehicle fit) and authenticated team packing-library tools.
If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Available Tools
10 toolscalculate_chargeable_weightCalculate Chargeable WeightARead-onlyIdempotentInspect
Calculates chargeable (billable) weight -- frachtpflichtiges Gewicht, Frachtgewicht -- for a freight shipment (Stückgut or Sammelgut) from a list of cargo pieces, for one of four transport modes. Answers questions like "wie viel wiegt die Sendung frachtpflichtig" or "was ist das Volumengewicht".
For each mode, chargeable weight is the greater of the actual (scale) weight and the volumetric weight (Volumengewicht), where volumetric weight is derived from total volume using a mode-specific default divisor (overridable via volumetric_divisor):
air (Luftfracht): volume_cm3 / 6000 (IATA standard, 167 kg/m3)
courier: volume_cm3 / 5000 (common express-carrier convention, e.g. DHL/FedEx/UPS)
road: volume_m3 * 333 (simple volumetric "1:3" convention; does not model Lademeter/LDM-based road pricing -- for loading-metre, Stellplätze, or vehicle-fit questions, use calculate_loading_metres and check_truck_fit instead, both on this server)
sea_lcl (Seefracht): volume_m3 * 1000 (W/M -- weight or measurement, 1 revenue tonne per m3)
Worked example: 2 pieces, 60x40x50cm, 45 kg each, air mode -> total actual weight 90 kg, total volume 0.24 m3, volumetric weight 40 kg (240,000 cm3 / 6000) -> chargeable weight 90 kg (actual weight governs, since it exceeds the volumetric weight).
Rounding: air and courier chargeable/volumetric weight round UP to the nearest 0.5 kg (chargeable_weight_raw_kg gives the unrounded value, chargeable_weight_kg the rounded one). Road and sea_lcl are not rounded up, just reported to 1 decimal place.
Edge cases: missing or invalid mode, more than 100 pieces, or any non-positive dimension/weight/quantity returns a clear, structured explanation rather than an error stack -- never a guessed default mode or divisor.
Returns total actual weight, total volume, volumetric weight, raw and rounded chargeable weight, which one governs, the divisor used, and a one-line human-readable summary.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Transport mode (required): one of "air" (Luftfracht), "road", "sea_lcl" (Seefracht), "courier". Selects the default volumetric divisor: air=6000 cm³/kg (IATA), courier=5000 cm³/kg, road=333 kg/m³ (simple volumetric convention — for loading-metre/Lademeter/LDM and vehicle-fit questions, use calculate_loading_metres and check_truck_fit instead, both on this server), sea_lcl=1000 kg/m³ (W/M). | |
| pieces | No | List of cargo pieces (up to 100 line items, required, non-empty). Use quantity to combine identical pieces rather than repeating rows. | |
| volumetric_divisor | No | Optional positive override of the mode's default divisor. For air/courier this is cm³ per kg (divided into volume); for road/sea_lcl this is kg per m³ (multiplied by volume). |
TDQS
A5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and destructiveHint=false, so the agent knows it's a safe read operation. The description adds substantial behavioral context: rounding rules (UP to nearest 0.5 kg for air/courier, no rounding for road/sea_lcl), edge-case handling (returns structured explanation, never guesses defaults), and the output object's contents.
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?
The description is long but every sentence earns its place. It is structured with clear sections: formula, per-mode divisors, a worked example, rounding, edge cases, and returns — making it easy to scan while being exhaustive.
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?
With no output schema, the description fully enumerates return fields (total actual weight, total volume, volumetric weight, raw/rounded chargeable weight, governing dimension, divisor, summary). It also covers edge cases and mode-specific behavior, making the tool safe and predictable to invoke.
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 input schema already has 100% coverage, but the description adds meaning: explains how mode selects divisors, how volumetric_divisor overrides defaults, and provides the actual formulas (e.g., volume_cm3 / 6000). It also explains the distinction between chargeable_weight_raw_kg and chargeable_weight_kg.
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 clearly states a specific verb ('Calculates chargeable (billable) weight') with a defined resource (freight shipment from cargo pieces across four transport modes). It also differentiates from sibling tools by explicitly directing loading-metre questions to calculate_loading_metres/check_truck_fit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool for chargeable weight calculations and provides direct alternatives for loading-metre/vehicle-fit scenarios: 'for loading-metre, Stellplätze, or vehicle-fit questions, use calculate_loading_metres and check_truck_fit instead.' It also names the four applicable modes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calculate_loading_metresCalculate Loading MetresARead-onlyIdempotentInspect
Calculates loading metres (Lademeter, LDM) -- the floor-space unit (Ladefläche) that governs European road freight -- for a list of cargo pieces, plus the equivalent number of pallet places (Palettenstellplätze, Stellplätze). Answers questions like "wie viele Lademeter" or "wieviel Platz brauche ich im Lkw".
Units: length_cm and width_cm (Länge/Breite in cm) per piece. weight_kg_per_piece (Gewicht in kg) is optional. Formula: LDM = sum(length_cm x width_cm x quantity) / reference_deck_width_cm / 100. Height is irrelevant here -- LDM is a floor-footprint metric, not a volume one (for volumetric/chargeable weight, use calculate_chargeable_weight instead).
Reference width: Lademeter (LDM) is always computed at the fixed 240cm (2.4m) reference lane -- this is a commercial road-freight convention, not a DIN/EN/ISO/VDI standard, and does not vary by vehicle. If vehicle_id names one of the loadable vehicle profiles (e.g. "semi_136" = Sattelzug 13,6 m, "rigid_75" = 7,5-Tonner), the response additionally reports deck_length_m: how much of that specific vehicle's own deck length the cargo occupies -- a different, vehicle-specific quantity, not the LDM figure. Pallet-place equivalents are also computed at the 240cm reference lane.
Worked example: 8 Europaletten/EUR-Paletten (120cm x 80cm) at the standard 240cm width = (120808)/240/100 = 3.2 LDM, equivalent to 8 Palettenstellplätze (one Europalette occupies 0.4 LDM at this width). An Industriepalette (120x100cm) occupies more floor space per unit: 0.5 LDM at the same width.
Edge cases: an unknown vehicle_id returns the list of available vehicles instead of guessing -- it never silently picks one. If any piece omits weight_kg_per_piece, total_weight_kg is returned as null rather than an incomplete partial sum. Maximum 100 piece lines (use quantity to combine identical pieces).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| pieces | No | List of cargo pieces (up to 100 line items, required, non-empty). Use quantity to combine identical pieces rather than repeating rows. | |
| vehicle_id | No | Optional vehicle profile id (e.g. "semi_136" = Sattelzug 13,6 m, "rigid_75" = 7,5-Tonner). Does not change the LDM calculation (always the fixed 240cm reference lane) -- adds deck_length_m, how much of that vehicle's own deck length the cargo occupies. If given but not recognized, the response lists every available vehicle instead of guessing. |
TDQS
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even with annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds rich behavioral context: unknown vehicle_id returns a list instead of guessing, missing weight yields null for total_weight_kg, max 100 piece lines, and the fixed 240cm reference width. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with a clear opening sentence, but it is quite long and repeats some vehicle_id behavior already present in the schema. Every sentence adds value, though the length could be slightly reduced without losing information.
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 absence of an output schema, the description thoroughly covers all relevant return values (LDM, pallet places, deck_length_m, total_weight_kg) and edge cases. It also includes the formula, units, and a worked example, making it complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds meaningful semantics beyond it: the formula, worked examples, and optionality/behavior of weight and vehicle_id. While the schema already documents the fields, the description reinforces how values are used in the calculation.
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 clearly states the tool calculates loading metres (LDM) and pallet-place equivalents, with specific verb, resource, and scope. It also explicitly differentiates from calculate_chargeable_weight, making it distinct from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use the tool (floor-space questions, not volumetric weight) and names the alternative tool for volumetric/chargeable weight. Also explains when vehicle_id is relevant (to get deck_length_m).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_truck_fitCheck Truck FitARead-onlyIdempotentInspect
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| pieces | No | List 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_id | No | Vehicle 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. |
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.
create_article_profileCreate Article ProfileAInspect
Creates a new article in your team's kubik.tools Library -- team-scoped from creation, visible to the whole team immediately (not a personal draft).
Two-step by design, never a silent write: call once WITHOUT confirm to get a preview of exactly what would be created (including a check for an existing article that looks like a likely duplicate); call again with confirm=true and the preview_id from the first response to actually create it. A confirmed creation can be undone within 15 minutes via undo_change -- after that, edit or delete it directly in the app.
On the confirm call, only api_key, confirm, and preview_id are actually read -- every other field is required/optional per the schema for shape-consistency but ignored if resupplied, since the values captured during the preview call are what gets created; to change any of them, call again without confirm for a fresh preview.
Do not use this to log a real packing observation for an article that already exists -- use log_pack_observation instead; this tool only creates the article record itself, never packing data. Do not skip the unconfirmed preview call even if you are confident there is no duplicate -- the duplicate check only runs on that first call, and confirm=true without a fresh preview_id will be rejected.
Required: name, supplier. Optional: article_number, hs_code (exactly 8 digits if given), description_de, description_en.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Article name, e.g. 'Rotor hub casting'. Required. | |
| api_key | Yes | Your team's kubik.tools MCP API key (kubik_mcp_...). Required. | |
| confirm | No | Set true, with preview_id, to actually create the article after reviewing the preview. Omit or false for a dry-run preview only. | |
| hs_code | No | HS/tariff code, exactly 8 digits. Format-only check -- not verified against a real tariff database. | |
| supplier | Yes | Supplier name. Required. | |
| preview_id | No | The preview_id returned by the first (unconfirmed) call. Required when confirm=true. | |
| article_number | No | Supplier's own article/SKU number, if known. | |
| description_de | No | ||
| description_en | No |
TDQS
A4.9/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide negative hints (not readOnly, not idempotent, not destructive), so description carries full burden. It discloses the two-step workflow, that the tool is never a silent write, that parameters are ignored on the confirm call except api_key/confirm/preview_id, that the duplicate check only runs on the first call, and that creation is team-visible immediately. This is rich, non-obvious behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-organized, front-loading the core purpose and then explaining the two-step design, parameter behavior, and exclusions. Each paragraph earns its place, though the final required/optional list somewhat duplicates schema information. Slightly verbose but justified by the tool's complexity.
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?
Despite having no output schema, the description conveys the preview/confirm response flow, duplicate-check behavior, undo timeframe, and team-scoped visibility. It fully addresses the tool's complexity, including the subtle behavior that only preview_id and confirm matter on the second call, leaving no ambiguity about how to invoke it correctly.
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?
Schema covers most parameter descriptions, but the description adds critical interplay semantics: only api_key, confirm, and preview_id are read on the confirm call, all other fields are ignored if resupplied, and preview_id is required when confirm=true. It also clarifies hs_code must be exactly 8 digits and reiterates required/optional fields. This goes well beyond schema descriptions.
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 'Creates a new article in your team's kubik.tools Library', using a specific verb and resource, and immediately clarifies team-scoping. It distinguishes itself from sibling tools by explicitly stating it only creates article records, never packing data (unlike log_pack_observation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: 'Do not use this to log a real packing observation... use log_pack_observation instead'. Also explains the mandatory two-step preview/confirm flow and warns against skipping the unconfirmed call, plus mentions undo_change for reversal within 15 minutes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_pack_observationsList Pack ObservationsARead-onlyIdempotentInspect
Lists the real, observed consolidation packs logged against a consolidation group in your team's Library -- "these articles, at these quantities, actually packed onto N pallets at these dims/weight," the same ground-truth data resolve_quantities/resolve_prepack_quantities and the app's own resolve flow learn from (PRINCIPLES.md P-13).
Use this to see what's already been logged for a group before deciding whether a new observation (log_pack_observation) is needed, or to review a group's own observation history. Each observation's member_quantities are resolved to article_number/name for readability -- never a bare internal id.
Returns an empty observations array (not an error) for a group that exists but has no observations logged yet -- a real, valid state, not a failure.
Requires an MCP API key (Authorization: Bearer ) issued for a kubik.tools team. Looks the consolidation group up by its own name text within that team's own Library -- never across teams.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | Yes | Your team's kubik.tools MCP API key (kubik_mcp_...). Required. | |
| group_name_query | Yes | Free-text search over the consolidation group's own name, e.g. 'pallet mix A' or 'mixed cartons'. |
TDQS
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds valuable behavioral context: member_quantities are resolved to article_number/name for readability, an empty observations array is returned for groups with no logs (not an error), and the operation requires an MCP API key and operates only within the team's Library. No contradiction with 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?
The description is detailed yet tightly packed. Each sentence serves a purpose: purpose, usage, readability, empty-array behavior, and auth/scope. It is front-loaded with the core action and no fluff. Despite its length, it is efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list operation with no output schema, the description covers the key aspects: what is returned (observations with resolved article info), the edge case (empty array), and scope. It also ties the data to the broader resolve flow. Minor omission: it doesn't enumerate all fields in each observation, but the mention of member_quantities resolution provides enough context. Would benefit from an explicit note on ordering or pagination, but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameter descriptions already exist. The description adds team-scoping context for group_name_query ('within that team's own Library -- never across teams'), which clarifies its semantics beyond the schema's generic 'Free-text search.' This incremental information raises the score above the baseline 3.
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 clearly states the tool's function: 'Lists the real, observed consolidation packs logged against a consolidation group in your team's Library.' It specifies the action (lists), resource (consolidation packs), and scope (logged against a consolidation group). It also differentiates from siblings by referencing the ground-truth data that resolve_quantities/resolve_prepack_quantities learn from and explicitly names log_pack_observation as the counterpart for adding new observations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: 'Use this to see what's already been logged for a group before deciding whether a new observation (log_pack_observation) is needed, or to review a group's own observation history.' It names the alternative tool, clarifies the context, and covers edge behavior (empty array is valid). No ambiguity remains about when to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
log_pack_observationLog Pack ObservationAInspect
Logs a real, observed consolidation pack -- "these articles, at these quantities, actually packed onto N pallets at these dims/weight" -- against an existing consolidation group in your team's Library. This is ground truth: it becomes a new data point resolve_quantities and the app's own resolve flow learn from (PRINCIPLES.md P-13).
Two-step by design: call once WITHOUT confirm to preview exactly what would be logged; call again with confirm=true and the preview_id to actually log it. A confirmed log can be undone within 15 minutes via undo_change -- after that it's permanent (append-only ground truth, by design -- see PRINCIPLES.md P-17/P-18 for why).
On the confirm call, only api_key, confirm, and preview_id are actually read -- every other field is required by the schema for shape-consistency but ignored if resupplied, since the values captured during the preview call are what gets logged; to change any of them, call again without confirm for a fresh preview.
Do not use this for a single article's own packing history outside a consolidation group -- that data comes from the app's own data entry, not this tool. Do not use this to correct a mistaken past observation after the 15-minute undo window -- log a new, correct observation instead; past ones are never edited. Requires an EXISTING consolidation_groups id -- this tool cannot create a new consolidation group.
Requires an existing consolidation_groups id (from the app's Consolidation Groups screen) and each member article's number (resolved to its profile automatically).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | Yes | Your team's kubik.tools MCP API key (kubik_mcp_...). Required. | |
| confirm | No | Set true, with preview_id, to actually log the observation after reviewing the preview. Omit or false for a dry-run preview only. | |
| width_cm | Yes | ||
| height_cm | Yes | ||
| length_cm | Yes | ||
| weight_kg | Yes | Total gross weight, in kg. | |
| preview_id | No | The preview_id returned by the first (unconfirmed) call. Required when confirm=true. | |
| pallet_count | Yes | Number of pallets this pack used. | |
| member_quantities | Yes | The articles and quantities actually packed together, e.g. [{article_number: 'MLB1001', qty: 3}]. | |
| consolidation_group_id | Yes | The id of an existing consolidation group in your team's Library. Required. |
TDQS
A4.9/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false/neutral, so the description carries the full burden of behavioral disclosure. It richly describes the two-step design, the confirm-call field-ignoring behavior, the 15-minute undo window, append-only permanence, and the fact that it cannot create a new group. No contradictions with 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?
The description is long but every sentence earns its place: it starts with the core function, then the workflow, then field semantics, exclusions, and prerequisites. It is well-structured and information-dense without waste, appropriate for a complex tool with 10 parameters and a two-step flow.
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?
For a tool with 10 parameters, no output schema, and non-trivial behavioral rules, the description covers purpose, flow, field roles, undo/persistence behavior, exclusions, and prerequisites. The only minor gap is the exact preview response shape, but the description indicates what the preview is for and returns preview_id, which is sufficient for the agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 70%, and the description adds meaningful context by explaining which fields are read on confirm (api_key, confirm, preview_id), showing an example for member_quantities, and clarifying preview_id's role. The three dimension params (length_cm, width_cm, height_cm) lack individual descriptions, but their names and units are self-explanatory and the description refers to 'dims/weight', so the meaning is adequately conveyed.
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 specific verb+resource: 'Logs a real, observed consolidation pack...against an existing consolidation group in your team's Library.' It clearly distinguishes this from sibling tools by stating it produces ground-truth data for resolve_quantities and explicitly says 'Do not use this for a single article's own packing history' and 'Do not use this to correct a mistaken past observation,' making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use context ('real, observed consolidation pack'), prerequisites (existing consolidation_groups id, article numbers), and when-not-to-use exclusions (single-article history, post-undo corrections). It also explains the two-step preview/confirm flow and references alternatives like undo_change, providing complete usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
resolve_prepack_quantitiesResolve Prepack QuantitiesAInspect
Resolves an ordered quantity of a CLASS of goods into concrete prepack units (boxes/cartons), using that class's own logged prepack table -- a class-level lookup (e.g. "small metal fittings"), not a single article. Use resolve_quantities instead when you have a specific article number/name.
Check resolution_status first: "resolved" means units/tier are a real answer, safe to use directly. "not_found" means no prepack table matched the search text, or the matched table has no threshold rules logged -- units/tier are both null. Prepack tables never produce "ambiguous" results (unlike resolve_quantities) -- a table either resolves or it doesn't, there is no packaging-family choice to make.
When resolution_status is "resolved", tier is one of: "observed" (an exact match against a real logged threshold), "estimated" (interpolated between two real logged thresholds), or "verify" (extrapolated beyond the highest -- or below the lowest -- threshold ever actually logged for this table; still returns a real number, but flagged as needing a human's eyes before it's trusted).
Requires an MCP API key (Authorization: Bearer ) issued for a kubik.tools team. Looks the prepack table up by its own article_class text within that team's own Library -- never across teams.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | Yes | Your team's kubik.tools MCP API key (kubik_mcp_...). Required. | |
| quantity | Yes | The ordered quantity to resolve, in whole units of the class. Must be a positive number. | |
| article_class_query | Yes | Free-text search over the prepack table's own article_class label, e.g. 'small metal fittings' or 'cable ties'. |
TDQS
A5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are minimal (readOnlyHint: false, etc.) but the description adds substantial behavioral context: requires API key, scoped to team's library, explains the meaning of resolution_status and each tier (observed/estimated/verify), and explicitly states that prepack tables never produce ambiguous results. This far exceeds what annotations alone provide and fully discloses 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Though lengthy, every sentence serves a purpose: introduces core function, contrasts with alternative, explains statuses and tiers, and details auth/scoping. Well-structured into logical paragraphs with no repetition. The density of useful information justifies the length.
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 there is no output schema, the description does an excellent job explaining what the tool returns (units/tier when resolved, nulls when not_found) and what each tier means. It also covers edge cases (verify for extrapolation) and team scoping, making it fully 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.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the description still adds meaningful semantics by explaining that article_class_query is a free-text search on the prepack table's label, quantity must be positive, and api_key is required with format. It also clarifies the class-level lookup, which enriches what the schema states.
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?
States a specific verb ('resolves') and resource ('ordered quantity of a CLASS of goods into concrete prepack units'), and clearly distinguishes from the sibling tool 'resolve_quantities' by specifying class-level vs article-level. No ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool vs resolve_quantities, instructs to check resolution_status first, and explains how to interpret each status. Also clarifies that this tool never returns ambiguous results, contrasting with the alternative. This is textbook usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
resolve_quantitiesResolve Article QuantitiesAInspect
Resolves an ordered quantity of a Library article into concrete packed units (boxes/pallets), using that article's own logged packing history -- never a generic guess.
Check resolution_status first: "resolved" means units/tier are a real answer, safe to use directly. "ambiguous" means the article has more than one viable packaging family (e.g. logged both as pallets and as crates) with meaningfully different pack counts -- units and tier are both null, and alternatives lists every viable option with no default among them. When resolution_status is "ambiguous", do not select an alternative autonomously -- present the options to the user and ask which packaging family they mean; do not guess based on which one appears first. "not_found" means the article has no packed-form data logged at all -- there is nothing to resolve, alternatives is absent, and units/tier are null. needs_confirmation (boolean) is kept only for backward compatibility with callers written before resolution_status existed -- new integrations should check resolution_status.
When resolution_status is "resolved", tier is one of: "observed" (an exact match against a real logged pack), "estimated" (interpolated between two real logged points), or "verify" (extrapolated beyond the highest -- or below the lowest -- quantity ever actually logged for this article; still returns a real number, but flagged as needing a human's eyes before it's trusted).
Does not resolve prepack-table or consolidation-group quantities -- those use the same tier engine but a different lookup key (a table/group id, not a free-text article search) and are not covered by this tool.
Requires an MCP API key (Authorization: Bearer ) issued for a kubik.tools team. Looks the article up by article number or name within that team's own Library -- never across teams.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | Yes | Your team's kubik.tools MCP API key (kubik_mcp_...). Required. | |
| quantity | Yes | The ordered quantity to resolve, in whole units of the article. Must be a positive number. | |
| article_query | Yes | The article number or name to search for in the Library, e.g. 'MLB1001' or 'rim holder'. |
TDQS
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains in detail the resolution_status values ('resolved', 'ambiguous', 'not_found') and what each means, including how to handle 'ambiguous' (present options to the user, not guess). It also describes tier values ('observed', 'estimated', 'verify') with their implications and notes the backward-compatibility needs_confirmation field, providing rich behavioral context beyond the sparse annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured, with clear sections for purpose, status handling, tiers, exclusions, and auth. Every sentence adds necessary behavioral detail, though the backward-compatibility note could be trimmed; it is not as tight as a two-sentence description but remains efficient for the complexity.
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 there is no output schema and only three parameters, the description effectively explains all return semantics (units, tier, alternatives, needs_confirmation) and when they apply. It also covers exclusion cases and authentication, making it highly complete for a tool with this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for all three parameters, so the schema carries the load. The description adds minor context about the api_key (team-scoped Bearer token) and article_query (looks up by number or name within the team's Library), but largely repeats schema information, so it does not significantly raise the baseline.
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 clearly states a specific verb and resource: 'Resolves an ordered quantity of a Library article into concrete packed units (boxes/pallets)' and explicitly distinguishes from a sibling concern by excluding prepack-table and consolidation-group quantities. It provides a concrete outcome and avoids any tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance: check resolution_status first, do not autonomously choose when ambiguous, and clarifies that prepack/consolidation quantities use a different tool. It also states the API key requirement and team scoping, which are actionable usage prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_article_profilesSearch Article ProfilesARead-onlyIdempotentInspect
Searches your team's kubik.tools Library for article profiles by article number or name (case-insensitive substring match). Returns up to 10 matches: id, article_number, name, supplier.
Leave query empty (or a single common substring) to browse -- this returns whatever matches, sorted however the underlying table naturally orders (no ranking beyond "matched or not"), never a full unfiltered dump beyond the 10-result cap. Use resolve_quantities once you've found the article you want to resolve a quantity against; use this tool first to find its exact article_number/id if you only have a rough description.
Requires an MCP API key (Authorization: Bearer ) issued for a kubik.tools team. Only ever returns that team's own Library -- never across teams.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Article number or name substring to search for, e.g. 'MLB1001' or 'rim holder'. Leave empty to browse the first 10 articles in the Library. | |
| api_key | Yes | Your team's kubik.tools MCP API key (kubik_mcp_...). Required. |
TDQS
A5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotent, non-destructive, but the description adds valuable behavioral context: no ranking ('no ranking beyond matched or not'), a hard 10-result cap, requirement of an MCP API key (Authorization: Bearer), and scoping to the team's own Library (never cross-team). This exceeds annotation coverage and provides operational expectations.
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?
The description is well-structured and concise. It opens with the core purpose, then adds usage nuances and auth requirements in a succinct second paragraph. Every sentence contributes value, with no redundant or filler content.
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 moderate complexity and no output schema, the description fully covers what is returned (id, article_number, name, supplier), the 10-result limit, the lack of ranking, the auth requirement, and the cross-team exclusion. It also positions the tool within the workflow, making it complete for an agent to decide when and how to invoke it.
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?
Schema coverage is 100%, but the description enriches both parameters. For query, it explains the substring match behavior and the 'leave empty to browse' use case. For api_key, it specifies the format ('kubik_mcp_...') and that it is required. This adds meaning beyond the schema's basic property descriptions.
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 clearly states the verb 'Searches' and the resource 'your team's kubik.tools Library for article profiles', specifying the search criteria (article number or name, case-insensitive substring match) and the output fields (id, article_number, name, supplier). It also differentiates from siblings by explicitly naming resolve_quantities as the next step, making the tool's role distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: 'Use resolve_quantities once you've found the article you want to resolve a quantity against; use this tool first to find its exact article_number/id if you only have a rough description.' Also explains the browse behavior with empty query. The tool's context is clear, with no ambiguity about its place among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
undo_changeUndo Recent ChangeADestructiveInspect
Undoes a create_article_profile or log_pack_observation call, but only within 15 minutes of when it was confirmed, and only if nothing else now depends on it.
For article_profiles: refuses if any packed_forms, consolidation_group_members, or edit-history rows now reference the article (edit it or delete it manually in the app instead of undoing).
For consolidation_pack_observations: append-only ground truth past the 15-minute window, by design (PRINCIPLES.md P-17/P-18) -- undo only exists for a mistake caught immediately after logging it, never as a general edit/delete capability.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| table | Yes | Which kind of change to undo, matching the undo_token's origin (create_article_profile -> article_profiles, log_pack_observation -> consolidation_pack_observations). | |
| api_key | Yes | Your team's kubik.tools MCP API key (kubik_mcp_...). Required. | |
| undo_token | Yes | The undo_token returned by the original confirmed create_article_profile or log_pack_observation call. |
TDQS
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although annotations already mark destructiveHint=true, the description adds essential behavioral detail: refusal conditions for dependent article_profiles, the append-only nature of consolidation_pack_observations, and the design rationale referencing PRINCIPLES.md. No contradiction with 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?
The description is appropriately sized for a tool with significant constraints. The first sentence front-loads the core action, and the subsequent paragraphs efficiently explain exceptions and design rationale without filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is destructive, has no output schema, and handles two distinct table types, the description covers behavior, constraints, refusal cases, and rationale well. It doesn't describe the return value/success response, but the rest is complete enough for an agent to use safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes all three parameters thoroughly (100% coverage), so the description adds limited extra parameter meaning. It does add a useful mapping between the 'table' enum and the originating call, but this is modest beyond the schema.
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 clearly states it 'Undoes a create_article_profile or log_pack_observation call', naming specific verbs and resources. It also distinguishes this tool from its siblings by emphasizing that it is only for undo, not for general editing/deleting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit usage boundaries: only within 15 minutes of confirmation, only if nothing depends on it, and never as a general edit/delete capability. It also names the alternative path: 'edit it or delete it manually in the app instead of undoing'.
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. Dates show when Glama detected each change.
4 tool updates
- Changed
check_truck_fit3 fields changed- added
Input schema / properties / pieces / items / properties / fragileAdded 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" +} - added
Input schema / properties / pieces / items / properties / height_cmAdded 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" +} - added
Input schema / properties / pieces / items / properties / rotatableAdded 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" +}
- Added
list_pack_observations - Added
resolve_prepack_quantities - Added
search_article_profiles
1 tool update
- Changed
calculate_loading_metres1 field changed- changed
Input schema / properties / vehicle_id / descriptionPrevious value: -"Optional vehicle profile id (e.g. \"semi_136\" = Sattelzug 13,6 m, \"rigid_75\" = 7,5-Tonner) to use that vehicle's real deck width instead of the 240cm standard. If given but not recognized, the response lists every available vehicle instead of guessing."New value: +"Optional vehicle profile id (e.g. \"semi_136\" = Sattelzug 13,6 m, \"rigid_75\" = 7,5-Tonner). Does not change the LDM calculation (always the fixed 240cm reference lane) -- adds deck_length_m, how much of that vehicle's own deck length the cargo occupies. If given but not recognized, the response lists every available vehicle instead of guessing."
4 tool updates
- Added
create_article_profile - Added
log_pack_observation - Added
resolve_quantities - Added
undo_change
4 tool updates
- Removed
create_article_profile - Removed
log_pack_observation - Removed
resolve_quantities - Removed
undo_change
7 tool updates
- Changed
calculate_chargeable_weight5 fields changed- changed
Input schema / properties / mode / descriptionPrevious value: -"Transport mode (required): one of \"air\", \"road\", \"sea_lcl\", \"courier\". Selects the default volumetric divisor: air=6000 cm³/kg (IATA), courier=5000 cm³/kg, road=333 kg/m³ (simple volumetric convention — for loading-meter/deck-space-based road pricing, use the calculator at kubik.tools instead), sea_lcl=1000 kg/m³ (W/M)."New value: +"Transport mode (required): one of \"air\" (Luftfracht), \"road\", \"sea_lcl\" (Seefracht), \"courier\". Selects the default volumetric divisor: air=6000 cm³/kg (IATA), courier=5000 cm³/kg, road=333 kg/m³ (simple volumetric convention — for loading-metre/Lademeter/LDM and vehicle-fit questions, use calculate_loading_metres and check_truck_fit instead, both on this server), sea_lcl=1000 kg/m³ (W/M)." - changed
Input schema / properties / pieces / items / properties / height_cm / descriptionPrevious value: -"Height of one piece, in centimeters. Must be a positive number."New value: +"Height of one piece, in centimeters (Höhe in cm). Must be a positive number." - changed
Input schema / properties / pieces / items / properties / length_cm / descriptionPrevious value: -"Length of one piece, in centimeters. Must be a positive number."New value: +"Length of one piece, in centimeters (Länge in cm). Must be a positive number." - changed
Input schema / properties / pieces / items / properties / weight_kg_per_piece / descriptionPrevious value: -"Actual (scale) weight of one piece, in kilograms. Must be a positive number."New value: +"Actual (scale) weight of one piece, in kilograms (Gewicht in kg). Must be a positive number." - changed
Input schema / properties / pieces / items / properties / width_cm / descriptionPrevious value: -"Width of one piece, in centimeters. Must be a positive number."New value: +"Width of one piece, in centimeters (Breite in cm). Must be a positive number."
- Added
calculate_loading_metres - Added
check_truck_fit - Added
create_article_profile - Added
log_pack_observation - Added
resolve_quantities - Added
undo_change
1 tool update
- First observed
calculate_chargeable_weight
Frequently Asked Questions
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as
io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such asio.github.acme/serveralso needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at
/.well-known/glama.jsonon the same origin as the connector, then choose Check HTTP challenge.DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Connectors
Dimensional weight, parcel fit, landed cost and freight class. 4 of 6 tools free.
Plan optimal container & truck loads: 3D layouts, utilization, centre of gravity, crush checks.
Pack cargo into containers & onto pallets; a verifiable 3D loading plan. Free tier + REST API.
Truck & trailer load planning from a plain-English shipment: what fits, how full, 3D load plan.
11
Related MCP Servers
- AlicenseAqualityAmaintenanceAI agent access to 11 freight calculation and reference tools — LDM, CBM, chargeable weight, pallet fitting, ADR dangerous goods (2,939 entries), airline codes (6,352), HS codes (6,940), INCOTERMS, container specs, unit converter, and ADR 1.1.3.6 exemption calculator.252914MIT
- AlicenseAqualityBmaintenanceEnables optimal freight-mode selection (air, sea-LCL, full container) by solving 3D bin-packing, cost optimization, and delivery-risk analysis behind two tools: solve for deterministic planning and explain for hallucination-proof natural-language narration of results.2MIT
- FlicenseNot gradedqualityCmaintenanceReal published tariffs for European road freight and moving: quote by m3, kg, pallets or LDM across 560k+ routes. Dated price index, freight glossary, order submission. Live endpoint at https://mcp.fromtocargo.com/mcp (19 tools).-
Try in Browser
Glama MCP Gateway
Add one secure layer between your agents and this server.
TDQS
A4.6/5.0
Disambiguation4/5
Most tools have clearly distinct purposes: the freight calculation tools are separated by volume-weight, floor-space, and vehicle-fit outputs, and the Library tools are split into create, search, list, log, resolve, and undo actions. The only mild ambiguity is between resolve_quantities and resolve_prepack_quantities, and between calculate_loading_metres and check_truck_fit, but the descriptions explicitly steer the agent to the right tool.
Naming Consistency5/5
All tool names follow a consistent verb_object pattern in snake_case: calculate, check, create, search, list, log, resolve, undo. Despite some verbs being semantically close, the naming is predictable and internally consistent.
Tool Count5/5
Ten tools is well-scoped for the freight-and-logistics domain the server covers: three calculation/fit tools and seven article-observation/resolution tools. Each tool earns its place, and the set is neither bloated nor too thin.
Completeness4/5
The core workflow is covered: freight calculations, article profile creation/search, packing observation logging, and quantity resolution. Minor gaps remain in lifecycle management—there is no update/delete for article profiles and no MCP tool for creating/list consolidation groups or prepack tables, which pushes some flows back into the external app.