Skip to main content
Glama

detect_rooms

Detect every room on a plan in a single batch: trace each labeled enclosure and return area/perimeter per room for takeoff.

Instructions

Batch room detection: reads every room-number label off the sheet's text layer (e.g. "134", "OFFICE 101") and runs One-Click at each — one call instead of read_sheet_text + reasoning + N one_click calls. An OCR'd scan (text layer, no vector linework) floods the rendered pixels instead (#154), disclosed per room and on origin as raster_traced. A seed is only reported as a room once it survives three gates, and everything skipped is counted and reasoned in withheld — never dropped silently, because a room the tool tells you it skipped is a question you can ask, while one it hides is a hole in a bid. The gates: a flood that leaked or landed in dense linework never becomes a region; two labels flooding the SAME region commit once (the extra labels ride on merged_labels — double-counting an area is the worst failure an estimating tool has); and a flood that is enclosed and clean but smaller than min_area_sf is a room-number bubble, a door swing, or a wall cavity rather than a room. Every room floods through the SAME sealed engine a single one_click runs (RFC #60 — feet-true gap sealing, door-swing wedges, the minimum-passage rule), so a batch detection and a click at the same seed measure the same square footage; each room carries the engine's account of its own trace (confidence + confidence_factors, gap_sealed_px, door_wedges, min_pass_px/min_pass_delta), and the same account rides origin on everything committed. Confidence is a review prioritizer, never a verification — a low-confidence room is a view_sheet {overlay: true} audit prompt, not a fact to bid from. With the sheet's scale set, returns area_sf/perimeter_lf per room. Every committed room carries the room number it was traced from as the shape's label, so a sweep arrives already sliced by room — that field is what the Report's per-room grouping and the workbook's floor × room tab read, and it is the one thing about a batch that cannot be recovered downstream if it is dropped. TO COMMIT, choose the honest source of the finish tag: assign_from_schedule: true routes every room through its OWN room-finish schedule row and commits each under the FLOOR finish that row states — when a schedule exists in the set, THIS is the default move, because one agent-chosen tag across N rooms flattens real finish variety into a wrong bid; condition commits every room under that one stated tag (only right when the rooms genuinely share it; role "deduct" makes them subtract). Without a scale, returns px-only quantities per room and commits nothing — the plausibility floor needs real units, so it only applies once a scale is set. A batch commit is NOT finished until you have LOOKED at it: view_sheet {overlay: true}, audit every ring against the walls, fix misses with edit_shape / delete_shape — before the totals mean anything. Coordinates are image px at render scale 2.0: PDF pt × 2, origin top-left, y down (the browser canvas's native space). Sheet payloads carry dims in both px and pt.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
roleNofloor_area
sheetYes
layersNoOverride the sheet's classified layer roles for THIS call (see sheet_info.layers)
conditionNoFinish tag to commit every detected room under (minted on first use). Mutually exclusive with assign_from_schedule
min_area_sfNoPlausibility floor: enclosed non-bubble regions smaller than this are withheld as cavities, not rooms. Default 5 SF — below any real finished space (a broom closet is ~10 SF). Lower it to inspect what was skipped.
sensitivityNoFill sensitivity, the same knob the canvas has: 0 strict (hatch/light linework always blocks), 0.5 balanced (default), 1 aggressive (crosses more hatch, tolerates more growth). Raise it when a flood stops short at hatching INSIDE the room; verify the grown ring with view_sheet overlay before committing
return_vertsNoInclude each traced polygon's vertices (image px)
assign_from_scheduleNoCommit each room under the FLOOR finish its OWN room-finish schedule row states (resolve_tag's chain, per room): the citation rides origin.assignment, and rooms the schedule cannot answer for — no row, no FLOOR cell, a compound cell like "CPT-1/VCT-1" — are returned in unresolved[] with reasons and seeds instead of committed under a guess. Needs the sheet's scale and a room-finish schedule in the working set (merge the schedule sheet in with load_plan first). Mutually exclusive with condition

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
noteNoHuman-readable summary of what was withheld, when anything was
roomsYes
warningNoPreview mode (no scale): why quantities are unavailable and what to do
detectedYesCount of cleanly-detected rooms — may be fewer than the labels found on the sheet
withheldYesWhat detection skipped and why — a withheld room is a question the caller can ask; a silently dropped one is a hole in a bid
unresolvedNoAssign mode only, empty array included: [] is the positive claim that every detected room resolved against its own schedule row
multiple_scalesNoSeveral DISTINCT scale notes on this sheet (#153) — rooms inside an enlarged viewport may be figured at the wrong scale
Behavior5/5

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

No annotations are provided, so the description carries the full burden. It discloses extensive behavioral traits: internal gates, withheld reasoning, merged_labels, 'never dropped silently', the same sealed engine, coordinate space, and commit requirements. It also clarifies confidence as a review prioritizer, not verification.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is an extremely long, single paragraph with many parentheticals and rhetorical asides (e.g., 'double-counting an area is the worst failure'). Although front-loaded with purpose, it is not appropriately sized; each sentence does not strictly earn its place due to verbose explanatory philosophizing.

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 tool with 8 params, nested layers, and output schema, the description covers input source, detection process, error handling, commit semantics, scale dependence, post-commit audit, and output coordinates. Output schema handles return values, so no gap in completeness.

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?

Even with 75% schema coverage, the description adds significant meaning beyond the schema: role 'deduct' makes them subtract, min_area_sf plausibility floor, sensitivity usage, assign_from_schedule vs condition mutual exclusivity, and scale requirement for sheet. It compensates for missing schema descriptions and enriches parameter understanding.

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 description opens with 'Batch room detection: reads every room-number label off the sheet's text layer' and explicitly contrasts with 'read_sheet_text + reasoning + N one_click calls', clearly distinguishing it from siblings. The verb+resource+scope is specific and immediately clear.

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?

It gives explicit when-to-use guidance: 'when a schedule exists in the set, THIS is the default move' vs condition, and notes 'Without a scale... commits nothing'. It also instructs to audit with view_sheet and fix misses, providing clear context for use cases and exclusions.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Kentucky-ai/opentakeoff'

If you have feedback or need assistance with the MCP directory API, please join our Discord server