European HVAC sizing: EN 12828 expansion vessels, EN 378 zones, Swiss refrigerant rules.
Scored across 3 tools
Each tool targets a clearly separate problem: refrigerant safety in rooms, Swiss refrigerant market legality, and expansion vessel sizing. The descriptions explicitly cross-reference each other to avoid boundary confusion.
All tool names use the same snake_case verb-first structure: check_en378_zones, check_refrigerant_switzerland, size_expansion_vessel. The verbs differ by function but the recognizable <verb>_<target>_<modifier> pattern is consistent throughout.
Three tools is within the reasonable range and each tool is substantial, earning its place. It is slightly thin for the broad 'HVAC' server name, but each tool covers a distinct, well-scoped engineering task.
The refrigerant-related tools together handle mixed safety and legality questions well, and the expansion vessel tool is self-contained. However, the broad HVAC branding leaves obvious gaps such as load calculation, duct sizing, and other system design tasks, so the surface is far from complete.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| pose | No | How the indoor unit is mounted: on the floor, wall, window or ceiling. Formula C.2 depends on it. | |
| language | No | The user's language. Texts are in French: translate them. | fr |
| charge_kg | No | Refrigerant charge of the largest circuit, in kg. | |
| acces_local | No | Access category of the plant room. Omit: 'c', authorised persons only. | |
| refrigerant | Yes | Refrigerant as the user wrote it: 'R-32', 'R410A', 'R290', 'R717', 'propane'… | |
| configuration | No | How the installation is laid out. Omit if unknown: the tool returns the question to ask. | |
| volume_local_m3 | No | Volume of the plant room, in m³. | |
| volume_enceinte_m3 | No | Volume of the ventilated enclosure, in m³. | |
| acces_locaux_desservis | No | Access category of the rooms crossed or served: 'b' for offices, laboratories, workplaces; 'a' for hotels, schools, shops, hospitals, homes. | |
| volume_local_desservi_m3 | No | Volume of the smallest room crossed or served by an indoor unit, in m³. | |
| surface_local_desservi_m2 | No | Floor area of that room, in m². Formula C.2 needs it; without it the tool returns the minimum area required instead. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
Swiss refrigerant regulation check (ORRChim / ChemRRV annex 2.10, OFEV synthesis of May 2026, rules adopted 29.10.2025) plus refrigerant data from EN 378-1 Annex E: GWP (AR4, the ORRChim basis), ODP, LFL, safety class, practical limit.
Returns, for a given refrigerant and installation: the date from which machines using it can no longer be placed on the Swiss market (import from 01.01.2027, sale to third parties from 01.07.2027), the date from which filling with virgin refrigerant is banned, the period when only reclaimed refrigerant may be used, and the date from which all filling is banned.
SCOPE: heating, air conditioning, building cooling and process cooling, data centres included. NOT food refrigeration, cold rooms or deep freezing: those are a different trade, and the tool declines them instead of answering.
Use it whenever the user asks about a refrigerant in Switzerland — its GWP / PRG, flammability, whether a chiller, heat pump, split, VRF or cold room using it may still be sold or refilled — in any language: fluide frigorigène, Kältemittel, refrigerante, refrigerant, R-32, R-410A, R-290, CO2, NH3...
The answer depends on the installation. The regulation distinguishes:
use (building cooling, food refrigeration medium / low temperature / combined /
deep freezing, process cooling, heat pump mainly for heating, ice rink), cooling
capacity Q0K or heating capacity Q0H, self-contained (factory-built packaged
unit) or not, split, direct expansion (incl. VRF), secondary coolant loop
(chilled water / brine), air-cooled condenser and refrigerant charge.
THIS TOOL ANSWERS ONE QUESTION ONLY: may the refrigerant still be sold and
refilled in Switzerland, and until when. It says NOTHING about safety in the
room - charge limits, machine room, detection, ventilation, ATEX. That is
check_en378_zones. 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 dates, and check_en378_zones for the room. Do not answer half the
question.
NEVER guess these. Call the tool with what the user gave: it returns
provisional: true, the possible scenarios, and questions_to_ask in the
order that matters most. Ask them (one or two at a time), then call again.
Natural refrigerants need no questions. Build your answer on answer_outline;
quote exceptions as possible, never as granted.
| Name | Required | Description | Default |
|---|---|---|---|
| split | No | True for a split system (indoor/outdoor units linked by refrigerant lines laid on site). Omit if unknown. | |
| language | No | The user's language, for labels. French or English text; translate for de/it/es. | en |
| application | No | Use of the installation: 'climatisation_batiment' (building cooling, incl. reversible heat pump used mainly for cooling), 'froid_alimentaire_positif' (food/perishables, use temp ≥ 0 °C), 'froid_alimentaire_negatif' (≥ −25 °C), 'froid_alimentaire_combine' (multiplex medium + low temp with common discharge), 'surgelation' (< −25 °C), 'froid_process' (industrial process cooling), 'pac_chauffage' (heat pump mainly for heating), 'patinoire_permanente', 'patinoire_temporaire'. Omit if unknown. | |
| refrigerant | Yes | Refrigerant designation as the user wrote it: 'R-32', 'R410A', 'R1234ze', 'CO2', 'propane'… | |
| heat_recovery | No | True if rejected heat is recovered. | |
| self_contained | No | True if 'autonome': factory-built circuits in a frame/casing and no gas-carrying part connected on site (packaged chiller, monobloc heat pump, rooftop). Omit if unknown. | |
| gwp_if_unlisted | No | ONLY if a previous call said the refrigerant is not in the database: its GWP (AR4) from the manufacturer's datasheet, given by the user. | |
| odp_if_unlisted | No | ONLY with gwp_if_unlisted: its ODP (0 for HFC/HFO). | |
| direct_expansion | No | True if the refrigerant evaporates directly in the room units / evaporators (DX, incl. VRF); False if it cools a water or brine loop. Omit if unknown. | |
| evaporator_count | No | Number of evaporators. | |
| secondary_circuit | No | True if cold is distributed through a secondary coolant loop (chilled water, glycol, brine). Omit if unknown. | |
| family_if_unlisted | No | ONLY with gwp_if_unlisted: 'naturel' (natural), 'stable' (contains any HFC/PFC — e.g. R-454B, R-454C, R-455A), 'hfo' (only HFO and/or natural components). | |
| cooling_capacity_kw | No | Peak useful cooling capacity Q0K, kW. Omit if unknown. | |
| heating_capacity_kw | No | Peak useful heating capacity Q0H, kW (heat pumps). Omit if unknown. | |
| air_cooled_condenser | No | True if heat is rejected through an air-cooled condenser (heat pump: its air heat exchanger). Omit if unknown. | |
| refrigerant_charge_kg | No | Total refrigerant charge, kg. Omit if unknown. | |
| refrigerant_circuit_count | No | Number of refrigerant circuits. | |
| simultaneous_heating_cooling | No | True for simultaneous heating and cooling with at least 2 air heat exchangers. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool read-only, idempotent, and non-destructive; the description adds a genuinely valuable behavioral contract: provisional results, scenarios, questions_to_ask, answer_outline, out-of-scope refusal, and multilingual label behavior. There is no contradiction with the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long, but the complexity of the domain justifies it: 18 parameters, legal nuances, and a sibling boundary. It is well organized and front-loaded with the legal dates and scope before workflow instructions, and the multilingual/refrigerant examples are useful rather than padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema already exists, so the description need not restate return fields. It supplies the missing operational context: when to ask clarifying questions, how to split mixed questions across tools, language handling, and scope/refusal behavior. An agent has everything needed to invoke and iterate with the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents all 18 parameters at 100% coverage, so the baseline is high. The description adds why those parameters matter—legal distinctions by application, capacity, self-contained/split, direct expansion vs secondary loop, and charge—and clarifies that natural refrigerants need no follow-up questions. The only minor weakness is a slight tension between the food-refrigeration exclusion and the food-refrigeration enum values in the schema, though the description frames those as decline cases.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a precise service: Swiss refrigerant market/refill ban dates under ORRChim/ChemRRV, with the specific legal sources named. It explicitly distinguishes itself from check_en378_zones and narrows the tool to a single question, so an agent cannot confuse it with its sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit trigger ('whenever the user asks about a refrigerant in Switzerland'), an explicit exclusion (food refrigeration, cold rooms), and names the sibling tool for room-safety questions. It also handles the mixed-question case by telling the agent to call both tools, and instructs the agent to ask clarifying questions rather than guess.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Size the expansion vessel and pressurisation of a closed heating or chilled-water circuit to EN 12828: static height, minimum pressure p0, fill pressure pa, final pressure pe, expansion volume, water reserve, nominal vessel volume with the standard vessel to buy, safety valve setting together with the minimum it must not fall below, pressure class of the lowest equipment, intermediate vessel when needed.
Heights become pressures through the real density of the fluid, at the temperature that matters for each: the coldest for p0, the design temperature for the valve and the lowest point. Water and glycols therefore give different figures for the same height.
Use it whenever the user asks to size or check an expansion vessel, pressurisation unit, pre-charge pressure or safety valve — in any language: vase d'expansion, maintien de pression, Ausdehnungsgefäss, Druckhaltung, vaso di espansione, vaso de expansión.
Needs the installation water volume and THREE heights, all measured from the point where the expansion vessel connects to the network:
the highest point of the installation, above it;
the lowest point, usually below it (negative) or level with it;
the safety valve, which always sits on the heat generator or
chiller. If the user does not know it, it is assumed 1 m above
the vessel connection, and the result says so.
Ask the user for the volume and the three heights before calling.
NEVER invent a height: if the lowest point or the valve height is
unknown, omit it. The result is then marked provisional and lists
the questions to ask. Build your answer on answer_outline: it
carries the assumptions, the questions and the link to the website,
which measures all of these on the user's IFC model.
| Name | Required | Description | Default |
|---|---|---|---|
| fluid | No | Heat-transfer fluid: 'eau' (Water), 'meg' (MEG), 'mpg' (MPG), 'tyfocor' (TYFOCOR L (MPG)). Omit: plain water. | |
| language | No | The user's language, for labels and alerts. | en |
| glycol_pct | No | Glycol concentration in %, ignored for water. Defaults to 30 %. | |
| installation | No | 'chauffage' for heating, 'refroidissement' for cooling / chilled water. Omit: heating. | |
| pressurisation | No | Type of pressurisation: 'statique' (Pressure-maintained by gas cushion (Statico)), 'compresseur' (Compressor-driven (Compresso)), 'pompe' (Pump-driven (Transfero)). Omit: gas-cushion vessel. | |
| flow_temperature_c | No | Flow temperature, °C. Omit: 80 in heating, 6 in cooling. | |
| design_temperature_c | No | Hottest the fluid ever gets, standstill included. Omit: the warmer of flow and return in heating, 40 °C in cooling. | |
| return_temperature_c | No | Return temperature, °C. Omit: 60 in heating, 12 in cooling. | |
| filling_temperature_c | No | Temperature at which the circuit is filled, °C. Omit: 10. | |
| installation_volume_l | Yes | Total water content of the closed circuit, in litres: pipes, emitters, generator, buffer tank. | |
| lowest_point_from_unit_m | No | Height of the REAL lowest point of the installation - the lowest drain - relative to the point where the expansion vessel connects to the network, in metres. NEGATIVE when below it, 0 when the vessel connects at the lowest point. Taken as given: no margin is added. Ask the user. NEVER invent it: if the user has not given it, omit it - the result is then marked provisional and returns the question to ask. | |
| safety_valve_from_unit_m | No | Height of the safety valve relative to the point where the expansion vessel connects to the network, in metres. The safety valve always sits on the heat generator (boiler, heat pump) or chiller - tell the user so, it helps them find it. Ask for it; if they cannot say, omit it: it is then assumed 1 m above the vessel connection, and the result says so. | |
| safety_valve_setting_bar | No | Safety valve setting in bar, one of the standard settings. Omit to take the smallest standard setting that works here. A setting below the minimum the installation needs is raised, and the result says so. | |
| highest_point_above_unit_m | Yes | Height of the REAL highest point of the installation - the top air vent - above the point where the expansion vessel connects to the network, in metres. Taken as given: no margin is added. | |
| minimum_required_pressure_bar | No | Pressure the installation requires at the pressurisation unit whatever the height - against cavitation at a pump suction, for instance. p0 never falls below it. Omit: zero. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and destructiveHint=false, so the tool is known to be safe. The description goes far beyond this: it explains the conversion of heights to pressures via real fluid density, the no-margin treatment of heights, the default 1 m assumption for the safety valve when unknown, and the rule "NEVER invent a height: if the lowest point or the valve height is unknown, omit it. The result is then marked provisional and lists the questions to ask." This gives the agent clear expectations about outputs and assumptions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than the average but well structured: purpose first, then the height-pressure principle, a clear usage trigger, a bulleted list of required heights, and a final imperative about not inventing values. Each sentence carries information needed to call the tool correctly, with minimal redundancy. The translated terms list is slightly long but useful for multilingual user requests.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's 15 parameters and rich input schema, the description covers all critical context: what to ask the user, how to handle unknown heights, the assumption behavior, and the need to build the answer on `answer_outline`. It also accounts for provisional results and how the website measures heights on an IFC model. The output schema exists, so return-value details are not required in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% parameter description coverage, so the baseline is 3. The description adds meaning beyond the schema by explaining the common reference point for all heights ("the point where the expansion vessel connects to the network") and the omission behavior for unknown heights. It also connects fluid choice to pressure differences ("Water and glycols therefore give different figures for the same height"), which reinforces parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: "Size the expansion vessel and pressurisation of a closed heating or chilled-water circuit to EN 12828," then enumerates the concrete outputs (static height, p0, pa, pe, expansion volume, nominal vessel volume, valve setting, etc.). This clearly distinguishes it from the sibling tools, which concern refrigerant zones and Swiss refrigerant checks, even though it does not name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: "Use it whenever the user asks to size or check an expansion vessel, pressurisation unit, pre-charge pressure or safety valve — in any language," and lists translations. It also gives pre-call guidance: "Ask the user for the volume and the three heights before calling." It does not explicitly mention sibling alternatives or exclusions, but the domain is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_en378_zonescheck_refrigerant_switzerlandsize_expansion_vessel27 engineering compliance and calculation tools for the built environment (UK, EU, UAE).
Design, solve and simulate HVAC systems from real components, weather years and buildings.
BTU sizing, window-seal length, heatwave outlook, running costs, balcony solar subsidies (DE/EU).
Your building's energy in real time: smart-me meters, load profiles, EV charging, ZEV billing
Add one secure layer between your agents and this server.
