opentakeoff-mcp

Overview Schema Source Related Servers Discussions Admin

edit_materials

Add, remove, or patch supporting-materials rows on a condition to convert measured area, length, or count into order quantities using coverage rates (e.g., adhesive, grout, seam tape).

Instructions

Add, remove, or patch supporting-materials rows on a condition — the coverage-rate lines that turn a measured area/length/count into an order quantity (adhesive at N sf/gal, grout at N lf/bag, …), matching the canvas's per-condition Supporting Materials panel. Each row is {name, per, basis, unit, round, note}: quantity = the condition's basis total (area/linear/count/seam_lf) ÷ per, rounded up to whole purchase units unless round:false. basis "seam_lf" is the one basis that is FIGURED rather than measured: it is the length where two cuts meet on the floor, read off the condition's roll layout (set roll_setup with edit_condition), which is what a heat-weld rod or a carpet seam tape is bought by. A 20-ft-wide room off a 12-ft roll seams once down its length; the same square footage as two 10-ft rooms seams not at all, and no percentage of the area or the perimeter can tell those two jobs apart. Without a roll_setup — or with no committed floor shapes to lay out — a seam_lf row reads 0, which is the honest state rather than a guess. condition names an existing OR NEW finish tag (minted on first touch, same as measure_polygon) — add alone is enough to seed materials on a condition before you've traced anything. remove/patch target existing row ids from this reply or export_takeoff (takeoff_summary strips materials for a compact quantities-only reply); a bad id 404s the WHOLE call before anything is written, and referencing an id on a tag with no condition yet errors rather than silently minting an empty one. No review gate here — materials rows are quantity config, not traced geometry, so this edits directly; undo_last reverses a call in one step (the condition's whole materials array, snapshotted before the write, restored verbatim).

Input Schema

TableJSON Schema

Name	Required	Description
`add`	No	New rows to add
`patch`	No	Field changes on existing rows
`remove`	No	Existing row ids to remove
`condition`	Yes	Finish tag, e.g. 'CPT-1'

Output Schema

TableJSON Schema

Name	Required	Description
`changed`	Yes
`condition`	Yes	The finish tag passed in
`materials`	Yes	The condition's full materials array after this write
`condition_id`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedv0.1.14Aug 4, 2026

changedInput schema / properties / add / items / properties / basis / description

Previous value: -"Which of the condition's totals this row divides against — default 'area' (total SF)"New value: +"Which of the condition's totals this row divides against — default 'area' (total SF). 'seam_lf' is the figured roll-layout seam length (weld rod, seam tape), 0 until the condition carries a roll_setup"

changedInput schema / properties / add / items / properties / basis / enum

Previous value: -[
-  "area",
-  "linear",
-  "count"
-]New value: +[
+  "area",
+  "linear",
+  "count",
+  "seam_lf"
+]

changedOutput schema / properties / materials / items / properties / basis / description

Previous value: -"Which of the condition's totals this row's quantity is computed against"New value: +"Which of the condition's totals this row's quantity is computed against — 'seam_lf' is the FIGURED roll-layout seam length (weld rod, seam tape), 0 until the condition carries a roll_setup"

changedOutput schema / properties / materials / items / properties / basis / enum

Previous value: -[
-  "area",
-  "linear",
-  "count"
-]New value: +[
+  "area",
+  "linear",
+  "count",
+  "seam_lf"
+]

addedOutput schema / properties / materials / items / properties / inherited

Added value: +{
+  "description": "On a twin: true while the row still follows the family — a patch on it takes it local, split_condition freezes them all",
+  "type": "boolean"
+}

addedOutput schema / properties / materials / items / properties / origin_id

Added value: +{
+  "description": "On a twin: the parent row this one follows (the variants.ts family link)",
+  "type": "string"
+}

Addedv0.1.6Jul 27, 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 carries the full behavioral burden and does so: no review gate (direct edit), a 404 aborts the whole call before any write, referencing an id on a tag with no condition errors rather than silently minting, seam_lf reads 0 without a roll_setup, and undo_last restores the snapshotted materials array verbatim in one step.

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?

It is front-loaded with the core action, but the ~250-word body includes an extended digression on seam geometry ('a 20-ft-wide room off a 12-ft roll seams once down its length...') that reads as documentation rather than crisp tool guidance. Informative sentences, but the volume costs discoverability/scannability.

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?

An output schema exists, so return values need not be explained. For a 4-param mutation tool the description covers row semantics, the seam_lf edge case, seeding behavior, id resolution sources, error semantics, and undo — nothing an agent needs before calling it is missing.

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 100%, so the baseline is 3, but the description adds real meaning: the row shape {name, per, basis, unit, round, note}, the quantity formula (basis total ÷ per, rounded up unless round:false), and the conceptual distinction that seam_lf is figured rather than measured. This goes beyond restating the schema's field docs.

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+resource: 'Add, remove, or patch supporting-materials rows on a condition'. It defines what those rows are (coverage-rate lines that turn a measured quantity into an order quantity) and routes to siblings like edit_condition and takeoff_summary by name, so an agent can distinguish it without opening a 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?

It states explicitly that 'add' alone can seed materials on a condition before anything is traced, that remove/patch consume existing row ids from this reply or export_takeoff, and that takeoff_summary strips materials for a compact reply. Alternatives (takeoff_summary, export_takeoff, edit_condition for roll_setup) and their selection conditions are named.

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