measure-mcp

fba_audit_listing

Audit an Amazon FBA listing by comparing recorded dimensions, weight, and fees with your measurements to decide if requesting a remeasurement is worthwhile.

Instructions

Compare what Amazon has on file / charged against your own measurement and say whether a remeasurement request looks worthwhile. A design-time and audit aid, NOT dispute evidence.

Naming: dims, weight (and dims_unit, weight_unit, dims_sigma) are YOUR measurement of the packed unit, as in the other fba tools; every amazon_* parameter is what Seller Central shows or charged. dims = your 3 edges ("12 x 9 x 3 in", a list or a dict; dims_unit in/cm/mm, default in); dims_sigma = their 1-sigma error in dims_unit (default 0.2 in); weight = your scale reading (1.4, "1.4 lb", "22 oz"; a bare number is POUNDS) and is optional only when amazon_weight is given. Give at least one of: amazon_dims (+ amazon_weight; amazon_dims_unit and amazon_weight_unit default in and lb) as shown in Seller Central, amazon_tier (e.g. "small_bulky"), or amazon_fee = the per-unit fulfillment fee charged (Fee Preview or order fee, without referral fee; 6.10 or "$6.10"). price = listing price in USD. charge_date = date the fee was charged (ISO; starts the 90-day reimbursement window), ship_date defaults to it. fee_includes_fuel_surcharge: leave unset to test both. units_sold_since_charge scales the exposure; units_per_month adds a monthly amount. When the fee differs under your dims and Amazon's and edges differ significantly, the verdict is at least amazon_possibly_over / amazon_possibly_under (uncertainty softens "likely" to "possibly", never to "no money at stake"); "consistent" is only returned when the central fees match or no edge differs.

Returns verdict (consistent, amazon_likely_over, amazon_likely_under, inconclusive, fee_not_explained_by_dims), confidence (never high), per-edge deltas with significance, tier comparison with probabilities, fee comparison with overcharge per unit (central and conservative), a reverse lookup of which tier/weight-band/period/price-band rows produce the charged fee (works without Amazon's dims), reimbursement_deadline and days_left, likely causes and next steps. The verdict never claims Amazon is wrong; the strongest wording is "likely over-measured; worth requesting remeasurement". detail="full" adds the assumptions list.

Estimate from third-party fee data; Amazon's own measurement governs.

Input Schema

TableJSON Schema

Name	Required	Default
`dims`	Yes
`price`	Yes
`detail`	No	summary
`weight`	No
`dims_unit`	No
`ship_date`	No
`amazon_fee`	No
`dims_sigma`	No
`amazon_dims`	No
`amazon_tier`	No
`charge_date`	No
`weight_unit`	No
`amazon_weight`	No
`units_per_month`	No
`weight_sigma_oz`	No
`amazon_dims_unit`	No
`amazon_weight_unit`	No
`units_sold_since_charge`	No
`fee_includes_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/5.0

Behavior4/5

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

With no annotations, the description carries the burden well: it discloses verdict logic, that confidence is 'never high', that uncertainty softens 'likely' to 'possibly', that the verdict 'never claims Amazon is wrong', and the 90-day reimbursement window started by charge_date. It does not explicitly state the tool is read-only/non-mutating, but the 'audit aid' framing makes this inferable.

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 and the 'not dispute evidence' caveat are front-loaded, then the naming/unit conventions, then the verdict behavior. It is dense and long, but 19 parameters with 0% schema coverage justify most of the length; a few clauses (e.g. the verdict wording rules) could be tightened.

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?

For a complex 19-parameter analytical tool with no annotations, the description supplies the input conventions, the conditional-requirement rule, verdict semantics, and the 90-day window. An output schema exists, yet the description still previews the key return fields, making it fully sufficient to invoke and interpret.

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%, so the description must do the work and it largely does: it defines dims, dims_unit, dims_sigma, weight, weight_unit, the amazon_* family, price, charge_date, ship_date, units_sold_since_charge, units_per_month, fee_includes_fuel_surcharge, and detail='full', including formats ('12 x 9 x 3 in', '1.4 lb', bare number = POUNDS) and defaults. Only weight_sigma_oz is left undocumented.

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 comparison action ('Compare what Amazon has on file/charged against your own measurement') and an explicit outcome ('say whether a remeasurement request looks worthwhile'). It also distinguishes itself from sibling fba tools by declaring it is 'a design-time and audit aid, NOT dispute evidence', so an agent can tell it apart from fba_draft_remeasure_request without opening either 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 usage context ('design-time and audit aid') and a when-not ('NOT dispute evidence'), plus the input condition that selects it ('Give at least one of: amazon_dims..., amazon_tier..., or amazon_fee'). It never names the alternative sibling tools to route to, so it stops short of full routing guidance.

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