Skip to main content
Glama
Meteor-Simulation

BULC MCP

Official

Add prop

add_prop

Add a &PROP device model for FDS simulations, using quantity presets and optional overrides; reference it from devices via prop_id.

Instructions

Add a &PROP device model. quantity presets seed standard defaults: 'LINK TEMPERATURE' (heat detector link), 'SPRINKLER LINK TEMPERATURE', 'CHAMBER OBSCURATION' (smoke detector), 'THERMOCOUPLE' (bead). Override any field. Reference from devices via prop_id. Every other FDS 6.10.1 spray key (mass flow, pressure/flow ramp, particle velocity, orifice, parcels, spray pattern shape/table, smokeview id …) goes in spray with the spr_upsert_spray_profile.prop key names. [bulc-mcp rules] DEVC-009 — bulc_knowledge_search ""

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesPROP model ID
rtiNoResponse Time Index
sprayNoOther &PROP spray keys (spr_upsert_spray_profile.prop names, FDS units)
beta_cNo
beta_eNo
lengthNoSmoke chamber length (m)
offsetNoDroplet insertion offset (m)
alpha_cNo
alpha_eNo
part_idNoDroplet particle class
c_factorNoConduction factor
k_factorNoSprinkler K-factor
quantityYesPROP quantity preset (see description)
flow_rateNoSprinkler flow (L/min)
spray_angleNo
bead_densityNo
bead_diameterNo
bead_emissivityNo
bead_specific_heatNo
operating_pressureNo(bar)
initial_temperatureNo(°C)
activation_obscurationNoSmoke setpoint (%/m)
activation_temperatureNo(°C)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv4.0.0

TDQS

A4.1/5.0
Behavior4/5

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

With annotations already declaring it a non-readonly, non-idempotent, non-destructive write, the description adds real context: presets seed defaults, any field can be overridden, and unlisted FDS 6.10.1 spray keys must be routed through `spray` using spr_upsert_spray_profile.prop names. It does not say what happens on a duplicate id, which is the main residual gap.

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 core action, then preset meanings, then the spray-routing rule. Dense but each sentence carries information; the trailing '[bulc-mcp rules] DEVC-009 …' fragment is somewhat cryptic but adds a pointer.

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 23-param mutation tool with no output schema, the description covers the two hardest concepts (preset semantics and spray-key routing). Missing only duplicate-id behavior and a note on units beyond what the schema already labels.

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?

Schema coverage is only 61% across 23 params, so the description must compensate and does: it enumerates the four quantity preset values with their meanings and explains the escape-hatch `spray` object. Many numeric physics fields (rti, beta, k_factor, bead_*) still rely on the schema's terse descriptions.

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 plus resource ('Add a &PROP device model') and immediately distinguishes it from siblings like update_prop/remove_prop by describing the preset-seeding behavior. An agent can tell what is created and how it is referenced (prop_id from devices).

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?

Explains the preset choice for quantity and points to bulc_knowledge_search for rules, which implies when the presets apply. However it never states when to reach for add_prop over add_device/add_heat_detector/add_sprinkler or when a preset vs full override is preferred, so alternatives are only implied.

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