Skip to main content
Glama

one_click

Click inside a room on a plan to trace its boundary from the drawing's vector or raster linework, returning area and perimeter in feet. Supports committing the shape to a takeoff with an optional finish condition.

Instructions

One-Click Area: click inside a room (image px) and the plan's vector linework bounds it — the sealed flood engine (RFC #60), contour trace, vertices snapped to true PDF endpoints. The engine's arguments are FEET-TRUE through the sheet's scale, exactly the canvas's: gap sealing bridges up to a door-width opening (disclosed as gap_sealed_px — that much boundary is synthetic), door-swing wedges annex the swing a doorway sweeps (door_wedges), and the minimum-passage rule keeps sub-half-foot slits from conjoining two rooms (min_pass_px/min_pass_delta). Every trace carries the engine's own account of itself: confidence (0..1, with confidence_factors naming what deducted) — a review PRIORITIZER, never a verification. 1.0 means every signal ran clean, not that the trace is right; a LOW confidence is a view_sheet {overlay: true} audit prompt, not a fact to bid from — put eyes on the flagged edge before the total means anything. SCANNED sheets work too (#154): where vectors can't bound the room (an image-only scan, or a scan wrapper whose only linework is the title block), the flood falls back automatically to the sheet's rendered pixels — same engine the canvas uses — and the reply plus the committed shape's origin carry raster_traced: true so a pixel-bounded ring is never mistaken for a vector-snapped one. Vector always wins where it works; a raster ring's corners are unsnapped, so audit it with view_sheet {overlay: true} before trusting the total. With the sheet's scale set, returns area_sf / perimeter_lf; pass condition (a finish tag, e.g. "CPT-1") to commit the traced shape to the takeoff — the full engine account rides the committed shape's origin, so the export tells the truth about how each shape was made. Without a scale it returns px-only quantities with a warning and commits nothing (the engine also degrades to its scale-blind fallbacks — a weaker measurement, one more reason set_scale comes first). role "deduct" makes the committed shape subtract. After committing, LOOK at what landed — view_sheet {overlay: true} — and fix an overshot ring with edit_shape before trusting any total. 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
xYes
yYes
roleNofloor_area
sheetYes
layersNoOverride the sheet's classified layer roles for THIS call (see sheet_info.layers)
conditionNoFinish tag to commit under (minted on first use)
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 the traced polygon's vertices (image px)

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
vertsNoTraced polygon vertices (image px), when return_verts was set
nvertsYesVertex count of the traced polygon
statusYes
area_sfNoScaled mode: traced area in SF
warningNoPreview mode (no scale): why quantities are unavailable — OR, in scaled mode, a mixed-scale warning (#153): a scale note disagreeing with the sheet's sits in the measured region (enlarged plan/detail viewport likely)
area_px2NoPreview mode (no scale): raw area in px²
shape_idNoScaled mode: id of the committed shape, when condition was passed
confidenceNo0..1 — the trace scored from the engine's own signals (sealed openings, door wedges, min-passage rule, hatch tier, raster boundary, mask coarseness, implausible size). A review PRIORITIZER, not a verification: 1.0 means every signal came back clean, never that the trace is right. A low score is a view_sheet {overlay:true} audit prompt, not a fact to bid from
door_wedgesNoDoor-swing wedges annexed into the region under grow-but-verify — how many doorways' swings were included, the canvas's own door handling; rides origin.door_wedges
min_pass_pxNoThe feet-true minimum-passage rule (openings under ~0.5 ft never connect two spaces) ran at this dilation radius AND changed the answer — present only with min_pass_delta
perimeter_lfNoScaled mode: traced perimeter in LF
perimeter_pxNoPreview mode (no scale): raw perimeter in px
gap_sealed_pxNoPresent when the seal ladder closed a genuine OPENING this many mask px wide (doorway-scale — scaled by the sheet's feet, distinct from gap_bridged_px's drafting-pinhole rescue). Part of the boundary is synthetic, and confidence deducts by that share; rides origin.gap_sealed_px on the committed shape
raster_tracedNoPresent when the region was bounded by the sheet's RENDERED PIXELS (the scanned-sheet raster fallback, #154) rather than vector linework — absent means the vector path ran. Rides origin.raster_traced on the committed shape; a raster ring's corners are unsnapped (a scan has no true endpoints), so audit it with view_sheet overlay before trusting the total
gap_bridged_pxNoPresent when the seal ladder bridged a drafting pinhole this many px wide to close the region — the rescue rides provenance (origin.gap_bridged_px) rather than passing as a clean fill
hatch_filteredNoPresent when hatch/pattern linework was classified out of the boundary
min_pass_deltaNoFraction of the verbatim flood the minimum-passage rule removed; 1 means the drawn linework bounds nothing here and the rule is the only reason there is a measurement — audit before trusting
ring_interiorsNoOf those wedges, how many were a CLOSED ring's interior (round column, callout bubble) rather than a door swing — annexed floor you may want as a deduct instead
confidence_factorsNoThe named factors behind a sub-1.0 confidence (e.g. "sealed-opening(10% synthetic boundary)") — each names the edge worth putting eyes on; absent when every signal ran clean
Behavior5/5

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

With no annotations, the description carries full transparency burden and does so extensively. It discloses synthetic boundary from gap sealing (gap_sealed_px), door-swing wedges (door_wedges), the meaning of confidence, automatic raster fallback for scanned sheets, and the exact coordinate system (render scale 2.0, origin top-left, y down). It even warns that '1.0 means every signal ran clean, not that the trace is right'. This is exceptionally rich behavioral disclosure.

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 front-loaded with the core purpose, but it is very long and includes repeated audit warnings ('put eyes on the flagged edge', 'LOOK at what landed', 'audit it'). While almost every sentence adds technical detail, the redundancy and dense jargon make it less concise than it could be. It earns a mid score for structure over length.

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 an 8-parameter tool with no annotations, the description covers most critical contextual areas: scale dependency, raster fallback, commit semantics, confidence as a review tool, coordinate system, and post-commit verification. It lacks explicit detail on layers and sensitivity, but those are documented in the input schema. Given the tool's complexity, the description is near-complete, though not perfectly exhaustive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 50%, so the description must compensate for x, y, role, and sheet. It does explain x/y as image px click coordinates, role's deduct behavior, and condition as a finish tag. However, it omits the layers override, sensitivity knob, and return_verts flag entirely, leaving those to schema descriptions. It adds meaningful semantics for some parameters but not all.

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 leads with a specific verb and resource: 'click inside a room (image px) and the plan's vector linework bounds it — the sealed flood engine'. This clearly distinguishes one_click as an automatic area-tracing tool, unlike sibling tools such as measure_polygon or detect_rooms. It also specifies the commit behavior and role semantics, making the purpose unmistakable.

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?

The description gives concrete usage context: 'With the sheet's scale set, returns area_sf / perimeter_lf', 'Without a scale it returns px-only quantities with a warning and commits nothing', and explicitly says 'role "deduct" makes the committed shape subtract'. It recommends setting scale first and auditing afterward with view_sheet, and mentions using edit_shape for fixes. However, it never explicitly compares against sibling tools like measure_polygon or detect_rooms, so it stops short of full when-to-use versus alternatives guidance.

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