opentakeoff-mcp

Overview Schema Source Related Servers Discussions Admin

measure_surface

Trace an open wall run in plan view and multiply length by wall height to compute wall surface area for tile, wainscot, and wall takeoffs.

Instructions

Surface Area — wall SF (#146): trace an OPEN run along the wall in plan view (min 2 points, image px) and the quantity is traced LF × height. This is how wall tile, wainscot, and wall systems are taken off — the quantity family measure_polygon cannot produce. Height lives on the CONDITION (the canvas's H knob): pass height_ft to set it on this call (journals as its own undo step, like typing H before tracing), or set it once with edit_condition; with neither, this refuses and mints nothing. The shape snapshots the height it was quantified at. Requires the sheet's scale. 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

Name	Required	Description
`pts`	Yes	The wall run, an open polyline (image px)
`sheet`	Yes
`condition`	Yes	Finish tag to commit under (minted on first use), e.g. 'CT-W1'
`height_ft`	No	Wall height in feet — written to the condition's H knob first, then used
`arc_through`	No	Indices of points that are the MIDDLE of an arc: the trace runs the point before → this point → the point after as the unique circle through the three (the canvas's Curve mode). For a curved wall put one point anywhere ON the bow between its two ends and mark it. The arc is baked to ordinary vertices on commit and origin.curved is stamped; a mark on an end of an open run, or two marks in a row, refuses.

Output Schema

TableJSON Schema

Name	Required	Description
`arcs`	No	How many arc_through bows were laid — present only when the trace was bent; the vertices reported are the baked arc, not the three points you gave
`npts`	Yes
`area_sf`	Yes	length_lf × height_ft — the wall SF committed
`shape_id`	Yes
`condition`	Yes
`height_ft`	Yes	The height this shape was quantified at (snapshotted on the shape)
`length_lf`	Yes	The traced run's open length

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.1.24Sep 13, 2026

addedInput schema / properties / arc_through

Added value: +{
+  "description": "Indices of points that are the MIDDLE of an arc: the trace runs the point before → this point → the point after as the unique circle through the three (the canvas's Curve mode). For a curved wall put one point anywhere ON the bow between its two ends and mark it. The arc is baked to ordinary vertices on commit and origin.curved is stamped; a mark on an end of an open run, or two marks in a row, refuses.",
+  "items": {
+    "minimum": 0,
+    "type": "integer"
+  },
+  "type": "array"
+}

addedOutput schema / properties / arcs

Added value: +{
+  "description": "How many arc_through bows were laid — present only when the trace was bent; the vertices reported are the baked arc, not the three points you gave",
+  "type": "integer"
+}

Addedv0.1.9Jul 31, 2026

TDQS

A4.7/5.0

Behavior4/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 unusual detail: the refusal-on-missing-height behavior, the separate undo journal entry for height_ft, the height snapshot on the committed shape, and the arc baking to ordinary vertices with origin.curved stamped. It does not cover permissions/auth, and output schema covers returns, so the safety profile is thin but the mutation semantics are well disclosed.

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 quantity identity and use case, then the prerequisites and coordinate convention. It is dense and long, with some clause-heavy sentences, but nearly every sentence adds operative information rather than restating the name.

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 mutation tool with no annotations, the description covers the failure mode, the side effect on the condition, undo journaling, scaling requirements, and the coordinate space; with an output schema present, return values need not be explained. Nothing an agent needs to invoke it correctly appears to be missing.

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 80%, so the baseline would be 3, but the description adds real meaning beyond the schema: the coordinate system (image px at render scale 2.0 = PDF pt × 2, origin top-left, y down), arc_through's Curve-mode behavior and its refuse cases, and the ordering effect of height_ft on the condition. These are semantics the schema strings do not convey.

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 ('Surface Area — wall SF: trace an OPEN run along the wall in plan view') and contrasts it with the sibling it cannot replace ('the quantity family measure_polygon cannot produce'). An agent can distinguish it from measure_line and measure_polygon without opening the schema.

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?

Explicitly names the use cases (wall tile, wainscot, wall systems) and the alternative (measure_polygon), and spells out the preconditions: height must come from height_ft or edit_condition, 'with neither, this refuses and mints nothing', plus the sheet scale requirement. Both the when and the when-not are stated.

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