measure-mcp

fba_tier_headroom

Check how close a packed unit is to Amazon FBA size tier, weight and fee thresholds, then see which edge to shrink and by how much to lower fees.

Instructions

Show how close a packaged unit is to every FBA tier, weight and fee-band threshold, and what to shrink to pay less. (fba_analyze is the one-call version with the single best suggestion.)

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" (a bare number is POUNDS unless weight_unit says otherwise); price = listing price in USD. dims_sigma = 1-sigma error per edge in dims_unit (use sigma_in from fba_measure_package; 0.2 in for a LiDAR scan); weight_sigma_oz = scale error in ounces. margin_in is the safety margin in INCHES (default 0.5) and margin_pct the weight margin in percent (default 3); a threshold is "risky" inside either margin or within 2 sigma and "critical" within 1 sigma. When dimensional weight sets the shipping weight, a weight-band edge is also risky if a margin_in measuring error could cross it. max_shrink_pct caps how much any one edge may shrink (default 15%); min_dims (same form and unit as dims) is the smallest each edge can be because of the contents. ship_date (ISO, default today) picks peak or non-peak fees; units_per_month adds monthly savings.

Returns current tier and fee, thresholds sorted by risk, overall_risk, ranked suggestions (single- and two-edge shrinks, each with apply_dims_in, new_total_usd, saving_per_unit_usd and per inch, confidence), tier_drop_suggestions (shrinks that reach a cheaper tier with the safety margin), and weight_suggestions (unit-weight cuts). Targets include the safety margin. Savings come from the same fee engine as fba_fee_estimate. detail="summary" (default) adds a short caveats list; "full" adds the assumptions list.

Estimate only; Amazon measures the packed unit itself and its measurement governs.

Input Schema

TableJSON Schema

Name	Required	Default
`dims`	Yes
`price`	Yes
`detail`	No	summary
`weight`	Yes
`min_dims`	No
`dims_unit`	No
`margin_in`	No
`ship_date`	No
`dims_sigma`	No
`margin_pct`	No
`weight_unit`	No
`max_shrink_pct`	No
`units_per_month`	No
`weight_sigma_oz`	No
`include_weight_options`	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.7/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 defines 'risky' vs 'critical' bands, the dimensional-weight crossover rule, default margins and shrink caps, the peak/non-peak fee dependency, and the crucial caveat 'Estimate only; Amazon measures the packed unit itself and its measurement governs.'

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-loaded with the purpose sentence and organized into 'Inputs:' and 'Returns:' blocks, which makes a long body navigable. The Inputs paragraph is an unusually dense run-on that could be broken up, but given 15 parameters the length is largely justified.

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 an output schema existing, the description still summarizes return fields, and it compensates for absent annotations and 0% schema coverage with defaults, semantics and an estimation caveat. For a complex 15-parameter tool, nothing essential for correct invocation 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 description coverage is 0% across 15 parameters, so the description must compensate and largely does: it gives accepted formats and unit semantics for dims, weight, price, dims_sigma, weight_sigma_oz, margin_in, margin_pct, max_shrink_pct, min_dims, ship_date, units_per_month and detail, including the 'bare number is POUNDS unless weight_unit says otherwise' rule.

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 (show headroom to FBA tier/weight/fee-band thresholds) plus the actionable outcome (what to shrink to pay less). It explicitly contrasts itself with fba_analyze as the 'one-call version with the single best suggestion', so an agent can tell the two apart without opening a 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?

Names the closest alternative (fba_analyze) and implies the selection condition (full threshold picture vs. single best suggestion), and points to fba_measure_package for the sigma value. However it never addresses fba_size_tier or fba_fee_estimate directly, and gives no explicit 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.