opentakeoff-mcp

Overview Schema Source Related Servers Discussions Admin

measure_polygon

Measures a closed polygon you define by vertices to compute area and perimeter at the sheet's scale. Requires scale set; supports condition and deduct role.

Instructions

Measure a closed polygon you supply (min 3 vertices, image px): area_sf and perimeter_lf at the sheet's scale. Requires the scale to be set. Pass condition to commit it; role "deduct" subtracts. A room ring belongs on the innermost wall-face strokes from get_sheet_vectors, crossing each door opening on the wall centerline and wrapping columns and stubs; never on a hatch edge, casework or a door leaf. Check it with view_sheet overlay:true on a tight crop and fix it with edit_shape. A CURVED wall is a circle: do not chord it and do not hand-tessellate it — give the bow one point on the wall and list its index in arc_through. 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	Default
`role`	No		floor_area
`sheet`	Yes
`verts`	Yes
`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
`nverts`	Yes
`area_sf`	Yes
`warning`	No	Mixed-scale warning (#153): a scale note disagreeing with the sheet's sits in the measured region — verify before trusting these numbers
`shape_id`	No	Present when condition was passed and the shape committed
`perimeter_lf`	Yes

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"
+}

Changed1 schema field changedv0.1.9Jul 31, 2026

addedOutput schema / properties / warning

Added value: +{
+  "description": "Mixed-scale warning (#153): a scale note disagreeing with the sheet's sits in the measured region — verify before trusting these numbers",
+  "type": "string"
+}

Addedv0.1.2Jul 17, 2026
Removedv0.1.1Jul 17, 2026
First observedJul 15, 2026

TDQS

A4.4/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 does well: it discloses the scale prerequisite, that condition commits vs a bare measurement, that role 'deduct' subtracts, and that arcs are baked to vertices on commit with origin.curved stamped. It does not cover failure handling beyond the arc refusal note (which lives in the schema) or idempotency, so it is strong but not exhaustive.

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-loads purpose and units before the tracing guidance, and every clause is task-relevant for a takeoff tool. It is dense and long - the room-ring and curved-wall paragraphs could be tighter - but nothing is filler.

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?

Complete for a complex geometry tool: coordinate convention (image px, render scale 2.0, origin top-left, y down), units in both px and pt, prerequisites, arc semantics, and a verify-then-fix workflow. An output schema exists, so return values need not be restated.

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?

Schema coverage is only 20%, so the description must compensate and largely does: it explains verts (min 3, image px), role ('deduct' subtracts, default floor_area), condition (commit), and the arc_through curved-wall pattern including where to place the point. Only 'sheet' is left to inference, which is low risk given the surrounding context.

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?

Names a specific verb and resource (measure a closed polygon you supply) and states the concrete outputs (area_sf and perimeter_lf at the sheet's scale). This clearly separates it from measure_line and measure_surface without needing to open any 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?

Gives real usage context: state must be set first, pass condition to commit, use role 'deduct' to subtract, verify with view_sheet overlay:true and fix with edit_shape. It stops short of naming measure_line/measure_surface as the alternatives for non-polygon work, so selection vs those siblings is left implicit.

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