Skip to main content
Glama
U-C4N
by U-C4N

Plant: Pipe Takeoff

pipe_takeoff

Generate a pipe takeoff from P&ID and layout drawings: build run topology, measure lengths, group rows by room, service, and diameter, then export XLSX/CSV.

Instructions

A pipe takeoff: topology from the P&ID, lengths from the layout, rows by room x service x diameter.

The P&ID gives the runs (junctions merged, tees split, a line drawn twice counted once, valves and reducers bridged), each run's service (the layer, overridden by a supply / return word near the line), its diameters exactly as labelled (direct, carried by continuity - never across a reducer - or unassigned) and the equipment tags at its ends. The length comes from the layout unless the scale check calls the P&ID to scale: the rectilinear minimum spanning tree of the run's tag positions on the layout, each connection along x first then y, plus vertical_allowance per connection. The P&ID's drawn length stays beside it as schematic_m, never as the answer. Lengths are metres from the unit the geometry implies; an INSUNITS that disagrees is a warning, never a factor. Status A / B / C per run: a C run (an end on no equipment, a tag missing from or written twice on the layout) is on the Kontrol sheet with its schematic length, counted in the total and flagged.

Read-only on both drawings. With output it writes one workbook - Metraj, Özet, Kontrol, Metodoloji - as XLSX and, always, as CSV beside it.

Refused before a drawing is read: lang outside tr / en / ru, an unknown service or length source, an allowance outside 0-1, a negative vertical allowance, a non-positive tolerance, and length_source='layout' without a layout. A missing, unreadable or oversize drawing is refused by the reader, which names MAX_DXF_BYTES. Refused after the scale check: length_source='pid' on a P&ID it calls schematic, unless force=True (the refusal quotes the statistics). Without openpyxl the XLSX is not written and files.refused carries capability: "xlsx_write" naming the office extra; the CSV files are written all the same.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tolNoLine ends closer than this (P&ID drawing units) are one junction; default 1 mm in the unit the P&ID's geometry implies (1.0 on a millimetre drawing, 0.001 on a metre one).
langNoHeaders and method text: tr | en | ru.en
forceNoWith length_source='pid', measure on a P&ID the scale check calls schematic anyway.
layersNoP&ID layers holding the lines; default every layer the vocabulary files under piping or electrical with confidence >= 0.9.
outputNoWorkbook to write (.xlsx); the four sheets are also written as CSV beside it. Omit to return the rows only.
pid_pathNoThe P&ID (DXF headlessly; DXF or DWG on a live seat). Omit to read the current drawing as the P&ID.
servicesNoServices to take off; default product, cip_supply, cip_return. Also: glycol_supply, glycol_return, steam, condensate, cold_water, hot_water, ice_water, compressed_air, drain, electrical, unknown.
allowanceNoAllowance as a share of the net length (0.20 = 20 %); its own column.
layout_pathNoThe layout of the same plant. Omitted, every length is the P&ID's drawn length and is marked scale_verified: false.
length_sourceNoauto | pid | layout. auto measures on the P&ID only when the scale check calls it to scale, else on the layout.auto
exclude_regionsNoIds of reported detail copies (detail_copies: D1, D2 ...) whose runs repeat pipes drawn elsewhere and are left out. Omitted, every copy is counted.
vertical_allowanceNoMetres added per connection for rises and drops (layout lengths).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.6.0

TDQS

A4.6/5.0
Behavior5/5

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

With annotations only saying readOnlyHint=false / destructiveHint=false, the description carries the burden and does it well: it clarifies it is 'read-only on both drawings' while writing one workbook plus CSVs, describes the A/B/C run statuses and the Kontrol sheet, and enumerates pre-read and post-scale-check refusals plus the openpyxl capability failure path (files.refused with capability xlsx_write). Nothing about side effects or failure modes is left to inference.

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 definition is front-loaded in the first sentence and nearly every following sentence carries real information about topology rules, length sourcing, or refusals. It is dense prose without headings, so a 370-word wall is harder to scan than bullets would be, but it is not padded.

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 12-parameter, high-complexity tool it covers outputs (Metraj/Ozet/Kontrol/Metodoloji workbook and CSV), validation and refusal behavior, capability fallbacks, and the P&ID-vs-layout length decision. An output schema exists, so return values need not be described, and nothing essential for a correct call is missing.

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 already 100%, so the baseline is 3, but the description adds conceptual meaning the schema does not: what counts as one junction (ends closer than tol, tees split, a line drawn twice counted once, valves/reducers bridged), why diameters are 'never carried across a reducer', and how vertical_allowance applies per connection on layout lengths. That is genuine semantic enrichment beyond the field text.

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 opening line names a specific verb+resource ('A pipe takeoff') and immediately decomposes it: topology from the P&ID, lengths from the layout, rows by room x service x diameter. That is far more specific than siblings like bom_extract, data_extract or cable_takeoff, and an agent can tell what artifacts this produces without opening the schema.

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?

The description gives rich conditional usage context: it explains when length comes from the layout vs the P&ID, when `force=True` is required, when `length_source='layout'` is impossible, and enumerates the refusal cases before and after the scale check. It never names a sibling alternative (e.g. cable_takeoff or bom_extract) for routing purposes, so it is clear context without exclusions.

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

Deploy Server

Other Tools