Dimensional weight, parcel fit, landed cost and freight class. 4 of 6 tools free.
Scored across 6 tools
Each tool targets a clearly distinct calculation (dim weight billing, density-based freight class, box selection, landed cost, rate table, free-shipping break-even), and the descriptions explicitly cross-reference neighbours with 'Not for X: that is Y' guidance. Even the closest pair (dim_weight vs freight_class) is separated by purpose: carrier billing versus LTL classification.
All six names are lowercase snake_case noun phrases describing the output quantity (dim_weight, landed_cost, rate_card, parcel_fit, freight_class, free_shipping_threshold). No mixing of camelCase, verb styles, or arbitrary abbreviations.
Six tools is well within the sweet spot and each earns its place as a distinct shipping calculation. None feel like filler or thin wrappers around the same computation.
The surface covers the main shipping-maths lifecycle: packaging choice, billable weight, freight class, landed cost, pricing table, and free-shipping threshold. Minor gaps exist for adjacent needs such as accessorial/surcharge handling, multi-currency duty, or carrier rate comparison, but agents can work around these.
Work out whether a parcel bills on its size or its weight. FREE.
Carriers charge the greater of actual weight and dimensional weight, so a light bulky box costs more than the scale suggests. Typical input {"length": 18, "width": 12, "height": 10, "actual_weight": 6} returns {"cubic": 2160.0, "dim_weight": 15.54, "actual_weight": 6.0, "billable_weight": 15.54, "billed_on": "dimensional", "overage": 9.54, "divisor_used": 139.0, "note": "..."}.
Use when deciding whether a smaller box is worth the packing effort, or why an invoice exceeded the scale weight. Not for choosing a box from a list of candidates: that is parcel_fit. Errors: on invalid, missing, or malformed input this tool never raises a protocol error; it returns {"error": ""} (for example {"error": "custom_divisor must be greater than 0 when divisor is 'custom'"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| width | Yes | Second side, same unit as length. Must be greater than 0. | |
| height | Yes | Third side, same unit as length. Must be greater than 0. | |
| length | Yes | Longest side of the packed parcel, in inches (or centimetres when using a metric divisor). Must be greater than 0. | |
| divisor | No | Which published divisor to apply. "ups_daily" is 139 and "ups_retail" is 166 cubic inches per pound, as UPS states them; "usps" is 166; the metric options are cubic centimetres per kilogram. Use "custom" to supply a contracted divisor. | ups_daily |
| actual_weight | Yes | Scale weight in pounds (or kilograms with a metric divisor). Must be greater than 0. | |
| custom_divisor | No | Your contracted divisor, used only when divisor is "custom". Must be greater than 0 in that case. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent/destructive annotations, it discloses the error contract (never raises a protocol error; returns {"error": ...} with an example) and states retry is safe after correction. That error-and-retry semantics is exactly the kind of context annotations cannot convey.
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 opening line is front-loaded and the usage/exclusion follow logically. The full worked input/output JSON is somewhat redundant with the existing output schema and lengthens the text without adding selection value.
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?
For a six-parameter read-only calculator with an output schema, the description covers purpose, alternatives, error behavior, and retry safety. Nothing needed to call it correctly is missing.
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 description coverage is 100% with units, defaults, and the custom_divisor constraint already documented, so the description's parameter contribution is limited to an illustrative example call. That example is mildly useful but adds no semantics the schema lacks.
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?
States a specific computation and its decision purpose ('whether a parcel bills on its size or its weight'), and explicitly names the sibling it is not (parcel_fit). An agent can separate it from rate_card or freight_class without opening any schema.
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?
Gives two concrete use cases ('deciding whether a smaller box is worth the packing effort' and 'why an invoice exceeded the scale weight') plus an explicit exclusion routing to parcel_fit. The when/when-not pair is fully spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find the order value at which free shipping stops costing you money. PREMIUM (license).
Break-even is where the gross margin on the order covers the shipping you absorb. Typical input {"gross_margin_pct": 45, "ship_cost": 7.5, "current_aov": 38, "target_uplift_pct": 15} returns {"break_even": 16.67, "suggested_threshold": 43.7, "above_current_aov_by": 5.7, "rationale": "..."}.
Use when setting or defending a free-shipping bar. Not for what shipping should cost when it is not free: that is rate_card. Errors: on invalid, missing, or malformed input this tool never raises a protocol error; it returns {"error": ""}. Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| ship_cost | Yes | What one shipment actually costs you to send. | |
| current_aov | Yes | Your current average order value. | |
| gross_margin_pct | Yes | Gross margin on a typical order, e.g. 45 for 45%. Must be above 0 and at most 100. | |
| target_uplift_pct | No | How far above current AOV you want the threshold set, to pull baskets up. Default 0, which returns break-even. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description adds genuinely new behavior: it never raises a protocol error, returns an {error: ...} object instead, and is always safe to retry after correcting input. The PREMIUM (license) note also flags an access prerequisite an agent would otherwise only discover at call time.
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?
Front-loaded with the core definition, then example, then usage routing, then error semantics — a sensible order with little waste. The multi-line inline JSON example is slightly bulky but earns its place by demonstrating output fields.
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?
With an output schema present the description needn't document return values, yet it still previews them in the example, and it covers inputs, routing, licensing, and error/retry behavior. Nothing an agent needs before calling is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3; the worked example lifts it by showing how the inputs map to distinct outputs (break_even vs suggested_threshold vs above_current_aov_by) and confirming target_uplift_pct=0 collapses to break-even. It doesn't explain units/edge behavior of target_uplift_pct beyond the default, so not a 5.
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?
States a specific verb+resource ('Find the order value at which free shipping stops costing you money') and immediately operationalizes it as break-even math. It explicitly names the sibling it is not (rate_card) and the condition that separates them, so no schema comparison is needed.
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?
"Use when setting or defending a free-shipping bar" plus "Not for what shipping should cost when it is not free: that is rate_card" gives an explicit when/when-not with a named alternative. It only disambiguates against one of five siblings, leaving dim_weight/freight_class/landed_cost/parcel_fit to inference (though those are far enough apart to be low risk).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Derive a US LTL freight class from density. FREE.
Density in pounds per cubic foot maps to a class on the published NMFC density scale. Typical input {"length": 48, "width": 40, "height": 36, "weight": 400} returns {"cubic_feet": 40.0, "density_pcf": 10.0, "density_class": "100", "caveat": "..."}.
Use for a first estimate before a carrier quote. Not as a final classification: NMFC also weighs stowability, handling and liability, so a carrier can and does reclassify. Errors: on invalid, missing, or malformed input this tool never raises a protocol error; it returns {"error": ""} (for example {"error": "dimensions produce zero volume"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| units | No | "in_lb" for inches and pounds, or "cm_kg" for centimetres and kilograms. Default "in_lb". | in_lb |
| width | Yes | Second side. Must be greater than 0. | |
| height | Yes | Third side, including the pallet. Must be greater than 0. | |
| length | Yes | Longest side of the palletised freight. Must be greater than 0. | |
| weight | Yes | Gross weight including the pallet. Must be greater than 0. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations by disclosing error semantics: invalid input never raises a protocol error and instead returns an {"error": ...} object with a fix hint, plus the caveat field in the response and the retry-safety implication. The read-only/idempotent restatement is redundant with annotations but harmless.
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?
Front-loaded with the core verb and the FREE signal, then the caveat and error contract. Slightly padded by the example output and a sentence restating annotation-provided read-only/idempotent traits, but nothing is materially wasteful.
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?
An output schema exists, yet the description still shows a sample response and flags the caveat field, and it fully covers the failure mode. An agent has everything needed to call this correctly and interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents units, length, width, height and weight. The worked example (48x40x36, 400 lb -> 40 cu ft, 10.0 pcf, class 100) adds concrete meaning by showing how the inputs combine into density, which the schema alone does not convey.
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?
States a specific verb and resource: derive a US LTL freight class from density. The domain is narrow and clearly separable from siblings like dim_weight or rate_card, though no sibling is named explicitly.
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 says when to use it (a first estimate before a carrier quote) and when not to (not as a final classification), and explains why: NMFC also weighs stowability, handling and liability so carriers reclassify. That is a genuine when/when-not pair with rationale.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Total what a unit really costs once freight, duty and fees are in. FREE.
Duty is applied to goods value, tax to goods plus duty plus freight (the common import treatment), and the order is spelled out in the response so you can check it against your own broker's method. Typical input {"unit_cost": 8.5, "quantity": 200, "freight_total": 640, "duty_pct": 6.5, "tax_pct": 0} returns {"goods": 1700.0, "duty": 110.5, "freight": 640.0, "tax": 0.0, "total_landed": 2450.5, "landed_unit_cost": 12.25, ...}.
Use before setting a price on imported stock. Not for the margin that price leaves you: that is the dropship server's margin_check. Errors: on invalid, missing, or malformed input this tool never raises a protocol error; it returns {"error": ""}. Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| tax_pct | No | Import VAT or GST as a percentage of goods plus duty plus freight, e.g. 20. Default 0. | |
| duty_pct | No | Import duty as a percentage of goods value, e.g. 6.5. Default 0. | |
| quantity | No | Units in the shipment. Must be at least 1. Default 1. | |
| unit_cost | Yes | Ex-works cost of one unit in your currency. Must be greater than 0. | |
| other_fees | No | Brokerage, port and handling charges for the shipment. Default 0. | |
| freight_total | No | Total freight and insurance for the whole shipment, not per unit. Default 0. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive and closed-world behavior, so the safety profile is known. The description adds materially beyond that: it calls out that no protocol error is ever raised, describes the error-return shape and how to fix it, confirms retry safety after correction, and states that the calculation order appears in the response for verification.
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?
Purpose and usage context are front-loaded, and the example is compact and informative. A few phrases ("FREE.", the multi-line formatting) add mild noise, but overall it is dense with useful content rather than padded.
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?
An output schema exists, so return values need not be explained, and the description correctly focuses on computation semantics, error behavior and retry safety. For a six-parameter, fully documented calculation tool, nothing an agent needs in order to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description earns above baseline by giving a worked input/output example and explaining the duty and tax bases (duty on goods value; tax on goods plus duty plus freight) in a form that is directly checkable, though the schema already documents those percentage bases.
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 opening sentence states a specific computation (total unit cost including freight, duty and fees), which is clear and actionable. It distinguishes itself from margin_check on the dropship server, but it does not differentiate itself from the shipping-focused sibling tools (rate_card, freight_class, dim_weight, etc.), so it falls short of the sibling-aware 5.
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?
It gives an explicit when-to-use ("Use before setting a price on imported stock") and an explicit when-not plus alternative ("Not for the margin that price leaves you: that is the dropship server's margin_check"). The agent does not need to infer routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pick the smallest box an item actually fits in, allowing for padding. FREE.
Tries every rotation of the item against every box, so an item that only fits diagonally-oriented is still found. Typical input {"item_length": 10, "item_width": 6, "item_height": 4, "box_options": [[12, 9, 4], [14, 10, 6]]} returns {"fits": [{"box": [14, 10, 6], "cubic": 840.0, "slack": [2, 2, 0]}], "best": [14, 10, 6], "rejected": [...]}.
Use when choosing packaging from stock. Not for what the carrier will bill once a box is chosen: that is dim_weight. Errors: on invalid, missing, or malformed input this tool never raises a protocol error; it returns {"error": ""} (for example {"error": "box_options must contain at least one [l, w, h] box"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| padding | No | Cushioning allowance added to every item side before the comparison, in the same unit. Default 1.0; use 0 for a bare fit. | |
| item_width | Yes | Item's second side, same unit. Must be greater than 0. | |
| box_options | Yes | Candidate inner box dimensions, each a list of exactly three positive numbers, e.g. [[12, 9, 4], [14, 10, 6]]. | |
| item_height | Yes | Item's third side, same unit. Must be greater than 0. | |
| item_length | Yes | Item's longest side, in inches. Must be greater than 0. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, yet the description adds real value beyond them: it discloses the brute-force rotation search semantics, the exact error contract (no protocol errors, {"error": ...} payload with a concrete example), and explicit retry safety after correcting input.
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?
Purpose and scope are front-loaded and each block (algorithm, example, routing, error contract) carries distinct information. It is on the long side for a single tool, and the bare 'FREE.' fragment and duplicated read-only/idempotent statement are the only low-value lines.
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?
With an output schema present, return values needn't be documented, yet the description still shows a sample response shape, and it fully covers the error/failure path and retry behavior — nothing an agent needs in order to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% so the baseline is 3, but the worked example ({"item_length": 10, ..., "box_options": [[12,9,4],[14,10,6]]}) concretely binds the parameters to their units and nesting shape, plus 'allowing for padding' clarifies the padding parameter's role in the comparison.
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?
States a precise verb+resource+objective: 'Pick the smallest box an item actually fits in, allowing for padding.' It also names the sibling it is not (dim_weight) so the agent can distinguish them without opening either schema.
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?
'Use when choosing packaging from stock' gives the positive trigger, and 'Not for what the carrier will bill once a box is chosen: that is dim_weight' gives an explicit exclusion plus the alternative to route to.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Turn a cost model into a customer-facing weight-banded price table. PREMIUM (license).
Prices each band at its upper bound so you never under-charge inside a band, then rounds up to a tidy increment. Typical input {"base_cost": 4.2, "cost_per_lb": 0.65, "bands_lb": [1, 2, 5, 10], "margin_pct": 25} returns {"bands": [{"up_to_lb": 1, "cost": 4.85, "price": 6.5}, ...], "over_top_band": "quote individually"}.
Use when publishing shipping prices customers pay. Not for the cut-off at which shipping becomes free: that is free_shipping_threshold. Errors: on invalid, missing, or malformed input this tool never raises a protocol error; it returns {"error": ""} (for example {"error": "bands_lb must contain at least one upper bound"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| bands_lb | Yes | Upper weight bound of each band in ascending order, e.g. [1, 2, 5, 10]. At least one band, each greater than 0. | |
| round_to | No | Increment to round each published price up to, e.g. 0.5 or 1. Default 0.5. | |
| base_cost | Yes | Fixed cost per shipment before weight, e.g. pick, pack and label. Must be greater than 0. | |
| margin_pct | No | Margin added on top of cost, e.g. 25 for 25%. Default 0. | |
| cost_per_lb | Yes | Marginal cost per pound. Use 0 for a flat rate card. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, yet the description still adds real behavioral content: prices are computed at each band's upper bound so in-band under-charging is impossible, results round up to a tidy increment, and every call is safe to retry. It also discloses the error contract — invalid input never raises a protocol error but returns an {"error": ...} object — which annotations cannot convey.
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 purpose and sibling boundary are front-loaded, followed by a compact input/output example and an error contract — every sentence carries information. The only slack is the stray 'PREMIUM (license).' tier marker, which adds no guidance for an agent.
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?
The tool has an output schema, so return values need no prose, yet the description still shows the result shape and the over_top_band policy. Combined with the error-handling paragraph and the retry guarantee, an agent has everything needed to call it correctly and recover from bad input.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the worked example shows how base_cost, cost_per_lb, bands_lb and margin_pct combine and what over_top_band means, adding meaning beyond the per-field docs. It stops short of explaining round_to's interaction with margin, so it lands at 4 rather than 5.
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 first sentence states a specific verb and resource — turning a cost model into a customer-facing weight-banded price table — and the description immediately marks the boundary against a named sibling (free_shipping_threshold). An agent can distinguish this from dim_weight, freight_class, and landed_cost without inspecting any schema.
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?
It gives an explicit when (publishing the shipping prices customers actually pay) and an explicit when-not, routing the free-shipping cut-off case to the free_shipping_threshold sibling by name. Nothing about tool selection is left to inference.
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.
dim_weightfree_shipping_thresholdfreight_classlanded_costparcel_fitrate_cardFreight calculators (weight, metres, vehicle fit) and authenticated team packing-library tools.
Instant LTL, partial and truckload freight quotes in the US and Canada, with class and pallet tools
Calculate shipment volume (CBM/CFT), weight, and how cargo fits standard shipping containers.
Plan optimal container & truck loads: 3D layouts, utilization, centre of gravity, crush checks.
Add one secure layer between your agents and this server.
