The New Engineer — HVAC

water_content_from_vessel

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.

Deduce the water content of an installation from the expansion vessel already fitted.

WHAT THIS IS FOR. Refurbishment, and site visits with no drawings. Sizing a new vessel, a new pump or a new generator needs the water content, and on an existing installation nobody has it: the drawings are lost, or never matched what was built. The vessel on the wall is the one piece of evidence still standing, and it was chosen from that very figure.

ASK THE OPERATOR FIRST. Whoever filled or refilled the system knows the real figure — from the meter, the filling station, or the maintenance log — and that figure beats any deduction. This tool is what you use when nobody knows, or to check a number that looks wrong. It gets the conversation moving; it does not close it.

HOW. The sizing calculation is run backwards: a trial water content is fed to the EN 12828 sizing, the resulting vessel is compared with the one on site, and the trial is adjusted until they match. The formulas are never rewritten in reverse — the answer cannot contradict the direct calculation, because it is the same code.

WHAT THE ANSWER IS WORTH. A vessel is picked from a catalogue range: a 200 L unit covers everything needing between 141 and 200 L. The result is therefore A RANGE, never a single figure. And an oversized vessel — common — will overstate the content. Compare the range with what you see on site; it does not replace looking.

It also assumes the vessel was sized correctly in the first place. If it was not, the deduction inherits the mistake — which is itself worth knowing: a range far from what the installation plainly holds means the vessel is wrong, and that is a finding in its own right.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`fluid`	No	Heat-transfer fluid: 'eau' (Water), 'meg' (MEG), 'mpg' (MPG), 'tyfocor' (TYFOCOR L (MPG)).	water
`installation`	No	'heating' or 'cooling'.	heating
`glycol_percent`	No	Glycol concentration in %, ignored for water.
`pressurisation`	No	How pressure is held: 'static' for a plain membrane vessel, 'compressor' for a compressor unit (Compresso and the like), 'pump' for a pump unit. A compressor or pump unit holds the pressure itself, so height and valve setting play no part.	static
`static_height_m`	No	Height of the highest point above the vessel, in metres. Required for 'static' only — a compressor or pump unit does not use it.
`vessel_volume_l`	Yes	Nominal capacity of the expansion vessel actually installed, in litres — read it on the nameplate.
`max_temperature_c`	No	HIGHEST temperature the fluid can reach, °C — in extreme conditions, running OR stopped. In heating it is the flow temperature. In cooling it is not the regime at all: a stopped chiller lets the water warm to ambient — 40 °C outdoors, 30 °C indoors in a temperate climate. This is what fixes the expansion.
`min_temperature_c`	No	LOWEST temperature the fluid can reach, °C — including a breakdown, not just normal running. Indoors, 10 °C. Outdoors, 0 °C, or down to the freezing point of the glycol mix. This is what fixes the reference volume.
`valve_setting_bar`	No	Safety valve setting, bar. Required for 'static' only.
`fill_temperature_c`	No	Temperature the water was at when the system was filled, °C. 10 °C is the usual mains temperature indoors. Ask, or state the assumption.
`flow_temperature_c`	No	Design flow temperature, °C. In heating this is the highest the water reaches.
`return_temperature_c`	No	Design return temperature, °C.

Schema Changelog

Changes observed during successful MCP inspections.

Changed11 schema fields changedOct 4, 2026
- addedInput schema / properties / flow_temperature_c / anyOf
```
Added value: +[
+  {
+    "maximum": 200,
+    "minimum": -50,
+    "type": "number"
+  },
+  {
+    "type": "null"
+  }
+]
```
- addedInput schema / properties / flow_temperature_c / default
```
Added value: +null
```
- removedInput schema / properties / flow_temperature_c / maximum
```
Removed value: -200
```
- removedInput schema / properties / flow_temperature_c / minimum
```
Removed value: --50
```
- removedInput schema / properties / flow_temperature_c / type
```
Removed value: -"number"
```
- addedInput schema / properties / return_temperature_c / anyOf
```
Added value: +[
+  {
+    "maximum": 200,
+    "minimum": -50,
+    "type": "number"
+  },
+  {
+    "type": "null"
+  }
+]
```
- addedInput schema / properties / return_temperature_c / default
```
Added value: +null
```
- removedInput schema / properties / return_temperature_c / maximum
```
Removed value: -200
```
- removedInput schema / properties / return_temperature_c / minimum
```
Removed value: --50
```
- removedInput schema / properties / return_temperature_c / type
```
Removed value: -"number"
```
- changedInput schema / required
```
Previous value: -[
-  "vessel_volume_l",
-  "flow_temperature_c",
-  "return_temperature_c"
-]New value: +[
+  "vessel_volume_l"
+]
```
AddedSep 29, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, but the description goes well beyond them: the answer is 'A RANGE, never a single figure', oversized vessels overstate the result, and the deduction inherits any original sizing mistake. That is real disclosure of result semantics and failure modes, not repetition.

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?

Sectioned and front-loaded with the differentiator (determinism, reversed sizing), and every heading (WHAT THIS IS FOR / HOW / WHAT THE ANSWER IS WORTH) carries useful content. It is longer than strictly needed and the determinism claim is restated, but there is little true filler.

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 12-parameter tool with no output schema, the description supplies the missing result-shape information (a range), the key assumption (vessel was correctly sized) and auditability. It does not describe output structure in more detail, but combined with a fully documented schema this is close to complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all 12 parameters, including defaults, ranges and the static/compressor distinction. The description adds conceptual context (what fixes expansion, what fixes reference volume) but no parameter-level semantics beyond the schema, so the baseline 3 applies.

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 and resource — deduce the water content of an installation from the fitted expansion vessel — and immediately frames itself against the forward calculation ('the sizing calculation is run backwards'), which is exactly the sibling size_expansion_vessel. An agent can identify what it does and how it differs from the forward sizing tool.

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?

Explicit sequencing: 'ASK THE OPERATOR FIRST' identifies the preferred source, and 'This tool is what you use when nobody knows, or to check a number that looks wrong' gives a precise when-to-use condition. It also states when it is appropriate (refurbishment, site visits with no drawings).

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

All The New Engineer — HVAC tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?