measure-mcp

measure_object

Measure an object's length, width, and height from depth captures or 3D scans, returning real-world dimensions with confidence levels.

Instructions

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 scan block; if they are wrong or ambiguous pass scan_units (m|cm|mm|in: what the FILE is written in, units="cm" works as an alias) and up_axis (x|y|z, signs ok). rgb_path: optional original photo (its EXIF gives the focal length; its pixels are the coordinates for bbox and point). bbox [x0, y0, x1, y1] or point [x, y]: PHOTO pixels (depth-map pixels when there is no photo) to pick the object. reference {"type": "credit_card", "corners": [[x,y] x4]} (see measure_list_reference_objects) rescales relative depth and fixes a guessed field of view. units: metric|imperial|both. Returns summary (quote it), confidence (worst of the edges, the same rule fba_measure_package uses), measurements longest/middle/shortest_edge (+/- about 95%) and bounding_box_volume (the enclosing box, NOT a vessel's capacity: use kitchen_measure_vessel for that), quality, warnings. Never "high" for relative or monocular depth or for a file without camera intrinsics (those are "low"), nor for a scan whose units had to be guessed (check scan.units_source). Under 1.5 cm is unreliable. Plain photo with no depth: pass bbox around a FLAT object plus a rectangular reference lying flush beside it and you get its footprint (length x width, no heights, no install needed).

Input Schema

TableJSON Schema

Name	Required	Default
`bbox`	No
`path`	Yes
`point`	No
`units`	No	both
`up_axis`	No	auto
`rgb_path`	No
`reference`	No
`scan_units`	No	auto

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.9/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 behavioral burden and does so: it reports where units/up-axis detection results land (scan block), how confidence is computed (worst of the edges, same rule as fba_measure_package), the grading rules (never 'high' for relative/monocular depth or missing intrinsics), and a hard reliability floor (under 1.5 cm is unreliable). It also warns that the scan 'nearest the middle' is selected and that rgb_path/bbox/point/reference do not apply to scans.

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-loads the one-line purpose, then flows into dense, mostly run-on prose. Given eight undocumented params the length is justified, but there is no bulleted structure to scan and the closing summary of return fields partly duplicates the existing output schema.

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?

Covers the acceptance surface (file types), unit/axis overrides, coordinate frames for bbox/point, the reference-based rescaling path, accuracy caveats, and the flat-object fallback — everything needed to call it correctly. Return-value detail is redundant given the output schema but is accurate.

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 coverage is 0%, so the description must document all 8 params and largely does: scan_units (m|cm|mm|in with the units alias), up_axis (x|y|z, signs allowed), rgb_path (EXIF focal length; pixels are the bbox/point coordinate frame), bbox/point formats and pixel basis, units (metric|imperial|both), and reference (type credit_card with 4 corners). This meaning is entirely absent from the schema.

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 ('Size (length, width, height) of one object standing on a flat surface') plus the input domain (depth capture or 3D scan). It actively distinguishes itself from siblings, explicitly routing vessel-capacity questions to kitchen_measure_vessel and reference setup to measure_list_reference_objects.

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

Usage Guidelines5/5

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

Gives explicit when/when-not guidance across every branch: which file formats qualify (LiDAR/HEIC, bundle, TIFF/16-bit PNG/NPZ, Scaniverse/Polycam/3D Scanner App OBJ/PLY), when to override scan_units/up_axis, when rgb_path/bbox/point/reference apply, and the flat-photo fallback with a rectangular reference. It names alternatives for adjacent needs.

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