opentakeoff-mcp

Overview Schema Source Related Servers Discussions Admin

propose_condition_edit

Propose condition changes (tag rename, waste %, height, multiplier) and hold them as pending diffs for estimator acceptance. Calculations stay unchanged until approved; rationale required.

Instructions

PROPOSE a change to a condition instead of making it (#365): a diff — a new finish tag (rename), waste %, ×N multiplier, height_ft, roll_setup — held PENDING until the estimator accepts it from the panel. edit_condition is the wrong power for "I think this condition is wrong": a tag rename or a knob change should be a decision the estimator makes, not one they discover. Until acceptance NOTHING changes — takeoff_summary and export_report keep computing from the current values and carry the diff beside them (proposed_condition_edits), and once accepted the report is byte-for-byte what a direct edit_condition would have produced (the same write path). Only fields that differ from the current value are recorded; a proposal that changes nothing is refused, and a rename onto a tag another condition already carries is refused (two conditions on one tag would make one unreachable). One pending diff per condition — proposing again replaces the earlier one (undo_last restores it). rationale is required: the estimator accepts a reason.

Input Schema

TableJSON Schema

Name	Required	Description
`drop_ft`	No	Proposed default vertical leg DOWN for the condition's linear runs (#441)
`rise_ft`	No	Proposed default vertical leg UP for the condition's linear runs (#441)
`condition`	Yes	Finish tag of an EXISTING condition, e.g. 'CPT-1'
`height_ft`	No
`rationale`	Yes	Why — the schedule row, the spec section, the sheet note that decided it
`waste_pct`	No
`finish_tag`	No	Proposed new tag (a rename)
`multiplier`	No
`roll_setup`	No	Proposed roll-goods setup, or null to propose opting out

Output Schema

TableJSON Schema

Name	Required	Description
`note`	Yes
`current`	Yes
`proposed`	Yes
`condition`	Yes
`rationale`	Yes
`proposal_id`	Yes
`condition_id`	Yes
`replaced_proposal_id`	No	Present when this proposal replaced an earlier pending one on the same condition

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv0.1.25Sep 25, 2026

addedInput schema / properties / drop_ft

Added value: +{
+  "description": "Proposed default vertical leg DOWN for the condition's linear runs (#441)",
+  "minimum": 0,
+  "type": "number"
+}

addedInput schema / properties / rise_ft

Added value: +{
+  "description": "Proposed default vertical leg UP for the condition's linear runs (#441)",
+  "minimum": 0,
+  "type": "number"
+}

addedOutput schema / properties / current / properties / drop_ft
```
Added value: +{
+  "type": "number"
+}
```
addedOutput schema / properties / current / properties / rise_ft
```
Added value: +{
+  "type": "number"
+}
```

Addedv0.1.21Sep 12, 2026

TDQS

A4.8/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 thoroughly: changes stay PENDING, nothing changes until acceptance, accepted results match edit_condition exactly, no-op and duplicate-tag proposals are refused, and one pending diff is allowed per condition. It even explains the write path and undo behavior.

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 long, but dense and justified given the tool's complexity and the number of behavioral edge cases it must convey. The opening phrase front-loads the core purpose, and the rest is mostly high-signal detail rather than padding.

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 tool with no annotations, the description covers when to use it, what changes, what does not change, refusal conditions, persistence semantics, and interactions with edit_condition and undo_last. An output schema exists, so omitting return-value details is acceptable.

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?

The description adds meaning by naming the changeable fields (finish tag, waste %, multiplier, height_ft, roll_setup) and emphasizing that only differing fields are recorded and rationale is required. It does not discuss drop_ft/rise_ft, but those already have schema descriptions, so the gap is minor.

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 states a specific action (propose a change) on a specific resource (a condition) and distinguishes it from the sibling edit_condition. It enumerates the kinds of changes allowed, making the tool's purpose unambiguous.

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?

The description explicitly says edit_condition is the wrong power for 'I think this condition is wrong' and positions propose_condition_edit as the proper decision-for-the-estimator path. It also explains replacement, refusal, and undo interactions, giving clear conditions for correct use.

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