Skip to main content
Glama

derive_transitions

Mint finish transitions where two tagged finishes meet: compare committed rooms, commit linear butt-joint runs under a new tag, and withhold wall-separated thresholds for manual review.

Instructions

Mint the transition where two finishes MEET (#202) — the derivation that follows derive_base, and the line an estimator draws by hand on every job. Pass the two finish tags and the tag the transition commits under (e.g. condition_a 'CPT-1', condition_b 'PT-1', condition 'T-1'), and every committed room of each is compared against every committed room of the other.

WHAT THE GEOMETRY ACTUALLY IS, because it decides what you get back: flood-traced rooms DO NOT SHARE EDGES. A trace fills to the wall linework, so two rooms across a partition are separated by four to eight inches of nothing — testing for a shared edge finds zero transitions on a real planset. What is there is proximity, in two flavours that mean completely different things:

• BUTT JOINT — the two rings run together inside ONE open space (a lobby that changes from carpet to tile with no wall between). The transition IS that run, and it commits as a linear shape under your tag, origin.derived naming both parent shapes and the measured gap.

• WALL-SEPARATED — the rings run parallel across a partition. The rooms are adjacent, but the transition is NOT the shared wall: it is a threshold, in the doorway, and NOTHING in the trace record says where the doorway is (the flood engine seals openings and reports how MUCH boundary it synthesised, never where). Committing 34 LF of threshold because two rooms share 34 LF of wall would be a wrong bid with a machine's confidence behind it. These come back in withheld — measured, with their length, their gap in inches, and an at point — as questions you answer by LOOKING (view_sheet at at, then measure_line or place_count the threshold yourself). The symbol_sweep doctrine: a near-match is never a silent commit and never a silent drop.

Tuning: max_gap_in (default 12) is how far apart two rings can be and still count as adjacent at all — raise it for thick walls, and every extra inch turns more of the plan into wall_separated questions, never into committed LF. min_run_in (default 12) drops corner artifacts. The butt-joint threshold is fixed at one inch and is not a knob: "these two finishes touch" is not a judgement call.

All-or-nothing, like derive_base: an unknown tag, a transition landing on either source tag, the same tag twice, or a sheet without a scale refuses the whole call before anything commits. The whole sweep is ONE undo step. After it, LOOK — view_sheet {overlay: true} over each run — before trusting total_lf. Coordinates are image px at render scale 2.0: PDF pt × 2, origin top-left, y down (the browser canvas's native space). Sheet payloads carry dims in both px and pt.

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_a": "<condition_a>",
      "condition_b": "<condition_b>",
      "condition": "<condition>"
    },
    "name": "derive_transitions"
  }
}

Input Schema

NameRequiredDescriptionDefault
conditionYesFinish tag the transitions commit under (minted on first use), e.g. 'T-1'. Must differ from both sources
max_gap_inNoHow far apart two rings can be and still count as adjacent, in inches (default 12 — a thick partition). Wider only produces more wall_separated QUESTIONS, never more committed LF
min_run_inNoShortest run worth reporting, in inches (default 12) — below this is a corner where two rooms clip, not a transition
condition_aYesFirst finish tag, e.g. 'CPT-1' — its committed rooms are walked, and runs are traced along their boundaries
condition_bYesSecond finish tag, e.g. 'PT-1'

Output Schema

NameRequiredDescriptionDefault
noteYes
runsYes
betweenYesThe two finish tags
total_lfYesSum of committed run lengths — butt joints only
withheldYesAdjacency across a wall: real, measured, and NOT committed — the transition there is a threshold at a doorway this cannot locate
committedYes
conditionYesThe tag the transitions committed under
withheld_lfYesShared-wall length held back — never part of total_lf

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed19 schema fields changedv0.1.31
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedOutput schema / properties / committed / maximum
      Added value: +9007199254740991
    • addedOutput schema / properties / committed / minimum
      Added value: +-9007199254740991
    • removedOutput schema / properties / withheld / items / properties / at / $ref
      Removed value: -"#/properties/runs/items/properties/at"
    • addedOutput schema / properties / withheld / items / properties / at / description
      Added value: +"Run midpoint (image px) — pass to view_sheet to look at it"
    • addedOutput schema / properties / withheld / items / properties / at / items
      Added value: +{
      +  "type": "number"
      +}
    • addedOutput schema / properties / withheld / items / properties / at / type
      Added value: +"array"
    • removedOutput schema / properties / withheld / items / properties / between_shape_ids / $ref
      Removed value: -"#/properties/runs/items/properties/between_shape_ids"
    • addedOutput schema / properties / withheld / items / properties / between_shape_ids / description
      Added value: +"The two floor_area shapes this run separates"
    • addedOutput schema / properties / withheld / items / properties / between_shape_ids / items
      Added value: +{
      +  "type": "string"
      +}
    • addedOutput schema / properties / withheld / items / properties / between_shape_ids / type
      Added value: +"array"
    • removedOutput schema / properties / withheld / items / properties / gap_in / $ref
      Removed value: -"#/properties/runs/items/properties/gap_in"
    • addedOutput schema / properties / withheld / items / properties / gap_in / description
      Added value: +"Median distance between the two rings across the run, in inches — 0-ish is one open space, 4-8 is a partition"
    • addedOutput schema / properties / withheld / items / properties / gap_in / type
      Added value: +"number"
    • removedOutput schema / properties / withheld / items / properties / length_lf / $ref
      Removed value: -"#/properties/runs/items/properties/length_lf"
    • addedOutput schema / properties / withheld / items / properties / length_lf / description
      Added value: +"Run length along the first shape's boundary"
    • addedOutput schema / properties / withheld / items / properties / length_lf / type
      Added value: +"number"
    • removedOutput schema / properties / withheld / items / properties / sheet / $ref
      Removed value: -"#/properties/runs/items/properties/sheet"
    • addedOutput schema / properties / withheld / items / properties / sheet / type
      Added value: +"string"
  2. Addedv0.1.12

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 load and does so: all-or-nothing refusal conditions (unknown tag, transition landing on a source tag, duplicate tag, sheet without scale), single-undo semantics, committed vs `withheld` output split, and the coordinate space (image px at render scale 2.0, origin top-left, y down). This is materially more than a restatement of the tool's effect.

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?

Purpose is front-loaded and the bulleted BUTT JOINT / WALL-SEPARATED split is well structured. Some rhetorical freight ('a wrong bid with a machine's confidence behind it', the symbol_sweep doctrine aside) could be trimmed without losing callable information.

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 five parameters and an output schema, the description covers the remaining burdens: what is committed versus withheld and why, the failure modes, reversibility (one undo step), and the coordinate convention. An agent can call this correctly and interpret the result without further reads.

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 baseline is 3; the description still adds decision-relevant meaning, notably that the butt-joint threshold is fixed at one inch and is not a knob, and that raising max_gap_in only produces more wall_separated questions rather than more committed linear feet. Example tag values are redundant with 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 first sentence names a specific verb and resource ('Mint the transition where two finishes MEET') and immediately positions it in the sibling sequence by naming derive_base as its predecessor. It also implicitly separates itself from measure_line/place_count by saying those are the manual follow-ups for withheld results.

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 sequencing (run after derive_base), explicit follow-up workflow ('view_sheet {overlay: true} over each run — before trusting total_lf', and for wall-separated pairs: view_sheet at `at`, then measure_line or place_count). It also names the alternative path for the ambiguous case rather than letting the agent guess.

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