opentakeoff-mcp

Overview Schema Source Related Servers Discussions Admin

apply_rules

Reapply correction rules to a takeoff to automatically deduct repeated issues such as mechanical chases; returns per-rule results and commits one undoable batch.

Instructions

Re-run the correction rules the takeoff arrived with (#207) — the lessons an estimator TAUGHT the canvas (#88): "every room like this loses the mechanical chase." A rule is a deterministic predicate (enclosed linework islands under a size cap, inside the rule's condition's rooms), never a re-prompt. Evaluation is the same pure rules.ts engine the canvas Preview runs; the commit is the one batch the canvas's Apply makes — ONE journal entry, undo_last takes the whole batch back. Everything lands reviewed: false (this server has no review gate), and the reply's per-rule disclosure — what each rule produced, what was skipped, with ids — IS your preview: read it, then view_sheet overlay:true. Idempotent by construction: any candidate an existing deduct already covers is dropped by the engine, so re-running after new rooms commit is the intended workflow and never double-deducts. Rules arrive ONLY via import_takeoff (minting a new rule is an estimator's correction and stays behind the canvas's human Preview→Apply gate); with none imported this refuses. Pass sheet to scan one sheet; omit it to scan every sheet holding the rules' rooms. Uncalibrated and scanned-raster sheets come back in skipped_sheets, named.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "apply_rules"
  }
}

Input Schema

Name	Required	Description	Default
`sheet`	No	Scan only this sheet (default: every sheet holding the rules' conditions' rooms)

Output Schema

Name	Required	Description
`note`	Yes
`rules`	Yes
`committed`	Yes	Deducts committed across all rules — 0 is a result (idempotence)
`skipped_rules`	Yes	Rules not evaluated, named — never silently dropped
`skipped_sheets`	Yes	Sheets that could not be scanned (uncalibrated, or scanned raster with no linework mask)
`total_deduct_sf`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedv0.1.31Nov 7, 2026
- removedInput schema / additionalProperties
```
Removed value: -false
```
- addedOutput schema / properties / committed / maximum
```
Added value: +9007199254740991
```
- addedOutput schema / properties / committed / minimum
```
Added value: +-9007199254740991
```
- addedOutput schema / properties / rules / items / properties / produced / maximum
```
Added value: +9007199254740991
```
- addedOutput schema / properties / rules / items / properties / produced / minimum
```
Added value: +-9007199254740991
```
Addedv0.1.15Aug 6, 2026

TDQS

A4.5/5.0

Behavior5/5

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

With no annotations supplied, the description carries the full burden and does so: it discloses the commit shape (ONE journal entry, undo_last reverts the whole batch), the review state (everything lands reviewed: false, no review gate), idempotence semantics (existing deducts cause candidates to be dropped, so no double-deduct), the refusal condition, and skipped_sheets reporting for uncalibrated/raster sheets.

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?

Front-loaded with the verb and operationally dense, but roughly 200 words for a one-parameter tool, padded with issue references (#207, #88) and narrative flourishes ('the lessons an estimator TAUGHT the canvas') that carry no selection or invocation value. The substantive facts (idempotence, batch undo, refusal, skipped_sheets) do earn their place; the styling does not.

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 an output schema and no annotations, the description covers the commit/undo model, idempotence, the no-review-gate state, the refusal edge case, and where preview information comes from. Nothing an agent needs to call this correctly and interpret the reply is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the single 'sheet' parameter is already documented with its default, so the description adds little beyond restating that default. Baseline 3 is appropriate for a one-parameter tool whose schema does the work.

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?

States a specific verb and resource ('Re-run the correction rules') and immediately disambiguates the mechanism: a deterministic predicate evaluated by the same pure rules.ts engine the canvas Preview runs, not a re-prompt. It is clearly distinguishable from siblings like import_takeoff (which creates rules) and view_sheet (which renders the overlay).

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?

Gives explicit when-to-use ('re-running after new rooms commit is the intended workflow'), when-not ('with none imported this refuses'; rules arrive ONLY via import_takeoff), and named alternatives ('read it, then view_sheet overlay:true'). It also spells out the scoping choice: pass sheet to scan one sheet, omit to scan all sheets holding the rules' rooms.

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

Deploy Server