Skip to main content
Glama

Renewably

Home battery plan

plan_home_battery
Read-onlyIdempotent

A home battery's plan from the half hour under way to the end of tomorrow, on the tariff's real prices (Agile's, and Agile Outgoing's, estimated beyond what Octopus has published), half hour by half hour: charge from the grid, hold, run the house (self-use), export, or send the sun to the grid – the cheapest way through, counting the battery's losses and wear. Exporting follows what the export tariff pays for – everything on Octopus's, only what the panels put in on the others – unless battery_export=all says the home is paid for what the battery charged from the grid too. A battery without panels gives export (Octopus's outgoing, agile-outgoing or prime-outgoing, eon-next-export-premium for a battery E.ON fitted, or fixed with export_rate) and trades on the grid: charging cheap, exporting at the peak. Smart Export Guarantee tariffs pay only for what panels made, so not a battery on its own. now is what to set this half hour; settings the few changes worth typing into the inverter's app. For a typical home of usage; give soc (the battery's charge now) for a plan from where it is. Advice and data for the owner's own automation – Renewably never controls a battery.

Input Schema

NameRequiredDescriptionDefault
socNoThe battery's charge now, per cent (0-100). Default: at its reserve.
rateNoCharge and discharge rate, kW (0.5-15, default 3).
wearNoThe battery's wear for each kWh it gives back, pence (0-20, default 2).
usageNoThe home's electricity use, kWh a year (500-30000, default 2500).
exportNoHow export is paid: `paired` (the tariff's own export tariff, default), `fixed` (with export_rate), `fit` (the Feed-in Tariff's deemed export: paid whatever is exported, so the sun used at home gives nothing up), `none`, or an export tariff's key from list_tariffs?direction=export (used where the tariff can have it, else its own).
regionYesAgile region: a letter A-P or the slug from list_regions (eg `C` or `london`); list_regions lists well-known places in each.
tariffNoA tariff's key from list_tariffs (default `agile`), eg `go`, `edf-go-electric`, `eon-next-drive`.agile
batteryNoUsable battery, kWh (2-50, default 10).
ceilingNoNever charged above this, per cent (10-100, default 100; above `reserve`) – for an inverter set to stop short of full.
reserveNoNever below this, per cent (0-90, default 0).
solar_kwpNoThe home's solar panels, kWp (0.2-50): the answer then counts their forecast spare sun – see the docs' Solar panels section.
round_tripNoRound-trip efficiency, per cent (60-100, default 90).
export_rateNoA fixed export rate, p/kWh (0-100).
solar_pitchNoTheir angle from flat, degrees (0-90, default 35).
export_limitNoThe home's export limit, kW (0-30, default 3.68: a G98 connection).
solar_facingNoThe way they face: S, SE, SW, E, W, NE, NW or N – or a bearing in degrees (south is 180). Default S.
grid_chargingNo`1` (default) may charge from the grid; `0` only from the panels.1
battery_exportNoWhat the battery may export: `terms` (default) what the export terms pay for – on Octopus's export tariffs everything, on the others only what the panels put in; without panels everything, once `export` is given; `all` what it charged from the grid too, on any export tariff – check the supplier pays for that; `solar` only what the panels put in, even on Octopus's; `never`.terms
solar_inverter_kwNoThe inverter's limit, kW (0.5-50), if smaller than the panels.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / ceiling
      Added value: +{
      +  "default": 100,
      +  "description": "Never charged above this, per cent (10-100, default 100; above `reserve`) – for an inverter set to stop short of full.",
      +  "maximum": 100,
      +  "minimum": 10,
      +  "type": "number"
      +}
  2. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare read-only, idempotent, open-world behaviour, and the description adds real value on top: prices are the tariff's real ones with estimates beyond what Octopus published, the plan counts round-trip losses and battery wear, and it explicitly says 'Renewably never controls a battery' — advice only. It does not describe plan horizon edge cases or failure modes, but the safety/actuation profile is unambiguous.

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

Conciseness2/5

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

The purpose is front-loaded, but the body is a dense run-on of dash-clauses and nested parentheses that is hard to parse for an agent scanning many tools. Substantial material is repeated (the export-tariff payment rule appears in the body and again in the `battery_export` discussion), and informal phrasing like 'send the sun to the grid' costs tokens without adding precision.

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 19-parameter optimiser with no output schema, the description covers the important unknowns: the planning horizon, what the returned `now` and `settings` mean, price sourcing and estimation, loss/wear accounting, and export eligibility rules. It stops short of describing the shape of the returned schedule (per-half-hour actions, savings figures) or how errors/full-horizon limits behave.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline would be 3, but the description adds genuine meaning beyond the schema: it explains the interaction between `export` and `battery_export` (Octopus export tariffs pay for everything, others only for panel generation; `battery_export=all` overrides on any tariff), what a battery-without-panels configuration looks like, that `now` is the action for this half hour and `settings` the inverter app changes, and that `soc` defaults to reserve.

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?

The description states a specific resource (half-hourly home battery plan from now to end of tomorrow) and the decision space it optimises (charge, hold, self-use, export, solar to grid on real tariff prices). It implies a distinction from planning tools that don't model a battery, but never names a sibling such as plan_home or get_home_battery_times, so the agent must infer routing.

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?

Usage conditions are embedded rather than stated: give `soc` to plan from current charge, `usage` for a typical home, and the export tariff rules explain which configurations are valid (SEG tariffs not for a battery alone). There is no explicit 'use this instead of X when Y' routing to the sibling planning and times tools, leaving selection largely to inference.

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