Skip to main content
Glama
bewygs

CFAST MCP

by bewygs

add_device

Add a target or detector to a compartment in a CFAST model. Configure material, orientation, and activation parameters for fire simulation.

Instructions

Add a device (target or detector) to a compartment of a model.

Devices are either targets (PLATE, CYLINDER), which heat up and report temperature, or detectors (HEAT_DETECTOR, SMOKE_DETECTOR, SPRINKLER). The compartment comp_id must already exist. Required fields depend on the type: targets need material_id (already added with add_material) and exactly one of normal or surface_orientation; HEAT_DETECTOR and SPRINKLER need setpoint and rti (SPRINKLER also spray_density).

Parameters

model_id : str Id of the model to modify. id : str Unique name of the target or detector. comp_id : str Compartment in which the device is located. location : list[float] Position [x, y, z] as distances from the left wall, the front wall, and the floor. Default units: m. type : str One of PLATE, CYLINDER (targets), HEAT_DETECTOR, SMOKE_DETECTOR, SPRINKLER (detectors). material_id : str or None, optional What the target is made of; must already exist in the model. Required for target types (PLATE, CYLINDER). surface_orientation : str or None, optional Predefined surface orientation for targets: CEILING, FRONT WALL, BACK WALL, LEFT WALL, RIGHT WALL or FLOOR. Provide exactly one of surface_orientation or normal for a target. normal : list[float] or None, optional Unit vector [nx, ny, nz] perpendicular to the exposed target surface (e.g. [0, 0, 1] faces the ceiling). Provide exactly one of normal or surface_orientation for a target. thickness : float or None, optional Thickness of the target material; if None, the material's value is used. Default units: m. temperature_depth : float, optional Depth at which the internal target temperature is reported. With depth_units="M" (default) an absolute depth in meters from the front surface, which must be > 0 and less than the material thickness; otherwise a fraction of the thickness in [0, 1]. Default value: 0.5. depth_units : str, optional Units for temperature_depth: "M" for meters. Default value: M. setpoint : float or None, optional Temperature at or above which the link activates. Default units: °C. Required for HEAT_DETECTOR and SPRINKLER. rti : float or None, optional Response Time Index for the sprinkler or detector. Default units: (m·s)^(1/2). Required for HEAT_DETECTOR and SPRINKLER. obscuration : float, optional Obscuration at or above which a SMOKE_DETECTOR activates. Default units: %/m, default value: 23.93 %/m. spray_density : float or None, optional Amount of water dispersed by a sprinkler. Default units: m/s. Required for SPRINKLER.

Returns

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYes
rtiNo
typeYes
normalNo
comp_idYes
locationYes
model_idYes
setpointNo
thicknessNo
depth_unitsNoM
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?

With no annotations provided, the description carries the full burden. It discloses prerequisites (compartment must exist, material must be added via add_material), parameter dependencies (exactly one of normal or surface_orientation for targets), and default values/units (e.g., temperature_depth default 0.5, depth_units default 'M'). It does not explicitly mention error handling or idempotency, but covers most behavioral aspects thoroughly.

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 well-structured with a clear introductory sentence, a bullet-like list of parameters, and a return section. It is comprehensive but slightly verbose; given the complexity (15 parameters), the length is justified. It could be more concise by grouping common info, but it remains readable.

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

Completeness5/5

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

Given the tool's complexity (15 parameters, conditional requirements, multiple device types) and the presence of an output schema, the description is remarkably complete. It covers prerequisites, parameter dependencies, default values, units, and return format. It does not delve into error cases but provides enough context for an agent to use the tool correctly.

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?

The schema has 0% description coverage, so the description must compensate. It does so excellently by explaining each parameter in depth: location coordinates, units, conditional requirements (e.g., material_id only for targets), default values, and the meaning of temperature_depth and depth_units. This far exceeds the minimal schema information.

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 the tool adds a device (target or detector) to a compartment, distinguishing between target and detector types. It specifies the device subtypes (PLATE, CYLINDER, etc.) and notes the prerequisite that the compartment must already exist. This clearly differentiates from sibling tools like 'add_compartment' or 'update_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 provides detailed guidance on when to use each parameter based on device type (e.g., material_id for targets, setpoint for detectors). It explains which parameters are required for which type. However, it does not explicitly state when not to use this tool (e.g., for updating an existing device, use 'update_device'). The guidelines are clear but lack explicit exclusionary context.

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