Skip to main content
Glama

Ampworth

What size solar system do I need?

solar_pv_system_size
Read-onlyIdempotent

Work out the solar PV system a UK home needs: the capacity in kWp, the number of panels, the battery to go with it, and what it would do to the electricity bill.

This runs the MCS arithmetic backwards. The other solar calculators here each answer one question about a system somebody has already specified. This one starts from what a household uses and arrives at the system that covers it, which is the question a householder actually has.

The chain is short and every link is published. Annual consumption sets the generation the array has to make. The MCS irradiance dataset behind MIS 3002 says what one kWp makes on that roof, which gives a capacity. Capacity divided by panel size gives a panel count, rounded up, because panels come whole. The MGD 003 tables then say how much of that generation the household will use and how much it will export.

Only the postcode and the roof direction are required. Direction is a compass point, not an angle: 'S', 'SE', 'SW', 'E', 'W', 'NE', 'NW' or 'N'. Give the annual consumption from a bill if it is known, since the 3,500 kWh default is only the British average. Shading can be described in words instead of measured, and a roof area caps the panel count where the roof is the constraint.

No cost is assumed. Installed prices vary far too much between houses to guess at, so a payback figure appears only when a cost from a real quotation is supplied.

Use this to size a system or to sanity-check a quotation. Use 'solar_pv_output' instead when the capacity is already known and the question is only what it will generate.

Method from MIS 3002. 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
shadingNoHow much shading the roof has, in words: 'none', 'light', 'moderate' or 'heavy'. Defaults to 'none'. Use 'shadeFactor' instead if a proper MGD 005 assessment has been done.
postcodeYesUK postcode of the property, for example 'BS1 5TR'. Only the outward code matters. Required.
directionYesCompass point the roof faces: 'S', 'SE', 'SW', 'E', 'W', 'NE', 'NW' or 'N'. Required.
occupancyNoWeekday occupancy: 'home_all_day', 'in_half_the_day' or 'out_all_day'. Decides how much of the generation is used at home instead of exported. Defaults to 'in_half_the_day'.
panelWattsNoNameplate rating of a single panel in watts. Defaults to 440, which is typical of a current domestic module.
roofAreaM2NoShade-free roof area available for panels, in square metres. Optional; when given it caps the number of panels.
inclinationNoRoof pitch in degrees from horizontal. Defaults to 35, which is typical of a British pitched roof. A flat roof is 0.
shadeFactorNoA measured shade factor between 0.5 and 1 from an MGD 005 assessment. Overrides 'shading' when given.
installedCostNoThe installed cost of the system in pounds, from a quotation. Optional; supplying it gives a payback period. No cost is assumed if it is left out, because prices vary too much to guess at.
includeBatteryNoWhether to size a battery alongside the panels. Defaults to false.
batteryModuleKwhNoNominal capacity of one battery module in kWh. Batteries are sold in whole modules, so the answer rounds up to one. Defaults to 5.
exportPricePerKwhNoWhat the household is paid for a unit exported, in pounds. Optional.
annualConsumptionKwhNoThe household's electricity use in kWh a year, from a bill. Defaults to 3500, which is the British average and the figure MGD 003 falls back on, but a real bill sharpens the answer considerably.
electricityPricePerKwhNoWhat the household pays for a unit, in pounds. Optional; supplying it puts a value on the answer.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
zoneYes
notesYes
methodYes
panelsYes
batteryNo
shadingNoThe shading description used, when one was chosen in place of a measured factor.
directionYes
panelWattsYes
referencesYes
capacityKwpYesThe installed capacity: the panel count multiplied by the panel rating.
exportedKwhYes
importedKwhYesUnits still bought from the grid over a year.
inclinationYes
roofLimitedYesTrue when the roof area given, not consumption, set the size.
shadeFactorYes
paybackYearsNoInstalled cost divided by the annual benefit. Only present when a cost was supplied.
postcodeUsedYes
annualBenefitNoBill saving plus export income.
installedCostNo
newAnnualCostNo
occupancyLabelYes
selfConsumedKwhYes
annualBillSavingNo
idealCapacityKwpYesThe capacity that would exactly cover a year of consumption, before rounding up to whole panels.
roofAreaNeededM2Yes
currentAnnualCostNo
annualExportIncomeNo
consumptionAssumedYesTrue when the 3500 kWh default stood in for a figure the caller did not give.
annualGenerationKwhYes
annualConsumptionKwhYes
selfConsumptionPercentYes
specificYieldKwhPerKwpYesKk: the kWh a kWp produces in a year at this zone, pitch and orientation.
gridIndependencePercentYesThe share of the household's own use met by the system.
generationAsPercentOfUseYesAnnual generation as a percentage of annual consumption. Above 100 means the system makes more over a year than the house uses, though not at the same times.

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 (read-only, idempotent), yet the description adds substantial behavioral context: panels and battery modules round up because they are sold whole, no cost is assumed so payback appears only when a real quotation is supplied, defaults are the British averages, and the method provenance (MIS 3002, MGD 003, MGD 005) is disclosed. This is far beyond what the annotations convey.

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?

Front-loaded with what the tool does and why it differs from siblings; the method paragraph and provenance are informative rather than filler. It is longer than strictly necessary ('The chain is short and every link is published' is flourish) but nothing is misleading or redundant.

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 14-parameter, output-schema-backed calculator this is complete: required vs optional inputs, defaults, rounding behavior, the no-cost assumption, and the installer/survey caveat are all covered, and return values are left to the output schema.

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 meaning beyond the schema: direction is framed as a compass point rather than an angle, the 3,500 kWh default is tied to the British average/MGD 003 fallback, and installedCost is explained as the trigger for a payback figure. It stops short of adding syntax detail for every parameter, so not 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 specific verb+resource with scope: sizing a UK solar PV system (kWp capacity, panel count, battery, bill impact). It explicitly distinguishes itself from the other solar calculators as the one that works backwards from consumption rather than describing an already-specified system.

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?

Gives both use cases ('size a system or sanity-check a quotation') and names the alternative with the condition that selects it: use 'solar_pv_output' when capacity is already known. No inference required.

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