opentakeoff-mcp

Overview Schema Source Related Servers Discussions Admin

measure_line

Measures open polylines on plan sheets at the set scale, computing total length in feet with arc curves and optional vertical rise/drop legs.

Instructions

Measure an open polyline (min 2 points, image px): length_lf at the sheet's scale. Requires the scale to be set. Pass condition to commit it as a linear shape (base, transitions, feature strips, conduit and home runs). A curved run (base along a radius wall, a curved feature strip) takes arc_through: one point on the bow, marked. DROP AND RISE (#441): a plan trace is the flat X–Y path; the material also travels VERTICALLY — a home run drops from the ceiling to a panel, rises to a box. length_lf is the TOTAL: plan + rise + drop. The condition's rise_ft / drop_ft (edit_condition) are the defaults for every run under it; pass rise_ft / drop_ft here to give THIS run its own legs (0 included — "no drop on this one" is a statement), and the reply splits plan_lf / vertical_lf beside the total when a leg exists. 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
`sheet`	Yes
`drop_ft`	No	This run's vertical leg DOWN, in feet, added to its plan length — overrides the condition's drop_ft default for this run (0 = no drop here, whatever the default)
`rise_ft`	No	This run's vertical leg UP, in feet, added to its plan length — overrides the condition's rise_ft default for this run (0 = no rise here, whatever the default)
`condition`	No
`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
`drop_ft`	No	The drop this run resolved to — present with vertical_lf
`plan_lf`	No	The flat X–Y trace alone — present only when the run carries a vertical leg
`rise_ft`	No	The rise this run resolved to (its own, else the condition default) — present with vertical_lf
`shape_id`	No	Present when condition was passed and the shape committed
`length_lf`	Yes	The run's TOTAL length: plan trace + rise + drop (#441)
`vertical_lf`	No	rise_ft + drop_ft — present only when a leg exists

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedv0.1.25Sep 25, 2026

addedInput schema / properties / drop_ft

Added value: +{
+  "description": "This run's vertical leg DOWN, in feet, added to its plan length — overrides the condition's drop_ft default for this run (0 = no drop here, whatever the default)",
+  "minimum": 0,
+  "type": "number"
+}

addedInput schema / properties / rise_ft

Added value: +{
+  "description": "This run's vertical leg UP, in feet, added to its plan length — overrides the condition's rise_ft default for this run (0 = no rise here, whatever the default)",
+  "minimum": 0,
+  "type": "number"
+}

addedOutput schema / properties / drop_ft

Added value: +{
+  "description": "The drop this run resolved to — present with vertical_lf",
+  "type": "number"
+}

addedOutput schema / properties / length_lf / description

Added value: +"The run's TOTAL length: plan trace + rise + drop (#441)"

addedOutput schema / properties / plan_lf

Added value: +{
+  "description": "The flat X–Y trace alone — present only when the run carries a vertical leg",
+  "type": "number"
+}

addedOutput schema / properties / rise_ft

Added value: +{
+  "description": "The rise this run resolved to (its own, else the condition default) — present with vertical_lf",
+  "type": "number"
+}

addedOutput schema / properties / vertical_lf

Added value: +{
+  "description": "rise_ft + drop_ft — present only when a leg exists",
+  "type": "number"
+}

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.2Jul 17, 2026
Removedv0.1.1Jul 17, 2026
First observedJul 15, 2026

TDQS

A4.7/5.0

Behavior5/5

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

With no annotations, the description fully carries the behavioral burden: it discloses the commit side effect when a condition is passed, arc validation refusals, rise/drop merging with per-run overrides, and the exact coordinate system. This is far richer than annotations alone would provide.

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 description is front-loaded with the core purpose and moves through prerequisites, arcs, vertical legs, and coordinate space in a logical order. It is long, but information-dense; minor asides like “#441” and the parenthetical about 0 could be trimmed without losing essential content.

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 six-parameter tool with optional commit behavior and vertical-leg complexity, the description covers preconditions, unit conventions, validation refusals, overrides, and the plan/vertical split. Since an output schema exists, not detailing the full return value is not a gap.

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 only 50% and pts, sheet, and condition are undocumented in the schema, but the description compensates directly: it defines pts as image-px coordinates for open polylines, explains condition's commit role, and clarifies rise_ft/drop_ft overrides including the special meaning of 0. arc_through also receives semantics beyond its schema description.

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 a specific verb and resource—measuring an open polyline and returning length_lf at sheet scale—and lists the linear shape types it commits. It distinguishes the tool from siblings like measure_polygon and measure_surface by emphasizing open polylines and linear runs.

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 clearly states when to use the tool (open polyline/linear runs), requires the scale to be set, and explains the arc_through case for curved runs. It does not explicitly name alternatives or give a when-not-to-use rule, so it stops short of full routing guidance.

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