Plain Freight

Estimate China to USA shipping cost

estimate_price

Read-onlyIdempotent

Rough price estimate for shipping goods from China to a US address, 100 g to 2,000 kg. Records nothing, contacts no one and needs no email. Inputs: total weight, and optionally the product and carton sizes or total volume. Returns estimated door to door prices in USD for air (and sea from 10 kg chargeable weight), the chargeable weight used (the greater of actual weight and carton volume in cm3 / 6,000), transit estimates, and whether US import duty is included. Figures come from Plain Freight's pricing engine for densely packed goods, priced on the applicable rate; goods that need a review get no figure. The exact ZIP code, pickup city and cartons can move the price, so the result is an estimate, not an offer.

Input Schema

Name	Required	Description
`product`	No	What is being shipped, in a few words (sets the goods rate)
`total_cbm`	No	Total volume in cubic meters, if known instead of carton sizes
`weight_kg`	Yes	Total actual weight of the shipment in kg
`carton_count`	No	Number of cartons of that size
`carton_width_cm`	No	One carton's width in cm
`carton_height_cm`	No	One carton's height in cm
`carton_length_cm`	No	One carton's length in cm

Output Schema

Name	Required	Description
`error`	No
`goods`	No
`options`	No
`estimate`	No	Always true: a rough figure, not an offer
`actual_kg`	No
`next_step`	No
`priced_as`	No
`priced_on`	No	Date the pricing engine produced these figures
`chargeable_kg`	No
`volumetric_kg`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 27, 2026

changedOutput schema / properties / priced_as / enum

Previous value: -[
-  "general",
-  "branded"
-]New value: +[
+  "general",
+  "branded",
+  "toy"
+]

Changed1 schema field changedSep 27, 2026

changedOutput schema / properties / goods / properties / verdict / description

Previous value: -"instant_offer: priced at once; branded_rate: priced at once on the higher branded rate; person_checks_first: no price until a person reviews the goods"New value: +"instant_offer: priced at once; branded_rate: priced at once on its applicable rate; person_checks_first: no price until a person reviews the goods"

AddedSep 27, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Adds substantial behavior beyond the annotations: no writes, no contacts, no email requirement; the chargeable-weight rule (greater of actual weight and cm3/6000); duty inclusion in the returned price; and the important edge case that goods requiring review return no figure at all. It also discloses the pricing model's bias (densely packed goods) and the limits of accuracy, which is exactly the context an agent needs to trust or caveat the output.

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?

Front-loads purpose, then inputs, then return values, then caveats — a sensible order with no filler sentences. It is a single dense paragraph, denser than it needs to be, but every sentence carries 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?

Despite seven parameters and a pricing calculation, the description covers what goes in, what comes back, the chargeable-weight logic, and the failure case where no figure is returned. With an output schema present, it doesn't need to enumerate return fields and correctly doesn't.

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 the baseline would be 3, but the description adds real meaning: the 100 g–2,000 kg operating range, the choice between carton dimensions and total volume, and how volume feeds the chargeable-weight divisor of 6,000. It doesn't explain carton_count semantics beyond the schema's own text, which keeps it short of a 5.

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 and resource — a rough door-to-door price estimate for China-to-US shipping — with an explicit weight range. The framing 'the result is an estimate, not an offer' cleanly separates it from generate_offer, and the scope (air, sea from 10 kg chargeable) is unambiguous without opening the schema.

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?

Gives clear context for when this is the right call: it records nothing, contacts no one, needs no email, and is explicitly 'an estimate, not an offer', which implicitly routes the agent to generate_offer for a firm quote. It never names the sibling explicitly, so the routing is inferred rather than stated.

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

All Plain Freight tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.