Ampworth

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 17, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds real domain behaviour: efficiency falls ~2-3% per degree of water temperature, star ratings scale one star per 5 degrees with six stars at 35C, and a caveat that installed systems still need a certified installer. It stops short of stating validity bounds or how out-of-range inputs are handled.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the purpose, which is good, but it runs five paragraphs and includes economic rationale ('cheap or expensive to run') and a restatement of the 50 K/60 K point that overlaps the schema. The method and installer caveats earn their place; the economic lecture is padding.

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 spelled out, and the description correctly covers inputs, method provenance (MGD 007 section 4 / BS EN 442), workflow, and interpretation of the star rating. It is complete enough to invoke correctly, with only minor gaps around edge cases.

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 fully documents all five parameters and the baseline is 3. The description adds interpretive framing (heat loss in watts from a room-by-room calc, catalogue ratings normally at 50 K, restated if 60), but largely echoes what the schema already states for ratedAtDeltaT and radiatorOutputW. Marginal added meaning over the structured fields.

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: compute the flow temperature a heat pump must produce through a given radiator, plus the resulting MCS star rating. This is clearly distinguishable from siblings like room_heat_loss (which produces the heat-loss input) and heat_pump_size. An agent can identify the tool without opening the schema.

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?

Gives strong operational context: 'Run this for every room' and explains that the whole house runs at its worst room's flow temperature. It also implies the pipeline dependency on a room-by-room heat loss figure. However, it never explicitly names a sibling tool (e.g. room_heat_loss) as the source of the input, so the routing is implied rather than stated.

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

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