Skip to main content
Glama

The New Engineer — HVAC

check_en378_zones

Read-onlyIdempotent

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?

The description discloses key behavioral traits beyond the annotations: result is 'provisional' and carries 'questions_to_ask' when inputs are missing, with instruction to ask one or two at a time then call again. It also specifies output behavior (per volume, from answer_outline) and constraints like 'C.3 is never used.' These add value on top of the readOnlyHint and idempotentHint annotations.

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 long but dense and well-structured: it opens with scoping, then configurations, then usage caveats. Each sentence carries substantive domain information without filler. It is verbose by necessity given the 11 parameters and 4 configurations, but remains readable and front-loaded.

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 (11 params, 4 configurations, multiple standards), the description is fully complete: it covers scope, exclusions, sibling routing, configuration definitions, required inputs, provisional behavior, and standards involved. With an output schema present, not explaining return values is appropriate; nothing an agent needs to call it correctly is missing.

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 baseline is 3. The description adds domain-level semantics: it maps the four configurations to parameter requirements, e.g., split systems need floor area and mounting pose for formula C.2, and clarifies access categories. This helps the agent choose and validate parameters beyond the schema definitions.

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 specific verb and resource: 'EN 378 applied to BUILDING projects, volume by volume.' It distinguishes itself from sibling check_refrigerant_switzerland by explicitly clarifying this tool answers safety in the room, not market/refill restrictions. The scope (building services) is also clearly delineated.

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?

The description gives explicit when-to-use and when-not-to-use guidance: 'THIS TOOL ANSWERS SAFETY IN THE ROOM. It says NOTHING about whether the refrigerant may still be placed on the market or refilled... that is check_refrigerant_switzerland.' It also names alternatives for mixed questions and excludes cold rooms/food/industrial refrigeration.

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