Skip to main content
Glama

Lay a pipe run

edit_plumbing
Destructive

Lay pipe runs for cold, hot, sewer, or vent plumbing from source to points via wall, floor, or ceiling; replaces prior runs and returns length, bends, and materials.

Instructions

Lay a pipe run of the plumbing project (plumbing reads it). route {kind: cold|hot|sewer|vent, ids?, via?: ceiling|floor|wall, from?, depth?} lays the run from its source to the points along and inside the walls, through the ceiling or under the floor, sharing the trunk; it replaces the earlier run of the same points and the lines drawn by hand to them (replaced_drawn) and answers {via, suggested, length_m, by_premise_m, bends, branches, materials: [[item, qty, unit]]}. Sewer runs only under the floor, by gravity (2 % fall up to 75 mm, 1 % above): the reply says needs_depth_cm, and with depth a run that does not fit is refused saying how much it needs. Without via the cheapest premise that can be built is taken; one that cannot is refused with why. Fittings and what is refused: rules topic=plumbing.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idsNoFor `route`: the points; default every point of the kind
viaNoFor `route`: `ceiling`, `floor` or `wall`; omitted, the cheapest that can be built
fromNoFor `route`: the piece it starts from (a water meter, a valve, the heater, the inspection box or stack); default the nearest of its kind
kindNoFor `route`: what the run carries
depthNoFor `route` of sewer: the height free under the finished floor, cm (slab recess, or the ceiling void of the storey below)
actionNoThe change to make

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
revYes
runYes
viaYes
bendsYes
notesNo
branchesNo
length_mYes
trunk_mmNo
materialsYes
slope_pctNo
suggestedNo
merged_intoNo
by_premise_mNo
needs_depth_cmNo
replaced_drawnNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed20 schema fields changedv3.0.0
    • changedInput schema / properties / action / description
      Previous value: -"`route`"New value: +"The change to make"
    • addedInput schema / properties / action / enum
      Added value: +[
      +  "route"
      +]
    • removedInput schema / properties / ids / default
      Removed value: -[]
    • changedInput schema / properties / kind / description
      Previous value: -"For `route`: what the run carries, `cold`, `hot` or `sewer`"New value: +"For `route`: what the run carries"
    • addedInput schema / properties / kind / enum
      Added value: +[
      +  "cold",
      +  "hot",
      +  "sewer",
      +  "vent"
      +]
    • removedOutput schema / properties / bends / description
      Removed value: -"Bends along the run"
    • removedOutput schema / properties / branches / description
      Removed value: -"Branches off the trunk"
    • removedOutput schema / properties / by_premise_m / description
      Removed value: -"Total metres by route: {ceiling, floor, wall}; a reason instead where one is impossible"
    • removedOutput schema / properties / length_m / description
      Removed value: -"Metres: {horizontal, vertical, total}"
    • removedOutput schema / properties / materials / description
      Removed value: -"Bill of materials: [item, quantity, unit]"
    • removedOutput schema / properties / merged_into / description
      Removed value: -"The run this one joined, or null"
    • removedOutput schema / properties / needs_depth_cm / description
      Removed value: -"Sewer: depth it needs under the floor, cm"
    • removedOutput schema / properties / notes / description
      Removed value: -"What the rules say about the run"
    • removedOutput schema / properties / replaced_drawn / description
      Removed value: -"Hand-drawn lines this run replaced"
    • removedOutput schema / properties / rev / description
      Removed value: -"Plan revision"
    • removedOutput schema / properties / run / description
      Removed value: -"The run: <system>:<circuit|all|ids>"
    • removedOutput schema / properties / slope_pct / description
      Removed value: -"Sewer: slope %"
    • removedOutput schema / properties / suggested / description
      Removed value: -"The route the rules suggest"
    • removedOutput schema / properties / trunk_mm / description
      Removed value: -"Sewer: trunk diameter mm"
    • removedOutput schema / properties / via / description
      Removed value: -"Where it runs: ceiling, floor, wall (or tape)"
  2. First observedv0.1.0

TDQS

A4.1/5.0
Behavior5/5

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

Annotations already flag destructiveHint=true, and the description substantiates it: the new run 'replaces the earlier run of the same points and the lines drawn by hand to them (replaced_drawn)'. It further discloses refusal behavior (needs_depth_cm, why a premise can't be built), gravity/fall limits, and the reply payload — rich context well beyond the annotations.

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?

Purpose is front-loaded, but the body is a run-on wall of nested parentheticals and conditionals that is hard to parse on first read. Most sentences carry real information, yet the structure could be broken into clearer condition/behavior lines.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description needn't spell out returns, yet it still sketches the reply shape. Combined with annotations covering the destructive profile, it is essentially complete — only the absence of usage exclusions/alternatives keeps it short of full marks.

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 schema baseline carries most semantics; the description still adds value on defaults and constraints, notably the sewer `depth` meaning (free height under the finished floor, slab recess or storey-below void) and the 2%/1% fall rule tied to that parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb+resource: laying (routing) a pipe run of a kind (cold/hot/sewer/vent) in the plumbing project, and notes that `plumbing` reads it and `rules` topic=plumbing governs fittings. It distinguishes the routing action clearly from read-only siblings, though the core purpose is somewhat buried under dense conditional detail.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives concrete applicability conditions: sewer runs only under the floor, by gravity, with specific falls; without `via` the cheapest buildable premise is chosen; an unbuildable one is refused with the reason. It also routes the agent to `rules` for fittings/refusals, but never states explicit when-not-to-use or a direct alternative tool for routing.

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