measure-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MEASURE_MCP_TOKEN | No | Bearer token required when running the server on a non-loopback address (e.g., with --host 0.0.0.0). | |
| MEASURE_MCP_TOOLS | No | Set to the groups of tools you want to load. Possible values: kitchen, room, moving, fba. Combine groups with commas, e.g., 'kitchen,room'. If unset, all 34 tools load (~19k tokens). Core measure_* tools always load. | |
| MEASURE_MCP_OUTPUT_DIR | No | Directory where tools write output files (floor plans, inventories). Defaults to ~/measure-mcp-output. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| measure_depth_infoA | Check what a photo or depth file contains BEFORE measuring from it. path: HEIC/HEIF, TIFF, 16-bit PNG, NPZ, JPEG, or a capture-app bundle (folder or .zip). Returns summary (quote it), info {kind, has_depth, depth_size [w, h], accuracy absolute|relative, source, intrinsics_origin, valid_fraction, warnings}, advice and capabilities {monocular_depth, heic, usd}. accuracy "relative" needs a reference object; intrinsics_origin "assumed" means the camera field of view is a guess (every size is then capped at low confidence with a wide +/-). A file with no depth is a plain photo: see advice for the options. |
| measure_objectA | Size (length, width, height) of one object standing on a flat surface, from a depth capture or 3D scan. path: LiDAR/Portrait HEIC, capture bundle (folder or .zip), a metric depth file (TIFF, 16-bit PNG in mm,
NPZ), or a 3D scan: a Scaniverse, Polycam or 3D Scanner App OBJ or PLY export (a .zip holding the .obj plus
its .mtl and texture is fine). A scan must show the object standing on a table; the object is the one
nearest the middle, as a gravity-aligned box, and rgb_path, bbox, point and reference do not apply to it. The
file's units and up axis are detected and reported in the result's |
| measure_distance_between_pointsA | Straight-line distance between two pixels of a depth capture (a doorway width, a shelf gap). path: LiDAR/Portrait HEIC, capture bundle or metric depth file (TIFF, 16-bit PNG in mm, NPZ). point_a and point_b: [x, y] in PHOTO pixels (depth-map pixels when there is no photo). rgb_path: optional original photo (EXIF gives the focal length). reference: see measure_list_reference_objects; with a plain photo the two points must lie on the reference's surface. units: metric|imperial|both. Returns summary (quote it), confidence, measurements [distance] (+/- about 95%), warnings. A depth file without camera intrinsics is capped at low with a wide +/-. Glass, mirrors and black surfaces have no depth (NO_DEPTH_AT_POINT): pick a nearby matte point. Points under 3 cm apart are within the noise. |
| measure_list_reference_objectsA | List everyday objects of known size (credit_card, us_quarter, us_letter, a4, half_sheet_pan, dollar_bill)
that give a photo a metric scale, and how to pass one as Lay it flat on the same surface as the thing measured, fully visible, then pass reference={"type": key, "corners": [[x,y] x4 in photo pixels, clockwise from top-left]} (discs: "bbox"). Needed for relative depth; it also fixes a guessed field of view, and measures a flat object's footprint in a plain photo. |
| measure_open_captureA | Describe a capture bundle from the measure-mcp iOS app (a folder or .zip): depth.tiff, confidence, colour image and a capture.json sidecar with intrinsics, pose and device. Returns summary (quote it), depth_size, source (lidar), accuracy, valid_fraction, depth_range_m, intrinsics. Pass the same path to kitchen_measure_vessel, measure_object, measure_distance_between_points to measure. |
| measure_find_filesA | List recent measurable files on this computer, newest first, with what each contains. When the user says "this photo" or "the scan I just took" in chat you have NO file path: ask them to save it to ~/measure-mcp-inbox (or AirDrop it to Downloads), then call this tool and use the path it returns. folder: look only there (direct children, no recursion); default: $MEASURE_MCP_INBOX, ~/Downloads, ~/Desktop, ~/measure-mcp-inbox. limit: 1-100 (default 20). Finds HEIC/HEIF, JPEG, depth TIFF/PNG/NPZ, capture .zip or folders, PLY/OBJ/USDZ and RoomPlan/scan JSON. Each file: path, size_bytes, modified, age, kind, has_depth (+ depth_size, accuracy, source, intrinsics), can_measure_with. Returns summary, files, searched. |
| kitchen_measure_vesselA | Capacity of a bowl, baking dish, cake pan, sheet pan or pot from one depth capture or 3D scan (to scale a recipe). Camera looking down into the upright vessel on a flat surface (45 degrees above the table or steeper), whole
rim in frame. path: LiDAR/Portrait HEIC, capture bundle (folder or .zip), metric depth file (16-bit PNG in mm,
TIFF or NPZ in meters), a plain photo, or a 3D scan: a Scaniverse, Polycam or 3D Scanner App OBJ or PLY
(a .zip with the .obj, .mtl and texture is fine). A scan needs the vessel upright on a table with some table in
view; it is the object nearest the middle, clutter is ignored, and rgb_path, bbox, point and reference do not
apply. Units and up axis are detected and reported in A plain photo has no depth. With the base install it returns NO_DEPTH whose hint lists the options in order: LiDAR capture; a credit card in frame plus pip install "measure-mcp[depth]"; typed dimensions (kitchen_vessel_from_dimensions, which always works). measure_depth_info shows what is installed. Returns summary (quote it), vessel (pass it as source_vessel/target_vessel to kitchen_scale_recipe), measurements (rim size, inner depth, brimful capacity, each +/- about 95% with a confidence), capacity (L, mL, cups, quarts), fill_guidance, nearest_preset, quality (fit_grade, fit_issues) and warnings. Capacity is BRIMFUL, inner surface. Confidence is never "high" for relative or monocular depth, a noisy or poorly fitting capture, or guessed camera intrinsics (those are "low"); a rim that fits no clean circle/rectangle returns VESSEL_FIT_POOR instead of a number. Present it as an estimate; typed dimensions are more exact. |
| kitchen_vessel_from_dimensionsA | Build a vessel and its capacity from a standard pan name or typed dimensions; no photo, always works. Pass EITHER preset OR dimensions (both is an error). preset takes natural names: "9x13", "9 x 13 inch pan", "8 inch round", "8-inch cake pan", "half sheet", "loaf pan", "bundt", "2 qt saucepan", "10 inch skillet", "23x33 cm"... Presets include square/round/springform pans, 9x13, loaf pans, quarter/half/full sheets, pie plate, skillets, bundt and tube pans, one muffin cup, casseroles and pots by quart. The result says which preset it resolved to (preset.resolved_to, preset.match exact|alias|parsed|default|fuzzy): tell the user. An unknown name returns candidates. dims: "9 x 13 x 2 in" (length x width x depth), "9 x 2 in" (round: diameter x depth), a list or a dict; or the named fields diameter, or length and width, plus depth. dims_unit: in (inches, default), cm, mm, m. Measurements are INSIDE, rim to inside floor. For slanted walls add bottom_diameter (or bottom_length and bottom_width, never wider than the rim); profile cylinder|frustum|cap is inferred (bowl: "cap"). Bundt/tube: tube_diameter (approximate). Outside sizes need wall_thickness. corner_radius is optional. Returns summary (quote it), vessel (pass to kitchen_scale_recipe), capacity (L, mL, cups, quarts, brimful), fill_guidance, preset {source, verified, how resolved} and warnings. |
| kitchen_scale_recipeA | Scale a recipe written for one pan to another vessel, with kitchen-friendly amounts. ingredients: ONE text block, an ingredient per line (paste the list as is), or a list of strings ("2 1/4 cups
flour", "3 eggs", "1/2 cup (115 g) butter, melted") or {"amount", "unit", "name"} objects. A line with no
number stays unscaled and is listed in warnings. source_vessel: the pan the recipe was written for;
target_vessel: the pan to use now. Each is a |
| room_load_scanA | Read a room scan and report what was found (walls, doors, windows, objects, size, detected units and up axis).
|
| room_summaryA | Overall size of the room: footprint shape and vertices, floor area, ceiling height, volume, wall lengths, openings and objects.
|
| room_list_wallsA | List the walls with a plain-language
|
| room_list_openingsA | List doors, windows and open passages with width, height, sill and head height, wall, position and swing side. Filter by |
| room_list_objectsA | List furniture and appliances found in the scan with category, size (width x depth x height), footprint, height off the floor and nearest wall. RoomPlan scans carry Apple categories (sofa, table, bed, storage, refrigerator, ...); raw point clouds give |
| room_check_fitA | Will this item fit? Checks an item's footprint against a wall's free run or the whole room and returns a verdict with margin.
|
| room_check_doorwayA | Can this item go through that door or open passage? Tests a rigid box through the clear opening, turning it any way it can go.
|
| room_floor_plan_svgA | Draw the room as a floor plan SVG: walls with dimension lines, doors with swing arcs, windows, furniture, and optionally a proposed item. Pass |
| fba_analyzeA | START HERE for "what FBA tier and fee is this product?": one call returns the size tier, dimensional
and shipping weight, the estimated fulfillment fee (this period, and the peak or non-peak alternative),
the nearest limit that would change the tier or fee with its margin in YOUR units, a risk class
(safe / risky / critical) that reflects that nearest edge, and the single best shrink or weight cut to
save money. Quote Inputs: dims = the 3 edges of the PACKED unit as "12 x 9 x 3 in", [12, 9, 3] (with dims_unit) or {"length":12,"width":9,"height":3}; weight = 1.4 or "1.4 lb" / "22 oz" / "640 g" (a bare number is POUNDS unless weight_unit says otherwise, and the summary says how it was read); price = listing price in USD (29.99 or "$29.99"; selects the fee price band). dims_unit is in (default), cm or mm; weight_unit is lb (default), oz, g or kg. dims_sigma = 1-sigma measuring error per edge in dims_unit (omit for tape values; use sigma_in from fba_measure_package, or 0.2 in for a LiDAR scan); weight_sigma_oz = scale error in ounces. ship_date (ISO, default today) picks peak or non-peak fees. margin_in (0.5 in) and margin_pct (3 %) are the safety margins behind the risk class; a weight-band edge counts as risky when a measuring error of margin_in could cross it. max_shrink_pct and min_dims bound the shrink search. detail="summary" (default) returns a short Estimate from third-party-compiled rules (see fba_data_status); Amazon's own measurement governs. |
| fba_measure_packageA | Measure the PACKAGED unit (the box or bag as it ships) from 1 to 5 scans of the same package. Inputs: path = one scan file, or paths = a list of 2 to 5 scans of the same pack (combined by median per
sorted edge). A scan is a 3D scan export (a Scaniverse, Polycam or 3D Scanner App OBJ or PLY mesh or point
cloud; a .zip holding the .obj plus its .mtl and texture is fine) of the package on a table, a metric depth
file (HEIC, TIFF, 16-bit PNG, NPZ) or an iOS capture bundle (folder or .zip); rgb_path is an optional
companion photo for a single depth file. For OBJ/PLY the file's units (m, cm, mm or inches) and up axis are
detected from the table and plausible sizes, and notes say what was assumed; if that is wrong or ambiguous,
pass scan_units (m|cm|mm|in: what the FILE is written in; Scaniverse writes METERS, and Returns dims_in {longest, median, shortest} in INCHES with 1-sigma sigma_in per edge (LiDAR is never reported better than 0.2 in), dims_cm, length_plus_girth_in, volume_cubic_in, unit_weight (user-supplied), confidence (high/medium/low), quality_flags (thin_item_unreliable, low_coverage, soft_or_irregular_surface, scan_disagreement, monocular_only, relative_depth_not_metric, assumed_intrinsics), capture_advice and fba_args, ready to pass to fba_analyze. Relative, monocular or assumed-intrinsics depth is never high confidence. Items thinner than 1.5 in cannot be certified by a depth scan. This is an estimate for packaging decisions; Amazon measures the unit itself and its measurement governs. detail="full" adds per-scan results and the assumptions list. |
| fba_size_tierA | Classify a packaged unit into its US Amazon FBA size tier (small standard, large standard, small bulky, large bulky, extra-large bands) and show how close it is to each limit. (fba_analyze answers the usual question, tier plus fee plus nearest limit, in one call.) Inputs: dims = the 3 edges of the PACKED unit, any order: "12 x 9 x 3 in", [12, 9, 3] with dims_unit (in default, cm or mm) or {"length":12,"width":9,"height":3}; weight = unit weight of the packed unit: 1.4, "1.4 lb", "22 oz" or "640 g" (a bare number is POUNDS unless weight_unit is oz, lb, g or kg; the summary states how it was read). dims_sigma = 1-sigma measurement error per edge in dims_unit (a single number, or 3 numbers in the same order as dims; omit for exact tape/caliper values); weight_sigma_oz = scale error in ounces. as_of (ISO date) picks the dataset effective on that date, default today. Only product_class "standard" is modelled in v0.1. Returns tier, sorted dims in inches, length_plus_girth_in, unit and dimensional weight in lb (divisor 139,
2 in floor on the two shorter sides for bulky tiers), the shipping weight Amazon bands on (greater of unit
and dimensional, unit-only for small standard), each binding limit with margin, z-score and risk class
(safe/risky/critical), rejected tiers with the failing limits, the next tier up and tier_probabilities when
dims_sigma is given. detail="summary" (default) adds a short Estimate from third-party-compiled rules (see fba_data_status); Amazon's own measurement governs. |
| fba_fee_estimateA | 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 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. |
| fba_tier_headroomA | 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 Estimate only; Amazon measures the packed unit itself and its measurement governs. |
| fba_audit_listingA | 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: 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. |
| fba_draft_remeasure_requestA | Draft (never send) a Seller Support remeasurement request. Pass the dict returned by fba_audit_listing as audit, plus asin / sku / fnsku and seller_name. The text states measurements as seller-provided hand measurements, asks for a multi-unit Cubiscan remeasurement, asks Amazon to confirm fees and reimburse overcharges since the charge date within policy, and offers sample units. It does not claim a scan proves anything. Bracketed [ADD: ...] placeholders mark facts only the seller knows (number of units measured, name); replace them before use. amazon_dims_text / measured_dims_text override the dimensions taken from the audit, for example "18.5 x 12 x 3 in". measurement_method describes how the seller measured. tone is "concise" or "detailed". Returns subject, body, checklist (measure 3+ units as shipped, 90-day window from the charge date, reported re-request limits), warnings (audit verdict not 'likely over', low confidence, window passed, missing fields), the channel to use and the deadline. submitted is always false. Amazon's own measurement governs; photos and estimates from this server are not proof. |
| fba_data_statusA | Report which FBA rules dataset is in force and how much to trust it. Call this before quoting a fee,
or when another fba tool's date (ISO, default today) is the day to check. Returns dataset_id, as_of date of the data, effective range, the peak window and whether peak or non-peak fees apply on that day, active surcharges, a per-section verification table (official / secondary_cross_checked / secondary / unverified), the list of rows that are verified versus not, unverified_fields, staleness warnings (data older than 90 days or past its review date), source URLs and the 90-day reimbursement window. Fee and tier rows are currently compiled from third-party sources, so treat them as estimates; Amazon's own measurement and fee schedule govern. |
| moving_cube_sheet_lookupA | Look up how many cubic feet (and pounds) the movers' cube sheet assigns to an item, with sources. Use this to answer "why 50 cu ft for my sofa?" or to find the right catalog name before building an inventory. Accepts names, aliases, plurals, small typos and size hints ("55 inch tv", "18 cu ft fridge"). Each match lists the value, the range across published sheets, alternative values, the weight at the movers' 7 lb per cu ft rule, and whether the row was re-verified against its source. Never includes prices. |
| moving_estimate_from_inventoryA | Estimate the volume (cu ft / m3) and weight of a move from a list of belongings. Give |
| moving_estimate_from_scanA | Estimate a move from a RoomPlan room scan (JSON export, USDZ, or a PLY/OBJ the room tools can load). Pass |
| moving_estimate_objectA | Volume of one oddly shaped object from measured size, ready to add to an inventory. Give |
| moving_recommend_truckA | Pick the smallest rental truck or van (U-Haul, Penske, Budget) for a load, by volume AND payload. Pass |
| moving_recommend_containerA | Pick portable moving containers (PODS 8/12/16 ft, U-Haul U-Box) for a load, by volume AND weight limit. Containers have hard weight limits that dense loads (books, tools) can hit before the volume is full;
|
| moving_recommend_storageB | Pick a self-storage unit size (5x5 up to 10x30) for a load, leaving an access aisle. Unit volume is floor area times ceiling height (8 ft is typical; pass ceiling_ft if the facility differs). Usable space is 0.65-0.80 of that (packing efficiency minus 0.05 for an aisle). Also reports the next smaller unit and how much would not fit, and two-unit combinations. Input as in moving_recommend_truck. No prices. |
| moving_export_inventoryA | Turn an estimate into a printable or shareable inventory list for movers, insurance or storage. Pass |
| moving_data_infoB | Report the versions, as-of dates, source URLs, verified/unverified row counts and staleness warnings of the moving data files (cube sheet, trucks, containers, storage units). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 34 tools
Domains are cleanly separated by prefix (measure/kitchen/room/fba/moving) and most tools target a distinct input or resource. The main overlap is the FBA cluster, where fba_analyze is explicitly the one-call version of fba_size_tier/fba_fee_estimate/fba_tier_headroom; the descriptions admit this and guide tool selection, which keeps ambiguity manageable rather than confusing.
Strong, predictable domain-prefix + verb_noun convention (measure_object, room_list_walls, kitchen_scale_recipe, moving_estimate_from_inventory, fba_size_tier). A few bare-noun outliers (room_summary, fba_data_status, moving_data_info) and info/analyze names deviate slightly, but overall the pattern is readable and consistent.
34 tools is heavy for a single server and sits above the comfortable 3-15 range. It is partly justified because five genuinely distinct domains (measurement, kitchen, room, FBA, moving) are bundled, but the redundant FBA tier/fee/headroom-versus-analyze cluster suggests some bloat rather than each tool earning a unique slot.
Every domain has full lifecycle coverage: measurement (info, object, distance, references, capture, file discovery), kitchen (measure/from-dims/scale), room (load, summary, walls, openings, objects, fit, doorway, floor plan), FBA (analyze, tier, fee, headroom, package measure, audit, remeasure draft, data status), and moving (lookup, three estimators, truck/container/storage, export, data info). No obvious dead ends.