Skip to main content
Glama

Ampworth

What size heat pump do I need?

heat_pump_size
Read-onlyIdempotent

Estimate the heat pump a UK house needs, and what it would cost to run against the fuel it burns now.

IMPORTANT: MIS 3005-D requires a heat pump to be sized from a room-by-room heat loss calculation to BS EN 12831, and nothing here replaces that. Say so whenever you report a result from this, and point the user at the room-by-room calculation. What the figure is for is checking whether a size somebody has been quoted is plausible, because oversizing is the commonest fault in heat pump installations and it is invisible to the person living with it.

There are two routes and the first is much the better one.

From metered fuel, which is preferred: give 'annualFuelUse' from a year of bills. The fuel becomes heat delivered, hot water comes off it using the MIS 3005-D formula, and what remains divided by the local heating degree days gives the building's heat loss coefficient in watts per kelvin. Degree days are computed from the Met Office monthly means published in MGD 007 section 5.

From the fabric, as a fallback when there are no bills: give 'floorAreaM2', an 'insulation' level and a 'propertyType'. The watts per kelvin per square metre behind this are a reasonable reading of British housing stock but they are NOT MCS figures, because MCS publishes no such shortcut. Say so when using this route.

Either way the peak load is the coefficient multiplied by the design temperature difference for the location, from Table 2 of MIS 3005-D. The heat pump must deliver at least that at the design outside temperature and the design flow temperature, which is not the same as its headline rating.

The result also compares what each of four flow temperatures would cost to run, which is the decision that governs the bill and the one a quotation most often leaves unstated. Supply 'quotedHeatPumpKw' to have a quoted size checked against the estimate.

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
fuelNoThe fuel the house is heated with now: 'mains_gas', 'oil', 'lpg', 'electricity' or 'coal'. Defaults to 'mains_gas'.
scopNoSeasonal coefficient of performance of the proposed heat pump, if it is known from the MCS Product Directory. Defaults to an indicative figure for the chosen flow temperature.
bedroomsNoNumber of bedrooms, for the hot water demand. Defaults to 3.
locationYesNearest of the eight tabulated locations: 'belfast', 'birmingham', 'cardiff', 'edinburgh', 'glasgow', 'london', 'manchester' or 'plymouth'. Required.
occupantsNoNumber of people living there, if known. MIS 3005-D takes the greater of this and bedrooms plus one.
insulationNoHow well insulated the building is: 'solid', 'cavity_unfilled', 'insulated', 'modern' or 'very_efficient'. Used only with floorAreaM2.
designBasisNo'a' for the 99% outside design temperature or 'b' for the colder 99.6% one. Defaults to 'a'.
floorAreaM2NoTotal heated floor area in square metres, over all storeys. Used only when no fuel figure is given.
internalTempNoWhole-house mean internal design temperature in Celsius. Defaults to 20, which is a reasonable average of the room-by-room figures in MIS 3005-D Table 1.
propertyTypeNo'detached', 'semi', 'end_terrace', 'mid_terrace', 'flat' or 'bungalow'. Used only with floorAreaM2. Defaults to 'semi'.
annualFuelUseNoHow much of that fuel the house burns in a year, in its own unit: kWh for gas and electricity, litres for oil and LPG, kilograms for coal. Give this if it is known: it describes the actual house and is far better than the fabric estimate.
flowTemperatureNoThe flow temperature the system would be designed around: 35, 45, 50 or 55. Defaults to 45. This is the single biggest influence on running cost.
fuelPricePerUnitNoPrice of one unit of the current fuel, in pounds. Optional; supplying it and the electricity price gives a running cost comparison.
quotedHeatPumpKwNoThe output of a heat pump somebody has quoted, in kW. Optional; supplying it says whether that size looks plausible against this estimate.
nonHeatingFractionNoShare of that fuel used for something other than heating and hot water, such as a gas hob, as a decimal. A hob is usually 0.03 to 0.05. Defaults to 0.
summerMonthFuelUseNoFuel used in a single summer month, in the same unit, when the heating is off. Give this if it can be found: almost all of it is hot water, so it separates hot water from space heating exactly and removes the biggest assumption in the estimate.
applianceEfficiencyNoSeasonal efficiency of the existing boiler as a decimal. Defaults to a realistic figure for the fuel instead of the one on the badge.
electricityPricePerKwhNoPrice of a unit of electricity, in pounds. Optional.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
scopYes
basisYes
notesYes
methodYes
warningYes
locationYes
basisNoteYes
referencesYes
designBasisYes
scopAssumedYesTrue when an indicative figure stood in for a real one from the product directory.
internalTempYes
breakEvenScopNoThe seasonal efficiency at which the two cost the same.
peakHeatLossKwYesThe space heating load at the design outside temperature. The heat pump must deliver at least this, at the design flow temperature, without help from an immersion heater.
flowTemperatureYes
quotedSizeCheckNo
annualDifferenceNoPositive when the heat pump costs less.
annualHotWaterKwhYes
currentAnnualCostNo
heatingDegreeDaysYes
externalDesignTempYes
heatPumpAnnualCostNo
annualHeatDemandKwhYes
dailyHotWaterLitresYes
wattsPerSquareMetreNoPeak load per square metre of floor, where a floor area was given. A useful sanity check.
flowTemperatureCostsNo
annualSpaceHeatingKwhYes
hotWaterFromSummerUseYesTrue when a summer month's fuel separated hot water from space heating, instead of an allowance standing in for it.
temperatureDifferenceYes
heatPumpElectricityKwhYes
heatLossCoefficientWPerKYesHow many watts the building loses for every degree between inside and outside. The figure everything else follows from.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, not destructive), so the description exceeds the bar by disclosing the method (coefficient from degree days, peak load from MIS 3005-D Table 2), the caveat that the fabric route is not MCS-derived, and the design-flow vs headline-rating distinction. This is unusually rich context for a calculator.

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?

Reasonably front-loaded (purpose, then the IMPORTANT caveat, then the two routes), and the length is defensible for an 18-parameter calculator. It loses a point for mild repetition, notably the instruction to flag limits being restated for the metered and fabric routes separately.

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?

An output schema exists, so return values need no explanation, and the description compensates fully for the tool's complexity by documenting method provenance, the design-temperature basis, and the recommended framing of results. Nothing an agent needs to invoke or report this 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?

With 100% schema description coverage the baseline is 3, but the prose adds genuine relational meaning beyond per-field docs: it explains that annualFuelUse and the fabric parameters are mutually exclusive routes, that quotedHeatPumpKw drives a plausibility check, and that flowTemperature governs four cost scenarios. It does not restate individual field syntax.

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+resource (estimate heat pump size for a UK house) plus a secondary function (running-cost comparison against current fuel). It is clearly distinguishable from siblings like room_heat_loss, heat_pump_running_cost and radiator_flow_temperature, which it never overlaps.

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?

Explicitly lays out two routes, names the metered-fuel route as preferred and the fabric route as fallback, and states the trigger for each (annualFuelUse present vs absent). It also names the shape of use (checking whether a quotation is plausible) and points to the room-by-room calculation as the alternative for actual design.

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