Skip to main content
Glama
Meteor-Simulation

BULC MCP

Official

Update device

update_device
Idempotent

Change any &DEVC field on an existing device by ID or uid. Only one device is modified even if IDs are duplicated.

Instructions

Update an existing device by ID (or internal uid). Any &DEVC field can be changed; only one device is modified even with duplicate IDs. [bulc-mcp rules] DEVC-001, DEVC-003, DEVC-004 — bulc_knowledge_search ""

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesDevice ID (or uid) to update
xbNoRegion [x1,x2,y1,y2,z1,z2] — plane for flow, box for HRR/statistics, segment for beam, column for layer
iorNoWall direction for solid quantities: ±1(X) ±2(Y) ±3(Z)
xbpNoLine endpoints for points>1: [x1,x2,y1,y2,z1,z2]
xyzNoPoint position [x,y,z] (m)
delayNoAspiration transport delay (s)
depthNoDEPTH (m) for INSIDE WALL TEMPERATURE
latchNofalse → re-trips allowed (LATCH=.FALSE.; default true)
outputNofalse → omit column from devc.csv (control-only device)
pointsNo>1 → expand XBP line into N point devices (ID-01..)
ctrl_idNoCTRL reference (required for QUANTITY=CONTROL / CONTROL VALUE)
devc_idNoASPIRATION unit id (for sampling points)
duct_idNoHVAC duct id (DUCT quantities)
node_idNoHVAC node id(s) — 2 for NODE PRESSURE DIFFERENCE
part_idNoParticle class for MPUV/ADD/AMPUA etc.
prop_idNoPROP model reference (detector/sprinkler properties)
spec_idNoSpecies: OXYGEN, CARBON DIOXIDE, CARBON MONOXIDE, SOOT, WATER VAPOR, or fuel name
flowrateNoAspiration sampling flowrate (>0)
quantityNoFDS QUANTITY (e.g. TEMPERATURE, VOLUME FRACTION, MASS FLOW +, LAYER HEIGHT, PATH OBSCURATION, HRR, CONTROL)
relativeNoSubtract first output value
rotationNoRotation about orientation axis (deg)
setpointNoTrip threshold (device acts as trigger when crossed)
quantity2NoSecond quantity for COV/CORRCOEF
pipe_indexNoSprinkler pipe group (default 1)
orientationNoSensor direction vector (default 0,0,-1)
initial_stateNoStart in tripped state (INITIAL_STATE)
absolute_valueNoOutput |x|
quantity_rangeNoValue gate [min,max] for integral statistics
smoothing_timeNoSmoothing time constant (s, overrides factor)
trip_directionNo+1 ascending (default) / -1 descending crossing
bypass_flowrateNoAspiration unit bypass flowrate
smoothing_factorNoExponential smoothing 0..1
conversion_addendNoOutput = factor*x + addend (default 0)
conversion_factorNoOutput = factor*x + addend (default 1)
no_update_devc_idNoFreeze this output when the referenced device trips
spatial_statisticNoMEAN, MAX, MIN, VOLUME MEAN/INTEGRAL, MASS MEAN/INTEGRAL, AREA INTEGRAL, SUM, VOLUME, MASS (needs xb)
temporal_statisticNoTIME AVERAGE, RUNNING AVERAGE, MAX, MIN, MAX TIME, MIN TIME, TIME INTEGRAL, RMS, COV, CORRCOEF, SMOOTHED

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv4.0.0

TDQS

B3.4/5.0
Behavior4/5

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

Annotations already declare the write/idempotent/non-destructive profile, but the description adds real context beyond them: "Any &DEVC field can be changed" and the duplicate-ID single-device guarantee. It stops short of 5 because it says nothing about permissions, side effects on dependent outputs, or reversibility.

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?

Two tight sentences with the core action front-loaded, followed by a short rules reference. Appropriate length for a 37-parameter tool, though the bracketed bulc fragment is slightly opaque.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Annotations cover the safety profile and the schema fully documents parameters, so the description only needs to convey purpose and scope, which it does. However, for a highly complex 37-field mutation with no output schema, it omits any note on field interactions (e.g. ctrl_id requirements) that would make it complete.

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 all 37 parameters are already documented in the schema, which sets the baseline at 3. The description only adds the generic "any &DEVC field can be changed" note, contributing no field-level semantics beyond 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 specific verb and resource ("Update an existing device by ID (or internal uid)") and clarifies mutation scope ("only one device is modified even with duplicate IDs"). It does not explicitly name sibling tools like add_device/remove_device to differentiate, so it stops short of the top band.

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

Usage Guidelines2/5

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

The description offers no when-to-use or when-not-to-use guidance and never points to an alternative tool (e.g. add_device for creation, remove_device for deletion). The bulc reference is about rule compliance, not usage selection, so this is close to no guidance.

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