Skip to main content
Glama
bewygs

CFAST MCP

by bewygs

update_device

Modify an existing device's properties such as location, type, material, or threshold, while preserving its device identifier.

Instructions

Update an existing device (target or detector).

Selects the device by device_id and changes only the parameters you provide; any left as None is unchanged. The device's id is the selector and is not changed here.

Parameters

model_id : str Id of the model to modify. device_id : str Id of the device to update. comp_id : str or None, optional Compartment in which the device is located. None leaves it unchanged. location : list[float] or None, optional Position [x, y, z] from the left wall, front wall and floor. Default units: m. None leaves it unchanged. type : str or None, optional One of PLATE, CYLINDER, HEAT_DETECTOR, SMOKE_DETECTOR, SPRINKLER. None leaves it unchanged. material_id : str or None, optional What the target is made of; must already exist. None leaves it unchanged. surface_orientation : str or None, optional Predefined surface orientation for targets. None leaves it unchanged. normal : list[float] or None, optional Unit vector [nx, ny, nz] perpendicular to the target surface. None leaves it unchanged. thickness : float or None, optional Thickness of the target material. Default units: m. None leaves it unchanged. temperature_depth : float or None, optional Depth at which the internal target temperature is reported (meters when depth_units="M", else a fraction in [0, 1]). None leaves it unchanged. depth_units : str or None, optional Units for temperature_depth: "M" for meters. None leaves it unchanged. setpoint : float or None, optional Activation temperature for HEAT_DETECTOR and SPRINKLER. Default units: °C. None leaves it unchanged. rti : float or None, optional Response Time Index. Default units: (m·s)^(1/2). None leaves it unchanged. obscuration : float or None, optional Obscuration at or above which a SMOKE_DETECTOR activates. Default units: %/m. None leaves it unchanged. spray_density : float or None, optional Amount of water dispersed by a sprinkler. Default units: m/s. None leaves it unchanged.

Returns

str Confirmation, the updated model summary, and any warnings.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
rtiNo
typeNo
normalNo
comp_idNo
locationNo
model_idYes
setpointNo
device_idYes
thicknessNo
depth_unitsNo
material_idNo
obscurationNo
spray_densityNo
temperature_depthNo
surface_orientationNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior4/5

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

Without annotations, the description must disclose behavior. It explains partial update semantics ('changes only the parameters you provide; any left as None is unchanged') and notes that device_id is unchanged. No mention of error conditions or permissions, but basic behavioral traits are covered.

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 description is appropriately long for a parameter-heavy tool. It starts with a concise behavioral summary, then a structured Parameters section. No redundant information, though some units could be standardized in a separate note.

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?

Given the complexity (15 params, no annotations, output schema exists), the description is quite complete. It covers update behavior, parameter explanations, and return type. Could mention that some parameters are device-type-specific, but overall sufficient.

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

Parameters5/5

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

Schema description coverage is 0%, so the description carries full burden. It provides detailed explanations for each of the 15 parameters, including units, constraints, and applicability (e.g., activation temperature for detectors). This greatly exceeds the schema which only has type info.

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 description clearly states 'Update an existing device (target or detector).' with a specific verb and resource. It distinguishes from siblings like add_device by focusing on updating an existing device.

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 explicitly explains that only provided parameters are changed and that device_id is the selector. It gives clear context for use but does not explicitly mention when not to use (e.g., to add a device use add_device).

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/bewygs/cfast-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server