Ampworth calculators

Radiator flow temperature

radiator_flow_temperature

Read-onlyIdempotent

Work out the flow temperature a heat pump must produce to heat a room through a given radiator, and the resulting MCS Heat Emitter Guide star rating, following section 4 of MGD 007.

This is the calculation that decides whether a heat pump will be cheap or expensive to run. A heat pump's efficiency falls as the water temperature rises, by roughly two to three per cent per degree, and the temperature it must produce is set by the radiators, not by the machine.

Supply the room's design heat loss in watts, from a room-by-room calculation, and the rated output of the radiator in that room. British catalogues normally quote at a mean-water-to-air difference of 50 K; if yours quotes 60, say so and the figure is restated.

The result gives the oversize factor, which is the radiator's output at 50 K divided by the room's heat loss, and converts it to a required flow temperature through the BS EN 442 output law. Star ratings run from 0 to 6, one star per five degrees of flow temperature, with six stars at 35 degrees.

Run this for every room. A house runs at the flow temperature its worst room demands, so one undersized radiator sets the running cost for the whole house.

Method from MGD 007. These calculators follow the published MCS methods, for understanding a system and checking a quotation. Anything that gets installed still needs a design and a site survey from a certified installer.

Input Schema

TableJSON Schema

Name	Required	Description
`roomTemp`	No	Internal design temperature of the room in Celsius. Defaults to 21.
`systemDeltaT`	No	Designed drop in water temperature between flow and return, in kelvin. Heat pump systems commonly use 5; boiler systems used 10 or 20. Defaults to 5.
`ratedAtDeltaT`	No	The mean-water-to-air temperature difference the rated output was quoted at. British catalogues normally quote 50; some older ones quote 60. Defaults to 50.
`roomHeatLossW`	Yes	The room's design heat loss in watts, from a room-by-room heat loss calculation. Required.
`radiatorOutputW`	Yes	Rated output of the radiator or radiators in that room, in watts, at the catalogue temperature. Required.

Output Schema

TableJSON Schema

Name	Required	Description
`notes`	Yes
`method`	Yes
`verdict`	Yes
`references`	Yes
`starRating`	Yes	Temperature star rating from the MCS Heat Emitter Guide, 0 to 6. More stars mean a lower flow temperature and a more efficient system.
`meanWaterTemp`	Yes	Average of flow and return temperature needed to deliver the room's heat loss through this radiator.
`ratedAtDeltaT`	Yes
`roomHeatLossW`	Yes
`oversizeFactor`	Yes	Radiator output at 50 K divided by the room's heat loss. The single number the Heat Emitter Guide turns into a star rating.
`flowTemperature`	Yes	The flow temperature the heat pump must produce, in Celsius.
`radiatorOutputW`	Yes
`starRatingLabel`	Yes
`outputAtDeltaT50`	Yes	The radiator's output restated at a mean-water-to-air difference of 50 K, so oversize factors are comparable between catalogues.
`returnTemperature`	Yes
`outputAtDesignFlowW`	Yes	What this radiator actually gives at the flow temperature worked out here.
`radiatorOutputForFiveStarsW`	Yes	The radiator output at 50 K that would reach a five star rating, meaning a 40 degree flow temperature.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 16, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare read-only, idempotent, non-destructive and closed-world, so safety is covered. Beyond that the description discloses genuine behaviour: the 60 K catalogue convention triggers a restatement of the figure, the result yields an oversize factor converted via the BS EN 442 output law, and star ratings map 0-6 with one star per five degrees. It adds context annotations cannot carry.

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 purpose and inputs are front-loaded and the paragraph order (what it does, why it matters, what to supply, what you get, how to apply it, provenance) is logical. It is slightly long: the tutorial on heat pump efficiency falling two-to-three per cent per degree is useful interpretation context but not needed to invoke the tool.

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?

An output schema exists, so return values need not be explained, yet the description still summarises the key outputs (oversize factor, required flow temperature, star rating). Combined with input guidance, the per-room instruction, and the installation disclaimer, it covers what an agent needs; only explicit error or boundary behaviour is unaddressed.

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 five parameters including the 50 K vs 60 K catalogue convention and defaults. The description largely restates this, adding only the behavioural detail that a 60 K input causes the figure to be restated; that is helpful but marginal, so the baseline of 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?

The description names a specific verb and resource ('work out the flow temperature a heat pump must produce ... through a given radiator') plus the secondary output (MCS Heat Emitter Guide star rating) and the governing method (MGD 007 section 4). This clearly separates it from siblings like heat_pump_size or room_heat_loss, which supply inputs rather than this calculation.

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

Usage Guidelines4/5

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

It gives strong workflow context: 'Supply the room's design heat loss in watts, from a room-by-room calculation', 'Run this for every room', and 'one undersized radiator sets the running cost for the whole house'. It also frames the tool as for understanding/checking a quotation rather than certified design. It does not explicitly name an alternative tool or a when-not-to-use condition, so it falls short of a 5.

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

All Ampworth calculators 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?