Skip to main content
Glama
Meteor-Simulation

BULC MCP

Official

Spr set pipes

spr_set_pipes
Idempotent

Set pipe standard, material, Hazen-Williams C, and line numbers across selected pipes or runs in one bulk operation, with one undo step per change.

Instructions

Change many pipes at once: choose all / pipeIds / lineNo / runOf (the run through that pipe up to branches); set the pipe standard (material, C resets unless keepC), Hazen-Williams C, line number. One undo step per change. Out-of-standard sizes keep their size (inner diameter = nominal) and are reported. [bulc-mcp rules] SPR-003, SPR-005, SPR-021 — bulc_knowledge_search ""

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
allNo
keepCNoKeep each pipe C when changing the standard
runOfNoSelect the run through this pipe id (stops at branches, ends and the source)
lineNoNoSelect pipes with this line number
cFactorNoNew Hazen-Williams C
pipeIdsNo
materialNoPipe standard id (schedule included). Building: KSD3507 | CPVC | STS304 | ASTM_SCH40. Marine/plant: JIS_G3454_STPG_SCH40/SCH80, KS_D3562_SPPS_SCH40/SCH80, JIS_G3452_SGP, JIS_G3459_SUS_SCH10S/SCH40, ASTM_A53_A106_SCH40/SCH80, DIN86019_CUNI10FE (CuNi 90/10), … (enum). C resets to the standard default unless cFactor is given.
setLineNoNoNew line number ("" removes)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv4.0.0

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare the safety profile (readOnly=false, destructive=false, idempotent=true), so the bar is lower, and the description still adds real behavior: 'One undo step per change' (undo grouping), 'C resets unless keepC' (silent value reset), and out-of-standard pipes keeping nominal size and being reported. These are genuinely useful mutation side-effects.

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-loads the core operation and is dense with no filler, though the second sentence is a long multi-clause run-on that mixes selection, setting, undo, and reporting in one breath. Still, every sentence earns its place.

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?

No output schema and no required parameters, so the description must carry the behavior, and it does: selection modes, what gets set, C-reset semantics, undo atomicity, and out-of-standard handling. Only an explicit pointer to spr_update_pipe for single-pipe edits 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?

With 75% schema coverage the schema carries most of the load, but the description adds meaning: it explains keepC's effect on C, ties cFactor to Hazen-Williams C, clarifies setLineNo, and defines runOf as 'the run through that pipe up to branches'. It complements rather than repeats the schema.

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?

States a concrete verb and resource with scope: 'Change many pipes at once' plus the selection modes and the attributes it can set. The phrase 'many pipes at once' implicitly distinguishes it from the single-pipe sibling spr_update_pipe, though that sibling is never named.

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

Usage Guidelines3/5

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

Describes how to select pipes (all / pipeIds / lineNo / runOf) which implies usage context, but gives no explicit when-to-use-this-vs-spr_update_pipe guidance and no exclusions or prerequisites. The bulc rule references hint at governance but don't route the agent between tools.

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