measure-mcp

room_check_fit

Check if furniture or equipment fits a wall or room. Compares item size against free space, respecting doors and windows, and returns a fits/tight verdict with margin.

Instructions

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.

dims is the item size, width x depth x height (width = longest front-facing side, depth = front to back): a string such as "84 x 37 x 34 in", "60x30 in" (height unknown), "2.1 x 0.95 x 0.9 m"; a list such as [84, 37, 34] with dims_unit (default inches, and the reply says so); or an object like {"name": "sofa", "width": 84, "depth": 37, "height": 34, "unit": "in"} ({"length", "width", "height"} is read as width = length, depth = width). item_name labels it. target: a wall, "room" (default; finds spots), or {"type": "region", "x": 0, "y": 0, "width": 2, "depth": 1} in room meters. A wall is an id ("wall_1", or {"type": "wall", "id": "wall_1"}) or words: "longest wall", "shortest wall", "wall with the door", "wall with the window", "wall behind the sofa" / "sofa wall" (the wall nearest that object category or id), and "north/south/east/west wall" ONLY when the scan defines an orientation (see room_load_scan north_deg). An unclear reference returns an error whose hint lists every wall with its id, length and what is on it (room_list_walls shows the same labels). clearance: "none", "walkway" (76 cm / 30 in in front), "comfortable" (91 cm / 36 in), or {"front_m": 0.76, "side_m": 0, "back_gap_m": 0.02}. It respects doors, door swings, windows (windows warn/block/ignore) and existing furniture; list furniture the user will remove (or the scan's own copy of the item, e.g. the sofa being replaced) in ignore_objects (ids or a comma list): when the thing blocking a wall looks like the item itself, the reply says so. verdict is fits / tight / probably_not / does_not_fit from margin divided by the scan's uncertainty; a 1 cm margin on a drifty scan is "tight", never "fits". Returns placements with footprints (pass one to room_floor_plan_svg). max_results is 1-10. detail summary|full. load_options as in room_summary.

Input Schema

TableJSON Schema

Name	Required	Default
`dims`	Yes
`path`	Yes
`units`	No	both
`detail`	No	summary
`target`	No
`windows`	No	warn
`clearance`	No	none
`dims_unit`	No
`item_name`	No
`max_results`	No
`load_options`	No
`rotations_deg`	No
`ignore_objects`	No
`respect_door_swing`	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.6/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 delivers: it explains that verdict (fits/tight/probably_not/does_not_fit) is margin divided by scan uncertainty, that a 1 cm margin on a drifty scan is 'tight, never fits', that it respects doors, swings, windows and existing furniture, and that ambiguous references return an error hinting all walls with ids and lengths. It also flags the self-blocking case and the return of placements with footprints.

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 core question and purpose before any parameter detail, and nearly every sentence carries usable information. It is long and parenthetical-heavy, which costs some scannability, but no sentence is filler.

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 14-parameter spatial computation tool with an output schema, the description covers the decision logic (verdict thresholds, orientation-gated references), the edge cases (ignored objects, self-blocking, error hints) and which sibling to reach for on follow-up. Only the unexplained path/units/rotations_deg/respect_door_swing parameters keep it short of perfect.

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?

Schema description coverage is 0%, so the description must compensate, and it does for most parameters: three accepted dims formats with unit conventions, dims_unit default, item_name, target (wall ids, natural-language wall references, region objects), clearance presets and object form, windows policy, ignore_objects, max_results 1-10, detail summary|full, and delegation of load_options to room_summary. However, path, units, rotations_deg and respect_door_swing are never explained anywhere.

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?

Opens with a concrete question ('Will this item fit?') and states the exact operation: checking an item's footprint against a wall's free run or the whole room, returning a verdict with margin. This cleanly separates it from sibling checks such as room_check_doorway and from measurement/listing tools like room_list_walls.

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 strong conditional guidance: when compass-wall references are valid ('ONLY when the scan defines an orientation'), what happens on an unclear reference, and when to list items in ignore_objects. It cross-references room_load_scan, room_list_walls, room_summary and room_floor_plan_svg, but never states explicit when-not conditions versus room_check_doorway.

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