measure-mcp

room_check_doorway

Check if a rigid item can fit through a door or open passage. Tests dimensions, door state, and options such as rolling or removing legs to return a verdict and margin.

Instructions

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.

dims as in room_check_fit but all three sizes are needed: "84 x 37 x 34 in", [84, 37, 34] with dims_unit, or {"name": "sofa", "width": 84, "depth": 37, "height": 34, "unit": "in", "diagonal_depth": 31, "leg_height": 6}. Real sofas are not boxes: give diagonal_depth (top-back corner to bottom-front corner of the frame, the figure movers use) when known, and leg_height if the legs unscrew. opening_id is a door or open passage from room_list_openings; WINDOWS ARE REFUSED (error NOT_A_DOORWAY, which lists the valid door/opening ids). Open passages (no door leaf) get no leaf allowance, and unidentified gaps (gap_unknown) are tested with lowered confidence and a note. door_state: "as_is"/"leaf_open_90" (leaf swung back; it still takes door_intrusion_m, default 4 cm) or "removed" (off the hinges). allow_roll lets the item tilt about its travel axis; allow_legs_removed removes the legs first. Returns the verdict, margin, best way through, alternatives, and what would help (remove the door, remove legs). The approach path and turns are not evaluated; near zero margin the answer is "tight": measure the door. load_options as in room_summary.

Input Schema

TableJSON Schema

Name	Required	Default
`dims`	Yes
`path`	Yes
`units`	No	both
`detail`	No	summary
`dims_unit`	No
`item_name`	No
`allow_roll`	No
`door_state`	No	as_is
`opening_id`	Yes
`load_options`	No
`door_intrusion_m`	No
`allow_legs_removed`	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

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 names the NOT_A_DOORWAY error and what it contains, explains the lower-confidence behavior for gap_unknown, that open passages get no leaf allowance, the default door_intrusion_m of 4 cm, the 'tight' verdict near zero margin, and explicitly excludes approach path and turns from evaluation.

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?

The core question is front-loaded in sentence one, and given 12 parameters and zero schema coverage the length is largely justified. It is dense and reads as a wall of text, but sentences earn their place by disambiguating parameters and edge cases.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex analysis tool with an output schema, the description supplies the operating model, error behavior, and limitation scope an agent needs. Remaining gaps are the unexplained required `path` and the units/detail toggles.

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?

At 0% schema coverage the description must compensate and largely does: it gives three concrete dims formats, dims_unit, opening_id provenance, door_state semantics, door_intrusion_m default, allow_roll, and allow_legs_removed, plus load_options. However the required `path` parameter and the units/detail/item_name params are never explained, leaving real gaps.

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?

The opening question — 'Can this item go through that door or open passage?' followed by 'Tests a rigid box through the clear opening, turning it any way it can go' — states a specific verb, resource, and method. It is clearly distinguishable from the sibling room_check_fit (which it references for the dims format) 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?

It tells the agent where opening_id comes from (room_list_openings), that windows are refused, and what edge cases mean. There is clear usage context but no explicit statement of when to prefer room_check_fit over this tool, so it stops short of full alternative routing.

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