Skip to main content
Glama

The New Engineer — HVAC

check_en378_zones

Read-onlyIdempotent

DETERMINISTIC: the same inputs always give the same result — from any AI, on any day. Figures come from the standard's tables and formulas, never from a language model's estimate. Every step is auditable.

EN 378 applied to BUILDING projects, volume by volume.

An installation does not occupy one room but several: the machine, the rooms crossed by refrigerant lines, the rooms served by indoor units. Each volume is classified on its own — access category (a/b/c) and location class (I–IV) — and each classification calls for its own measures. The tool answers per volume, never as a single verdict.

It returns, for every volume: its classification and why, the charge limit from Tables C.1 and C.2 of EN 378-1 (with the C.2 formula computed when the table calls for it), whether the charge exceeds it, the EN 378-3 measures that follow, the applicable texts (EN 378-1 to -4, EN IEC 60079-10-1, SUVA 66139 and 2153) and the ventilation flow rates.

FOUR CONFIGURATIONS COVER ALMOST EVERY BUILDING PROJECT. Bring the user's case back to one of them wherever possible: machine_en_local_technique chiller or heat pump, all refrigerant inside the machine, standing in a plant room -> c III enceinte_accessible_fermee all refrigerant inside a walk-in ventilated enclosure that stays closed even for maintenance -> the enclosure is c III, the room around it carries no requirement enceintes_inaccessibles one or more units, each in a manufacturer's non-accessible ventilated enclosure -> TWO analyses: the enclosure in operation (class IV, the manufacturer sizes and justifies it, ask him for the enclosure ventilation), and the plant room with the enclosure OPEN for maintenance, which comes back to c III split_traversant split or VRF outdoors, refrigerant lines crossing occupied rooms -> each room on its own; offices and their circulations are b I, and formula C.2 gives the maximum charge for the floor area, or the minimum floor area for the charge

THIS TOOL ANSWERS SAFETY IN THE ROOM. It says NOTHING about whether the refrigerant may still be placed on the market or refilled: in Switzerland that is check_refrigerant_switzerland. A question that mixes both - « may I use R-32 for 3 kg in a server room, and until when can I refill it » - needs BOTH tools: call this one for the room, and check_refrigerant_switzerland for the dates. Do not answer half the question.

NEVER guess. The refrigerant, the configuration and the charge are always needed; a split also needs the floor area and how the indoor unit is mounted (floor, wall, window, ceiling), since C.2 depends on it. Without them the result is provisional and carries questions_to_ask: ask them, one or two at a time, then call again.

Answer from answer_outline, volume by volume. In building projects, detection is preferred over treating a plant room as an ATEX zone. C.3 is never used. Say that the practical limit alone proves nothing: the charge limit of Tables C.1 and C.2 is what counts.

SCOPE: building services. Cold rooms, food refrigeration and industrial process refrigeration are a different trade.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
poseNoHow the indoor unit is mounted: on the floor, wall, window or ceiling. Formula C.2 depends on it.
languageNoThe user's language. Texts are in French: translate them.fr
charge_kgNoRefrigerant charge of the largest circuit, in kg.
acces_localNoAccess category of the plant room. Omit: 'c', authorised persons only.
refrigerantYesRefrigerant as the user wrote it: 'R-32', 'R410A', 'R290', 'R717', 'propane'…
configurationNoHow the installation is laid out. Omit if unknown: the tool returns the question to ask.
volume_local_m3NoVolume of the plant room, in m³.
volume_enceinte_m3NoVolume of the ventilated enclosure, in m³.
acces_locaux_desservisNoAccess category of the rooms crossed or served: 'b' for offices, laboratories, workplaces; 'a' for hotels, schools, shops, hospitals, homes.
volume_local_desservi_m3NoVolume of the smallest room crossed or served by an indoor unit, in m³.
surface_local_desservi_m2NoFloor area of that room, in m². Formula C.2 needs it; without it the tool returns the minimum area required instead.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive/non-openWorld, and the description goes well beyond them: determinism guarantee, the 'provisional' status with questions_to_ask when inputs are missing, the auditability of each step, and the directive that C.3 is never used and detection is preferred over ATEX treatment.

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 determinism claim and organized into scannable blocks (configurations, tool boundary, never-guess, scope). It is long, and the opening 'from any AI, on any day' line leans promotional, but nearly every sentence carries operative content.

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 11-parameter domain tool, the description covers purpose, routing, required inputs, degraded-mode behavior, and scope exclusions; with an output schema present it need not detail return shapes, and it still names the key returned fields.

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 description coverage is 100%, so the baseline is 3, but the description adds real meaning: it states which inputs are always needed (refrigerant, configuration, charge), why pose matters (C.2 depends on mounting), and that omitting configuration returns the question to ask rather than an error.

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+resource ('EN 378 applied to BUILDING projects, volume by volume') and makes the per-volume, non-single-verdict behavior explicit. It clearly differentiates from sibling check_refrigerant_switzerland by scoping itself to in-room safety, not market/refill legality.

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?

Gives explicit when-to-use via four named configurations with mapping guidance, states when BOTH tools are needed for a mixed question, and excludes out-of-scope trades (cold rooms, industrial process refrigeration). It even instructs the agent on the follow-up loop when inputs are missing.

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