Moltline Shipping Maths

Landed Cost

landed_cost

Read-onlyIdempotent

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.

Input Schema

TableJSON Schema

Name	Required	Description
`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.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

TDQS

A5/5.0

Behavior5/5

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

Matches annotations (read-only, idempotent, non-destructive) and adds details about error handling (returns error object instead of raising protocol errors) and retry safety. Provides extra transparency beyond the 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?

Despite being detailed, the description is well-structured: purpose, formula, example, usage instructions, and error handling. Each sentence adds value without redundancy, fitting the complexity of the tool.

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?

Covers all necessary aspects: calculation logic, input parameters, example output, usage guidance, and error behavior. The presence of an output schema and complete parameter descriptions means no critical information is missing.

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% and parameter descriptions are detailed (e.g., freight_total is specified as 'for the whole shipment, not per unit'). The description further clarifies the roles of duty and tax parameters 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?

Clearly states the tool computes landed cost including freight, duty, and taxes, with an example. It distinguishes from sibling tools by explicitly noting it is not for margin calculation (margin_check) and is for pricing imported stock.

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 instructs to use before setting a price on imported stock and warns not to use for margin calculations, directing to a sibling tool. Also explains the calculation order and provides an example, giving clear usage context.

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

All Moltline Shipping Maths tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.8/5.0

Disambiguation5/5

Each tool serves a clearly distinct calculation: billable weight, free shipping break-even, freight class from density, landed cost, box selection, and rate card generation. The descriptions explicitly cross-reference which tool to use instead when there's potential overlap, eliminating ambiguity.

Naming Consistency4/5

Tool names follow a consistent lowercase snake_case style, but the pattern is mostly noun phrases (dim_weight, freight_class, rate_card) with one deviation (parcel_fit uses a noun+verb combo). This is minor and does not hinder readability.

Tool Count5/5

With 6 tools, the set is well-scoped for a shipping mathematics server. Each tool addresses a distinct functional need without redundancy, fitting comfortably in the ideal range.

Completeness5/5

The surface covers the core shipping calculations: dimensional weight, packaging selection, freight classification, landed cost, pricing thresholds, and rate tables. No obvious missing operations for the stated domain, especially given the read-only and idempotent nature of the tools.

Resources

Need Help?