Landed cost, fees & profit calculators for cross-border Amazon, TikTok Shop and Shopify sellers.
Scored across 3 tools
Each tool targets a distinct calculation: landed cost input, profit output from a given price, and required price derived from margin targets. There is no meaningful overlap in their outputs or intended use.
Two tools follow a clear verb_noun pattern (calculate_landed_cost, estimate_profit), but breakeven_price is a noun phrase without an action verb. The naming is otherwise predictable and readable.
Three tools is well-scoped for a focused cross-border cost and profit calculator. Each tool covers a distinct part of the calculation workflow without unnecessary redundancy.
The set covers the core calculation loop: landed cost, profit/margin/ROI/ACoS, and breakeven/target price. Minor extras like batch analysis or currency conversion are missing, but no obvious critical gap exists for the stated purpose.
反推保本价与达到目标净利率所需的售价。
解方程：售价 × (1 − 佣金率 − 广告率 − 目标净利率) = 落地成本 + 固定费用(履约费/固定手续费)。
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | 亚马逊品类（仅 amazon 生效），默认 home_kitchen。 | home_kitchen |
| fba_tier | No | FBA 尺寸档（仅 amazon_fba 生效），默认 small_std_4_8oz。 | small_std_4_8oz |
| platform | No | 平台 amazon_fba / amazon_fbm / tiktok_us / shopify / aliexpress。 | amazon_fba |
| ad_cost_pct | No | 广告费占售价比例（%），默认 15。 | |
| landed_cost | Yes | 单件落地成本（USD）。 | |
| target_margin_pct | No | 目标净利率（%），默认 20。 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. The formula is transparent about the core calculation, but it does not explain where commission rates and fixed fees come from, how platform-specific rules affect results, or any edge cases. This is a meaningful gap for a no-annotation tool.
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 description is compact and front-loaded: the purpose is stated first, followed by a concise formula. Every element contributes to understanding the tool, with no filler or repetition.
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 formula and the fully covered schema together explain the mechanics of the calculation. However, the description omits when-to-use guidance, platform-specific fee behavior, and any caveats about default values. With no annotations and an output schema present, this is adequate but not complete.
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%, so the baseline is 3. The formula adds meaning by linking ad_cost_pct, target_margin_pct, and landed_cost into the calculation, but it does not add detail beyond the schema for category, fba_tier, or platform. The description provides modest added value without fully compensating for any gaps.
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 description clearly states the tool's function: reverse-calculating the breakeven price and the price needed to reach a target net margin. The formula further clarifies the resource and calculation approach. It does not explicitly name sibling tools, but the inverse-pricing purpose is distinct from cost estimation and profit estimation.
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?
No guidance is given on when to use this tool versus calculate_landed_cost or estimate_profit. There are no exclusions, prerequisites, or alternative conditions mentioned. The usage context is only implied by the formula and the sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
计算单件落地成本（采购 + 头程 + 关税 + 杂费）。
落地成本 = 采购单价 + 单件头程运费 + 关税（按货值）+ 其他固定成本（贴标/质检/包装等）。
| Name | Required | Description | Default |
|---|---|---|---|
| unit_cost | Yes | 单件采购单价（出厂价，USD）。 | |
| duty_rate_pct | No | 关税税率（%），按货值计；需以 HS 编码 + 进口国海关核定， 本工具不编造税率，默认 0（可先用 export-compliance 的 HS 工具归类）。 | |
| freight_method | No | 头程方式 sea(海运)/air(空运)/express(快递)，决定参考费率。 | sea |
| unit_weight_kg | No | 单件毛重（含包装，kg），用于按头程费率估算运费；若给了 freight_total_override 则忽略此项。 | |
| other_fixed_cost | No | 单件其他固定成本（USD），默认 0。 | |
| freight_total_override | No | 直接指定单件头程运费（USD），优先于重量估算。 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It usefully reveals that the tool does not invent duty rates and defaults to 0, which is an important honesty behavior. However, it does not disclose whether freight rates are live quotes or static reference estimates, and it says nothing about side effects or permissions.
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?
Two compact sentences with the core computation front-loaded and no filler. The formula sentence earns its place by explaining how the components combine, and nothing is repeated from structured data unnecessarily.
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 6-parameter calculator with a rich input schema and an output schema, the description is largely sufficient: it gives the formula and the key duty-rate behavior. It could be more complete by routing to sibling tools or stating freight-rate assumptions, but those are minor given the schema and output schema coverage.
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. The description adds value by presenting the exact formula tying unit_cost, freight, duty, and other_fixed_cost together, and it clarifies overhead examples like labeling/QC/packaging. This is a real semantic improvement over the schema alone, though not a large one.
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 description states a specific verb-resource pair ('计算单件落地成本') and gives the full formula, so an agent can tell this computes per-unit landed cost rather than profit or breakeven. However, it does not explicitly name or differentiate from sibling tools breakeven_price and estimate_profit, so it misses the strongest form of differentiation.
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?
The description gives clear calculation context and even advises using export-compliance's HS tool for duty classification because the tool defaults duty to 0 and does not fabricate rates. It does not state when to use this tool versus breakeven_price or estimate_profit, nor does it give any when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
估算单件净利 / 净利率 / ROI / 保本 ACoS。
净利 = 售价 − 落地成本 − 平台佣金 − 履约费(仅 FBA) − 广告费。
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | 亚马逊品类（仅 amazon 平台生效，决定佣金%），默认 home_kitchen。 | home_kitchen |
| fba_tier | No | FBA 尺寸档（仅 amazon_fba 生效，决定履约费），默认 small_std_4_8oz。 | small_std_4_8oz |
| platform | No | 平台 amazon_fba / amazon_fbm / tiktok_us / shopify / aliexpress。 | amazon_fba |
| sell_price | Yes | 售价（USD）。 | |
| ad_cost_pct | No | 广告费占售价比例（%），默认 15。 | |
| landed_cost | Yes | 单件落地成本（USD，可用 calculate_landed_cost 得到）。 | |
| return_rate_pct | No | 退货率（%），默认 0，仅计入提示、不直接扣减（退货成本另算）。 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It does this well by revealing the exact calculation formula, noting that fulfillment fees apply only to FBA, and indicating that return rate is not directly deducted. This gives agents important behavioral context beyond the schema, though it does not cover every edge case.
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 description is two compact sentences: the first front-loads the outputs, the second states the formula. Every phrase earns its place, and there is no filler or repetition of schema boilerplate.
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 calculator with 7 parameters but only 2 required, the schema defaults and per-parameter descriptions, combined with the description's formula, provide enough to invoke the tool correctly. The output schema covers return-value details. The main missing element is explicit sibling-selection guidance, which is a meaningful but not fatal gap.
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%, so the baseline is 3. The description adds relational meaning by tying parameters together in the formula: sell_price minus landed_cost, platform commission, FBA fulfillment fee, and advertising cost. This is valuable beyond the individual per-parameter schema descriptions.
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 description uses a specific verb ('估算' / estimate) and clearly names the resources: per-unit net profit, net margin, ROI, and breakeven ACoS. It also provides the profit formula, making the purpose concrete. It does not explicitly differentiate itself from siblings like breakeven_price, so it falls short of a 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?
The description gives no explicit guidance on when to use this tool versus breakeven_price, the main sibling alternative. The only alternative reference is buried in a parameter description ('可用 calculate_landed_cost 得到'), which mentions a data source but not selection criteria. Usage context is largely 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.
breakeven_pricecalculate_landed_costestimate_profitFree EU VAT, IBAN and bol.com commission tools for marketplace sellers
Cross-border duty-rate and Trade & Tariff content lookups with product compliance and restrictions
Curated Amazon/Shopify/TikTok Shop changes (fees, policies, APIs) & upcoming seller deadlines.
Inventory, restock planning, and sales analytics for your Amazon FBA business.
Add one secure layer between your agents and this server.
