Skip to main content
Glama
Meteor-Simulation

BULC MCP

Official
by Meteor-Simulation
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Spr add sprinkler head

spr_add_sprinkler_head

Add a sprinkler head to an existing node in BULC MCP, using a shared spray profile with optional per-head FDS and particle overrides.

Instructions

Add a sprinkler head to an existing sprinkler node. The head follows a shared spray profile (sprayProfileId, default = project default profile); K / activation temperature / RTI default to that profile. spray / particle override single FDS &PROP / &PART keys for this head only. [bulc-mcp rules] SPR-010, SPR-011 — bulc_knowledge_search ""

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
rtiNoResponse Time Index (m·s)^½ (default: profile, 100 standard; quick response ≤ 50)
zoneNoDeluge zone tag (zone scenarios open only that zone)
sprayNoPer-head FDS &PROP overrides — same keys as spr_upsert_spray_profile.prop (e.g. {"particles_per_second":10000,"spray_angle":[0,70]}).
lineNoNoLine number
nodeIdYesSprinkler node ID
kFactorNoK-Factor in metric L/(min·bar^½) (default: profile K, 80 ≈ K5.6 US; US value × 14.41)
disabledNoExclude from the calculation (plugged / under repair)
headTypeNopendant | upright | sidewall (pendant and upright both spray downward — upright only changes SMOKEVIEW_ID)
particleNoPer-head FDS &PART droplet overrides — same keys as spr_upsert_spray_profile.part (e.g. {"diameter":800,"age":600}).
nozzleKindNoclosed = heat-activated sprinkler (default), open = open nozzle (deluge / water spray, discharges from the start), drain = drain hole (always open orifice, no required pressure)
nozzleModelNoNozzle model / datasheet name
activationTempNoActivation temp (°C, default: profile, 68)
coverageRadiusNoCoverage radius (m, default 2.3)
sprayProfileIdNoShared spray profile id (spr_list_summary / spr_upsert_spray_profile)
requiredPressureNoRequired discharge pressure of THIS nozzle [MPa] (0.1 MPa = 1 bar). Empty = design default per kind (spr_set_defaults)
orificeDiameterMmNodrain: orifice diameter [mm] → K = 0.66643·Cd·d²

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv4.0.0

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare non-readOnly, non-idempotent, non-destructive behavior, lowering the bar. Beyond that, the description discloses the defaulting model (K/activation temp/RTI inherit from the shared spray profile) and the override scope (spray/particle affect 'this head only'), which is genuine behavioral context not carried by 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the primary action, then the defaulting and override semantics in tight clauses. The trailing bulc rule reference is short and non-disruptive; there is minimal wasted text.

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 16-parameter creation tool with no output schema but full annotation coverage, the description supplies the key conceptual model (shared profile defaults plus per-head overrides) an agent needs to call it correctly. It omits error/precondition behavior for a missing node, but the essentials are present.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all 16 parameters, including defaults, enums, and units. The description reinforces the sprayProfileId/default relationship but adds little syntax or meaning beyond what the schema provides, so the baseline 3 applies.

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 ('Add a sprinkler head to an existing sprinkler node'), with the attachment scope made explicit. This clearly distinguishes it from siblings such as spr_update_sprinkler_head, spr_remove_sprinkler_head, spr_add_node, and add_nozzle without the agent needing to open another schema.

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?

The description implies the use case (extending an existing node with a head) and points at the bulc rule set (SPR-010/SPR-011) for deeper guidance. However, it never explicitly states when to use this vs alternatives like spr_update_sprinkler_head or spr_set_nozzles, so usage is only implied rather than spelled out.

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