opentakeoff-mcp

Overview Schema Source Related Servers Discussions Admin

scope_merge

Resolve overlapping floor shape collisions by trimming the loser to its remainder with an exact boolean difference, or deleting it when overlap is near-total. One undoable journal step.

Instructions

Resolve ONE collision (#366): given a pair of floor shapes and the winner, the loser gives up the shared floor — TRIMMED to its remainder by an exact boolean difference (the cut_out module's own arithmetic; its quantities re-measured from the result), or DELETED outright when the overlap is near-total (≥ 98% of the loser: the same space claimed twice, not a room with a sliver left). One journal step either way; undo_last restores the loser verbatim. Who wins: state winner; with it omitted the reviewed shape wins over a pending one, and the verb refuses when neither is reviewed (it does not guess which condition the floor belongs to) or when BOTH are (that is the estimator's call — the collision shows on both condition rows in the canvas). The ink rule is absolute: a loser the estimator affirmed is refused whoever you name. A trim that would split the loser into disjoint pieces refuses — that is a re-trace decision, not a merge — and a loser carrying reconciled cutouts refuses (delete the cuts first).

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": {
      "shape_a": "<shape_a>",
      "shape_b": "<shape_b>"
    },
    "name": "scope_merge"
  }
}

Input Schema

Name	Required	Description
`winner`	No	Which of the two keeps the shared floor; omit to let the reviewed one win
`shape_a`	Yes	One shape of the pair (from scope_duplicates)
`shape_b`	Yes	The other

Output Schema

Name	Required	Description
`note`	Yes
`loser`	Yes
`action`	Yes
`winner`	Yes
`shared_sf`	Yes
`loser_holes`	No	trimmed: holes the remainder carries (a winner inside the loser leaves one)
`shape_count`	Yes
`loser_after_sf`	Yes
`loser_before_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 / loser_holes / maximum
```
Added value: +9007199254740991
```
- addedOutput schema / properties / loser_holes / minimum
```
Added value: +-9007199254740991
```
- addedOutput schema / properties / shape_count / maximum
```
Added value: +9007199254740991
```
- addedOutput schema / properties / shape_count / minimum
```
Added value: +-9007199254740991
```
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?

No annotations are supplied, so the description carries the full burden and meets it: it discloses the destructive outcome (trimmed by exact boolean difference vs DELETED outright at the 98% overlap threshold), that quantities are re-measured from the result, that it is a single journal step, and that undo_last restores the loser verbatim. The permission-like "ink rule" that an estimator-affirmed loser cannot be merged is exactly the kind of precondition that is invisible in structured fields.

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 core action and its two outcomes are front-loaded before the edge cases, and every clause carries decision-relevant content. It is a single dense paragraph with heavy parenthetical nesting and in-house jargon (#366, the ink rule), which costs some scannability for an agent parsing it cold.

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 three parameters and an output schema, everything an agent needs is present: the two possible outcomes, the threshold that selects between them, the winner-resolution rule, the full refusal set, and the recovery path. Return shape is covered by the output schema, so no explanation of return values is owed.

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: it explains that winner omission is resolved by reviewed-vs-pending status and that ambiguity in either direction causes refusal, which the schema only hints at with "omit to let the reviewed one win." It also frames the pair as winner/loser with a near-total-overlap consequence, though it does not say what identifier form shape_a/shape_b take beyond their scope_duplicates origin.

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?

Opens with a specific verb and resource scoped tightly: "Resolve ONE collision (#366): given a pair of floor shapes and the winner, the loser gives up the shared floor." It explicitly distinguishes itself from the detection sibling (scope_duplicates, named in the schema), from cut_out (whose arithmetic it reuses), and from undo_last (which reverses it), so the agent can place it in the workflow without opening another 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?

Gives explicit routing rules: state winner, or omit it to let the reviewed shape win, and it names the exact refusal conditions (neither reviewed, both reviewed, estimator-affirmed loser, trim that would split the loser, loser with reconciled cutouts). Each refusal points at the correct alternative action — re-trace, delete the cuts first, or an estimator decision — rather than leaving the agent to guess.

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

Deploy Server