Skip to main content
Glama

edit_materials

Add, remove, or patch supporting-materials rows on a condition to convert measured area, length, count, or seam length into purchase quantities using coverage rates.

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).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "condition": "<condition>"
    },
    "name": "edit_materials"
  }
}

Input Schema

NameRequiredDescriptionDefault
addNoNew rows to add
patchNoField changes on existing rows
removeNoExisting row ids to remove
conditionYesFinish tag, e.g. 'CPT-1'

Output Schema

NameRequiredDescriptionDefault
changedYes
conditionYesThe finish tag passed in
materialsYesThe condition's full materials array after this write
condition_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.1.31
    • removedInput schema / additionalProperties
      Removed value: -false
    • removedInput schema / properties / add / items / additionalProperties
      Removed value: -false
    • removedInput schema / properties / patch / items / additionalProperties
      Removed value: -false
    • addedInput schema / properties / patch / items / properties / fields / propertyNames
      Added value: +{
      +  "type": "string"
      +}
  2. Changed6 schema fields changedv0.1.14
    • 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"
      +}
  3. Addedv0.1.6

TDQS

A4.6/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 it discloses the important traits: no review gate, direct write, whole-call atomicity on a bad id ('404s the WHOLE call before anything is written'), auto-minting of new conditions, and one-step reversibility via undo_last restoring the snapshotted materials array verbatim. The remaining gap is that it doesn't describe validation failure modes per-field or partial-success behavior beyond the 404 case.

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 definition is front-loaded with the core action before the seam_lf digression, and most sentences carry operational weight. The 20-ft-room versus two-10-ft-rooms illustration is long for a tool description, but it earns some of its space by justifying why seam_lf cannot be derived from area or perimeter.

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 everything an agent needs before writing: row shape, formula, default behaviors, id sourcing, atomicity, minting rules, and undo semantics. Return values need not be explained because an output schema exists, yet the description still references reading row ids from the reply.

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 genuine meaning beyond the schema: it states the formula (basis total ÷ per, rounded up to whole units unless round:false) and explains that seam_lf is a figured roll-layout length rather than a measured basis. That is real semantic enrichment, though the patch/remove id semantics are only lightly elaborated beyond the schema.

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 precise verb triad and resource: 'Add, remove, or patch supporting-materials rows on a condition,' and immediately defines what those rows are (coverage-rate lines converting area/linear/count into order quantity). It distinguishes itself from siblings by naming edit_condition for roll_setup and export_takeoff/takeoff_summary as the id source, so an agent can route correctly without opening schemas.

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?

Explicit usage conditions are given: 'add alone is enough to seed materials on a condition before you've traced anything,' while remove/patch require existing row ids 'from this reply or export_takeoff,' and takeoff_summary is flagged as stripping materials. It also redirects roll-layout configuration to edit_condition rather than this tool, which is an effective when-not signal.

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