measure-mcp

fba_fee_estimate

Estimate US Amazon FBA per-unit fulfillment fees in USD from packed unit dimensions, weight, and listing price, showing peak/non-peak tiers and itemised cost components.

Instructions

Estimate the US Amazon FBA per-unit fulfillment fee in USD for a packaged unit.

Inputs: dims = 3 edges of the PACKED unit, any order ("12 x 9 x 3 in", [12, 9, 3] with dims_unit in/cm/mm, or a dict); weight = 1.4 / "1.4 lb" / "22 oz" / "640 g" (a bare number is POUNDS unless weight_unit says otherwise; the summary states how it was read); price = the listing price in USD (24.99 or "$24.99"; selects the fee price band: under 10, 10 to 50, over 50). ship_date (ISO date, default today) selects the peak table (2026-10-15 to 2027-01-14) or non-peak, and whether the 3.5% fuel and logistics surcharge (from 2026-04-17) applies; set include_fuel_surcharge=false to see the fee without it. dims_sigma / weight_sigma_oz add a +-2 sigma fee interval. units_per_month adds a monthly total. Only product_class "standard" is supported; others return an error.

Returns tier, shipping weight, price_band, period (peak/nonpeak), itemised components with the rule used, total_usd, interval_usd, monthly_usd, the alternate period's total, what is NOT included (bulky packaging fee, inbound placement, storage, returns) and data_verification. If a fee row is missing in the dataset the tier is still returned and fee_available is false. detail="summary" (default) adds a short caveats list; detail="full" adds the assumptions list and disclaimer.

Rates come from third-party summaries and are not yet verified against Seller Central; compare with the Fee Preview report. Amazon's own measurement and fee schedule govern.

Input Schema

TableJSON Schema

Name	Required	Default
`dims`	Yes
`price`	Yes
`detail`	No	summary
`weight`	Yes
`dims_unit`	No
`ship_date`	No
`dims_sigma`	No
`weight_unit`	No
`product_class`	No	standard
`sipp_enrolled`	No
`units_per_month`	No
`weight_sigma_oz`	No
`include_fuel_surcharge`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 16, 2026

TDQS

A4/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and does so richly: it discloses the peak-table window (2026-10-15 to 2027-01-14), the 3.5% fuel/logistics surcharge from 2026-04-17 and how to disable it, the error for unsupported product_class values, and the fee_available=false fallback when a fee row is missing. It also flags calibration risk (unverified third-party rates, compare with Fee Preview) and what is deliberately excluded.

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?

Purpose is front-loaded, then inputs are grouped, then returns, then provenance caveats — a sensible progression for a complex computational tool. It is dense but every paragraph corresponds to a real schema/behavioral need; nothing is padding, though the returns paragraph is long.

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?

An output schema exists, so the description need not fully explain return values, yet it still usefully summarizes them plus the fee_available fallback and detail modes. Combined with the thorough input and provenance coverage, the only real omission is the undocumented sipp_enrolled parameter.

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?

With 0% schema description coverage, the description does the heavy lifting, documenting acceptable forms and defaults for dims/dims_unit, weight/weight_unit (bare number = pounds), price and its fee bands, ship_date, include_fuel_surcharge, dims_sigma, weight_sigma_oz, units_per_month, product_class, and detail. One parameter, sipp_enrolled, is never mentioned, leaving a real gap for a 13-param tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Estimate the US Amazon FBA per-unit fulfillment fee in USD for a packaged unit'), including currency and scope, so the agent knows exactly what is produced. It does not, however, name or distinguish itself from siblings like fba_size_tier or fba_analyze, so routing still requires inference from the sibling list.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It implies usage through the input narrative (fill dims/weight/price, set ship_date to pick peak vs non-peak, include_fuel_surcharge=false to exclude the surcharge) and states the product_class='standard' restriction. But it never says when to choose this tool over fba_size_tier, fba_analyze, or fba_tier_headroom, which is the main guidance gap.

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