Ampworth calculators

Solar PV annual output

solar_pv_output

Read-onlyIdempotent

Estimate the annual AC electricity output of a UK solar photovoltaic system, in kWh, using the standard estimation method that MIS 3002 requires every MCS certified installer to use.

The method is: annual output = kWp x Kk x SF, where Kk is read from the MCS irradiance dataset for the site's postcode zone, roof pitch and orientation, and SF is a shade factor between 0 and 1.

Supply the postcode and the array's capacity in kWp, plus the roof's pitch in degrees from horizontal and its orientation in degrees away from due south in either direction, so that south is 0, south-east and south-west are both 45, east and west are both 90, and north is 180.

The result carries the tabulated yield, the estimate, and what the same array would produce at the best pitch and orientation for that zone, so a roof that is merely good is not mistaken for a poor one. This covers the United Kingdom only; the dataset has no values for anywhere else.

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

Name	Required	Description
`zone`	No	MCS postcode zone code, for example '5E'. An alternative to 'postcode' when the zone is already known.
`postcode`	No	UK postcode of the installation, for example 'BS1 5TR'. Only the outward code matters. Give this or 'zone'.
`capacityKwp`	Yes	Total installed capacity in kilowatts peak: the sum of the nameplate watts of every module, divided by 1000. Required.
`inclination`	Yes	Pitch of the array in degrees from horizontal. A flat roof is 0 and a wall-mounted array is 90. Required.
`orientation`	Yes	Degrees the array faces away from due south, in either direction, so due south is 0, south-east and south-west are 45, east and west are 90, and due north is 180. Required.
`shadeFactor`	No	Proportion of output left after shading, between 0.5 and 1. Use 1 for a clear horizon. Defaults to 1.

Output Schema

TableJSON Schema

Name	Required	Description
`zone`	Yes
`notes`	Yes
`method`	Yes
`references`	Yes
`capacityKwp`	Yes
`inclination`	Yes	Inclination after rounding to the nearest degree, as the method requires.
`orientation`	Yes	Orientation after rounding to the nearest five degrees, as the method requires.
`shadeFactor`	Yes
`postcodeUsed`	No	The postcode the zone was resolved from, when one was given.
`shadingLossKwh`	Yes
`annualOutputKwh`	Yes	The estimate: capacity multiplied by Kk multiplied by the shade factor.
`bestCaseAnnualKwh`	Yes	What this capacity would produce at the best pitch and orientation for the zone, unshaded. A yardstick, not a target: a roof faces where it faces.
`percentOfBestCase`	Yes	The estimate as a percentage of that best case.
`unshadedOutputKwh`	Yes	What the same array would produce with a clear horizon. Equals the estimate when the shade factor is 1.
`bestCaseInclination`	Yes	The pitch that yields most at this zone when facing due south.
`bestCaseOrientation`	Yes	The orientation that yields most at this pitch and zone. Almost always due south.
`specificYieldKwhPerKwp`	Yes	Kk: the kWh a single kWp produces in a year at this zone, pitch and orientation, before shading.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 16, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new behavioral context: the exact computation formula, the UK-only dataset limit ('no values for anywhere else'), and the disclaimer that results are for understanding/checking rather than design. It does not describe what happens on an out-of-UK postcode or other error paths.

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?

Purpose and method are front-loaded in the first two paragraphs, and the closing caveat earns its place. The orientation convention sentence, however, is lifted straight from the schema and is pure duplication that could be cut.

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?

For a calculator whose output schema exists (so return values need no explanation), the description covers method, domain conventions, geographic limits and usage caveats. The one remaining gap is behavior on invalid or non-UK input, which is only implied by the 'no values for anywhere else' note.

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% and every parameter is already documented there, including the orientation convention and the postcode/zone alternative. The description restates the orientation convention almost verbatim and adds no new syntax or format detail, so it sits at the baseline for a fully documented schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource with units: 'Estimate the annual AC electricity output of a UK solar photovoltaic system, in kWh.' It also pins the method (MIS 3002 / MCS) and the geographic scope. However it never names or contrasts against the obvious siblings solar_pv_system_size, solar_pv_shading, or solar_pv_self_consumption, so the agent must infer the boundary from the names alone.

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

Usage Guidelines3/5

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

It gives a usage context ('for understanding a system and checking a quotation') and a caveat that anything installed still needs a design and site survey from a certified installer. But it never says when to prefer this over the sibling PV calculators, nor what inputs make it inapplicable beyond the UK-only scope note.

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?