Skip to main content
Glama

Ampworth

Room heat loss

room_heat_loss
Read-onlyIdempotent

Calculate the design heat loss of a single room in watts, following BS EN 12831 as MIS 3005-D applies it. This is the figure a heat pump is sized from and the figure the radiator in that room must be able to deliver.

BS EN 12831 is a room-by-room method. Run this once for each heated room and add the results; sizing a heat pump from floor area alone is what produces the oversized installations that cycle all winter.

Internal design temperatures come from Table 1 of MIS 3005-D and follow from the room type: 22 for a bathroom, 21 for living and dining rooms, 18 for bedrooms, halls, kitchens and toilets. These are minimums, so a higher figure is accepted and a lower one is refused.

External design temperatures come from Table 2, for eight locations, in two columns: 'a' is the 99% figure and 'b' the colder 99.6% one, which needs no uplift for intermittent heating.

Each element needs an area, a U-value, and a kind. The kind matters because it fixes which temperature difference applies. Walls, windows, doors, roofs and suspended floors lose heat to the outside design temperature. A SOLID FLOOR ON THE GROUND loses heat to the local annual average air temperature instead, which is far warmer, and getting this wrong is the commonest error in a heat loss calculation. Window and door areas belong to the window and the door, not to the wall behind them.

Method from MIS 3005-D. 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
NameRequiredDescriptionDefault
elementsYesEvery surface through which the room loses heat. At least one is required.
locationYesWhich of the eight tabulated locations the property is nearest: 'belfast', 'birmingham', 'cardiff', 'edinburgh', 'glasgow', 'london', 'manchester' or 'plymouth'. Required.
roomNameNoA name for the room.
roomTypeNoWhich of the tabulated room types this is: 'living_room', 'dining_room', 'bedsitting_room', 'bathroom', 'bedroom', 'kitchen', 'hall' or 'toilet'. Sets the internal design temperature. Defaults to 'living_room'.
designBasisNo'a' for the 99% outside design temperature or 'b' for the colder 99.6% figure. Column B needs no uplift for intermittent heating. Defaults to 'a'.
floorAreaM2YesFloor area of the room in square metres. Required, and used with the ceiling height to work out the ventilation loss.
internalTempNoInternal design temperature in Celsius, if it should differ from the tabulated value for the room type. MIS 3005-D sets the tabulated values as a floor, not a target, so a higher figure is allowed and a lower one is not.
ceilingHeightMNoFloor to ceiling height in metres. Defaults to 2.4.
airChangesPerHourNoHow many times an hour the air in the room is replaced. A draughty old room may be 1.5 or more; a well sealed new one 0.5. Defaults to 1.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
notesYes
methodYes
elementsYes
locationYes
roomNameNo
roomTypeYes
referencesYes
designBasisYes
fabricLossWYes
largestLossNoWhich single element loses most, which is where insulating first pays best.
internalTempYes
roomVolumeM3Yes
totalHeatLossWYesThe room's design heat loss in watts. This is what the emitter in the room has to deliver on the coldest day.
ventilationLossWYes
externalDesignTempYes
fabricSharePercentYes
wattsPerSquareMetreYesHeat loss divided by floor area. A useful sanity check: a well insulated room lands near 40, a poor one well over 100.
temperatureDifferenceYesInternal minus external design temperature, in kelvin. The figure most of the fabric loss is worked out against.
ventilationSharePercentYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already cover the read-only/idempotent safety profile, and the description goes well beyond them: it discloses validation behaviour ('tabulated values are minimums... a lower one is refused'), the kind-dependent temperature basis, the ground-floor special case, and the default for unheatedTemp. That is real behavioural context an agent cannot get from 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.

Conciseness4/5

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

The core definition is front-loaded in the first sentence and each paragraph serves a distinct purpose (method, room temperatures, design basis, element kinds, disclaimer). It is nonetheless long for a single tool, with the closing MCS disclaimer paragraph adding bulk more than invocation guidance.

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?

For a domain-heavy calculation with an output schema already present, the description supplies everything an agent needs: method, required inputs, validation rules, defaults, and the common modelling error. Nothing needed 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 coverage is 100%, so the baseline is 3, but the description adds genuine meaning: it maps roomType to concrete temperatures (22 bathroom, 21 living/dining, 18 bedrooms/halls/kitchens/toilets) and explains that 'kind' fixes which temperature difference applies. It largely restates the a/b column note and defaults already present in the schema, which keeps this short of a 5.

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 precise verb+resource+unit ('Calculate the design heat loss of a single room in watts'), names the standard it follows (BS EN 12831 / MIS 3005-D), and positions the output as the figure a heat pump is sized from, which cleanly separates it from the aggregate heat_pump_size sibling.

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 clear operational guidance ('Run this once for each heated room and add the results') and explicitly warns against the wrong approach (sizing a heat pump from floor area alone). It implies but never names heat_pump_size as the aggregation step, so there is no explicit alternative routing.

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