Skip to main content
Glama

Lay a pipe run

edit_plumbing
Destructive

Lay plumbing pipe runs for cold, hot, sewer, or vent lines, choosing the cheapest feasible route and calculating required materials.

Instructions

Lay a pipe run of the plumbing project (the plumbing tool 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 the walls and inside them, or through the ceiling or under the floor, sharing the trunk, draws it (replacing the earlier run of the same points and the lines drawn by hand to them, listed in replaced_drawn) and replies {via, suggested, length_m, by_premise_m, bends, branches, materials: [[item, qty, unit]]} — water: pipe and bars, 90° elbows, tees, threaded elbows at the points, a gate valve per room, adhesive; sewer: the branch at the largest diameter it takes, the drops at each point's own, a 45° Y junction at each branch (never a 90° tee), two 45° elbows per turn, sealing rings, trap boxes. Sewer runs only under the floor, by gravity, with 2 % fall up to 75 mm and 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 (a point in no wall; from the ceiling a low point in no wall, nowhere to drop; sewer up to the ceiling or lying in a wall) is refused with why.

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, `cold`, `hot` or `sewer`
depthNoFor `route` of sewer: the height free under the finished floor, cm (slab recess, or the ceiling void of the storey below)
actionNo`route`

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
revYesPlan revision
runYesThe run: <system>:<circuit|all|ids>
viaYesWhere it runs: ceiling, floor, wall (or tape)
bendsYesBends along the run
notesNoWhat the rules say about the run
branchesNoBranches off the trunk
length_mYesMetres: {horizontal, vertical, total}
trunk_mmNoSewer: trunk diameter mm
materialsYesBill of materials: [item, quantity, unit]
slope_pctNoSewer: slope %
suggestedNoThe route the rules suggest
merged_intoNoThe run this one joined, or null
by_premise_mNoTotal metres by route: {ceiling, floor, wall}; a reason instead where one is impossible
needs_depth_cmNoSewer: depth it needs under the floor, cm
replaced_drawnNoHand-drawn lines this run replaced

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

The description fully discloses the destructive nature of the operation: it replaces the earlier run and lines drawn by hand, and it can refuse a run with a reason. It also details sewer behavior (gravity, fall percentages, depth requirements, refusal conditions) and the exact reply object, which goes well beyond the destructiveHint=true annotation.

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 dense and information-rich, with the core operation front-loaded and the sewer-specific rules appended after a clear transition. It is long, but nearly every clause adds a necessary constraint or output detail; only minor redundancy with the schema keeps it from a 5.

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 complex domain-specific tool, the description covers the route syntax, defaults, material lists, failure modes, and sewer constraints. The output schema exists, so the described reply format supplements it without needing to duplicate it. An agent has enough information to invoke route correctly and anticipate the consequences.

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 input schema already documents all six parameters with 100% coverage, so the baseline is 3. The description adds meaningful interaction semantics: how 'via' selects the premise, how 'depth' affects sewer feasibility, how 'from' defaults to the nearest source, and how 'ids' default to every point of the kind. This is valuable but partly overlaps with the schema descriptions.

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 opens with 'Lay a pipe run of the plumbing project' and explains that this is the tool that creates the run, while the 'plumbing tool reads it'. The noun 'pipe run' and the verb 'lay' name a concrete resource and action, clearly distinguishing this from the sibling 'plumbing' and other edit tools.

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 clear context on how route behaves, including when 'via' is omitted, what defaults apply, and when a run is refused. It explicitly contrasts with the 'plumbing' sibling by stating that the plumbing tool reads the result, implying edit_plumbing is used to modify or create it. It does not enumerate all alternative tools, but the guidance is sufficient for the main decision.

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