Skip to main content
Glama
Meteor-Simulation

BULC MCP

Official
by Meteor-Simulation
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Spr import network

spr_import_network
Destructive

Imports and validates sprinkler pipe networks from drawings or JSON payloads, creating nodes, pipes, nozzles, drains, and water sources in one undo step.

Instructions

Create the recognised (or a hand-written) pipe network in the sprinkler module in ONE undo step: nodes, pipes (nominal size, pipe standard, C, line number, valves), nozzles (kind closed|open|drain, K, required pressure, zone, line), drains and the water source. From a drawing: candidateId (+ components, excludeSegments/Nodes/Lines/Runs, source, defaults, drains, nozzleOverrides, zoneByLine/Run/Component, valves, placement). Hand-written: network = {version:1, units:"m", nodes:[{ref,x,y,z}], pipes:[{from,to,diameter,lineNo}], heads:[{node,kind,kFactor,requiredPressure,zone}], sources:[{node,sourceType,…}]}. Water-spray ISO nozzles default to open K80 (project default: general K80, zone deluge — confirm with the user). Validates first (nothing changes on error); dryRun only reports. scriptPath saves the payload JSON (re-import later). mode append (default) | replace. Then spr_run_calc. [bulc-mcp] mode='replace' replaces the current pipe network; call with dryRun=true first (DRW-009).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNoappend (default) adds to the current network; replace swaps it (design settings stay)
drainsNoCandidate nodes (open ends) that are drain holes — K or orifice diameter (default = nozzle K: drain hole = sprinkler orifice)
dryRunNoOnly validate and report counts, change nothing
sourceNoWater source at candidate node (default = recognised inlet): sourceType pump|city_water|gravity_tank|pressure_tank, staticPressure, residualPressure, residualFlow, pumpRatedFlow, pumpRatedHead, pumpShutoffHead (MPa / L/min), tankElevation
valvesNoValves on candidate segments: type, tag (WS-11U), zone (zone valve), open=false (closed)
networkNoHand-written import payload (SprImportPayload) instead of candidateId
defaultsNokFactor (default 80), nozzleKind (default open for water spray), requiredPressure MPa, material (pipe standard id, e.g. JIS_G3454_STPG_SCH40), cFactor, stemDiameter (25), fallbackDiameter (50)
placementNoPlace the drawing network: x,y,z offset of the inlet (m), rotateDeg about Z, mirrorY, floorIndex (story id; default by z)
zoneByRunNo{ "<run name>": "<zone>" }
componentsNoConnected components to import (default [0] = main network with the inlet)
scriptPathNoAlso save the import payload JSON to this path ("script" — can be re-imported with network=…)
zoneByLineNo{ "<lineNo>": "<zone>" } — nozzles on that line get the zone (zone deluge scenarios)
candidateIdNoFrom spr_analyze_drawing / chat attachment
excludeRunsNoRun names to drop (R05_Y_z1.7m …)
excludeLinesNoLine numbers to drop
excludeNodesNo
excludeSegmentsNoCandidate segment ids to drop (drain / air-blow / reference lines …)
nozzleOverridesNo
zoneByComponentNo{ "<component id>": "<zone>" }

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv4.0.0

TDQS

A4.7/5.0
Behavior5/5

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

Even with annotations declaring destructive/non-idempotent, the description adds real beyond-annotation behavior: the whole import is a single undo step, it validates before mutating ('nothing changes on error'), dryRun only reports, replace wipes the current network while design settings stay, and scriptPath persists the payload for re-import.

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?

Front-loaded with the core action and no filler sentences, but the body is a dense, unstructured run of parenthetical enumerations and inline JSON that is harder to parse than a segmented form would be.

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?

For a 19-parameter, 0-required, deeply nested tool with no output schema, it covers modes, validation/dry-run semantics, defaults, and the next step well. It stops short of describing what a success response reports (counts) and how append vs replace interact with existing valves/heads beyond the schema's 'design settings stay' note.

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 description coverage is already 89%, so the baseline is 3, but the description adds meaning the schema lacks: the concrete hand-written payload shape for the opaque 'network' object and the domain default (water-spray ISO nozzles default open K80, zone deluge, confirm with user).

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?

States a specific verb and resource (create the pipe network) and enumerates exactly what is created: nodes, pipes, nozzles, drains, water source. The 'in ONE undo step' and 'recognised (or hand-written)' framing distinguishes it from the granular sibling tools like spr_add_node/spr_add_pipe and from spr_analyze_drawing.

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?

Explicitly branches the two supported entry paths ('From a drawing: candidateId ... Hand-written: network = {...}'), names the upstream tool (spr_analyze_drawing) and the follow-up (spr_run_calc), and adds a hard rule for the dangerous path: 'mode=replace ... call with dryRun=true first (DRW-009)'.

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