Skip to main content
Glama

The New Engineer — HVAC

apply_ifc_rules

Idempotent

Turn what you read in the overview into rules the tool replays on EVERY piece of the model, including the ones you were never shown.

NOT NEEDED ON A MODEL ALREADY TREATED: when read_ifc_overview returns 'designation_existante', the units and fans are already designated - reuse them. Posting rules REPLACES that designation entirely: do it only when the user asks to start again, or when the designation plainly contradicts what they say.

THIS IS HOW THE TOOL LEARNS A MODEL. read_ifc_overview gives you one line per family of types, not one per piece. You answer with RULES on those groups, and this tool applies them to the three thousand pieces. You never give a verdict piece by piece: the result stays deterministic because a program, not you, does the matching.

THEN READ THE ANSWER BACK, AND EXPECT TO POST AGAIN. The answer gives every group with the role your rules gave it and how many pieces that is. A rule that is too wide shows up on one line — « Gaine rectangulaire cadree, 471 pieces, centrale_de_traitement_d_air » is a rule that turned every duct into an air handling unit. Narrow it and post again. Calling this tool costs nothing and may be repeated as often as you need.

WHAT NEEDS A ROLE, AND WHAT DOES NOT. Plain ducts and fittings need none: they are network by nature, and the answer marks them segment_ou_raccord so you can see at a glance whether a rule caught them by mistake. What needs a role is everything else — air handling units, fans, fire dampers, balancing dampers, silencers, louvres, diffusers — plus whatever must be kept OUT of the network, such as access zones, equipment plinths or damper motors.

THREE ROLE NAMES ARE FIXED, because circuits start from them: give air handling units, monoblocs and ventilation casings the role centrale_de_traitement_d_air, fans the role ventilateur, and SMOKE EXHAUST fans - including fans that bring compensation air for smoke exhaust - the role ventilateur_desenfumage - exactly these words. A smoke fan runs only in a fire, with the ventilation stopped: a duct it shares with an air handling unit is not a plenum shared by two installations, and the tool does not cut the networks there. Read the names, families and types: « désenfumage », « DES », « smoke », « Entrauchung », « RWA ». ONLY EQUIPMENT THAT MOVES THE AIR gets one of them: a unit is a box with a fan in it. Heating and cooling coils, heat exchangers, filters, silencers, dampers, fire dampers, VAV boxes, humidifiers are NOT units: the air runs through them, they are pieces of the network. Give them another role (coil, silencer, damper...) or none - never one of the unit roles. A coil in 'equipements' is a rule that is too wide. BUT A FAMILY WHOSE NAME SAYS IT IS A UNIT IS A UNIT - CTA, AHU, UTA, monobloc, caisson, centrale, Lüftungsgerät - even when its type describes its heat recovery: « BG_CTA_Echangeur à plaques » is an air handling unit with plate heat recovery, not a heat exchanger. A heat exchanger is a network piece only when it is a separate piece in a duct run. The answer lists, under 'equipements', the GUIDs of every piece of the model that got one of these roles: that list is what trace_duct_circuits starts from, and what the pages show as units. Every other role name is yours to choose.

A MONOBLOC BUILT FROM MODULES. Many air handling units are modelled as casings set end to end, each its own piece: filter casing, coil casing, heat exchanger or heat recovery casing, humidifier, washer, fan section, damper casing, empty casing. Give every such MODULE the role composant_de_monobloc - exactly these words - and its fan section(s) the unit role as usual. The tool then joins the modules that touch each other face to face (over 0.25 m2 of contact) into ONE unit: every duct on any module becomes one of its branches, and two fans of the same casing become one unit. Only modules of a unit get this role: a coil, a filter or a silencer fitted IN a duct is a piece of the network, and an equipment frame or plinth is not a module.

ORDER THE LIST YOURSELF, most specific first, down to the most general. The fire damper rule must come before the balancing damper rule, or « damper » takes everything. Equipment must come before terminals: « VEN_MSF_MONOBLOC_SIMPLE_FLUX_REPRISE » contains « reprise », and a return-diffuser rule placed first would claim the air handling unit.

Pieces no rule catches are simply listed, with no warning and no failure: the engineer judges on the 3D view, not on a coverage report.

NEXT: once 'equipements' lists the air handling units and fans you expect, call trace_duct_circuits with only the token. It computes nothing yet: it checks that the units are connected to the networks and returns the complete list of units and fans, to choose from - see trace_duct_circuits. 'equipements' counts every piece ('pieces') but lists at most thirty names: the count, not the list, is the model.

Input Schema

NameRequiredDescriptionDefault
rulesYesYour rules, as a JSON object. The only required key is roles.liste: an ORDERED list, FIRST MATCH WINS, most specific first. Each entry is {"role": "a_name", "si_un_de": [conditions]} and may also carry si_tout_de (all must match) and sauf_si (none may match). A condition names one field or one property, and one operation: {"champ": "nom_du_type", "contient": ["cta"]} {"propriete": "Mechanical.System Name", "commence_par": ["VEN_"]} Fields: classe, predefined_type, object_type, nom_brut, classe_du_type, nom_du_type, predefined_type_du_type, element_type_du_type - the same ones read_ifc_overview shows under 'identite'. Operations, from widest to narrowest: contient (anywhere, even inside a word), mot_commence_par (at the start of a word), commence_par (start of the string), finit_par (end of the string), mot_entier (a whole word), egal (the whole string). Case and accents are ignored, and _ - . / are read as spaces. You may also pass dimensions, noms_de_systeme and debits_et_pertes; they are kept as given.
tokenYesThe model token, from ifc_upload_result or from the link the user pasted.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the annotations, the description discloses that posting REPLACES prior designation, that matching is deterministic and program-driven rather than piece-by-piece, that unmatched pieces are silently listed without warning or failure, and that 'equipements' counts every piece but names at most thirty. These are substantive behavioral details an agent could not infer from annotations alone.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

The purpose is front-loaded and section headings help navigation, but the description is extremely long and repetitive in places, with conversational asides and all-caps blocks. Much of the guidance is relevant, but it could be tightened considerably without losing meaning.

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?

For a complex, output-less tool, the description explains what the answer will contain (groups with roles and piece counts, the 'equipements' list), how to react to it, what happens to unmatched pieces, and how to proceed to trace_duct_circuits. No major operational gap remains.

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 100%, so the schema already documents the rule object, fields, operations, and ordering. The description adds essential semantics not present there: the three fixed role names (centrale_de_traitement_d_air, ventilateur, ventilateur_desenfumage), the composant_de_monobloc module role, module-joining behavior, and ordering heuristics such as fire damper before balancing damper.

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 states a precise operation: turning overview-derived rules into a deterministic classification applied to every model element. It also explicitly contrasts itself with read_ifc_overview (what you read) and trace_duct_circuits (the next step), so an agent can distinguish it from its siblings.

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

Usage Guidelines5/5

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

It gives explicit when-to-use and when-not-to-use guidance: do not post when 'designation_existante' is present unless the user asks to restart or the designation plainly contradicts them; expect to read the answer and repost to narrow over-wide rules. The alternative sibling for the next step is named.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources