Cheapest and greenest times to use electricity in Great Britain, and which tariff suits a home.
Scored across 10 tools
Most tools target distinct tasks, such as tariff discovery, price retrieval, EV charging, and whole-home scenario planning. The main possible confusion is between get_home_battery_times and plan_home_battery, though their descriptions distinguish typical-day guidance from a detailed live dispatch plan.
Every tool uses readable snake_case with a consistent verb-first convention. The find, get, list, and plan prefixes also communicate different kinds of operations predictably.
Ten tools are well suited to the server's home-energy planning scope. Each supports a recognizable workflow, and the two battery tools offer sufficiently different levels of detail to justify their inclusion.
The set connects region and tariff discovery to prices, flexibility events, appliance timing, EV charging, battery operation, and whole-home investment scenarios. For a read-only advisory service, these tools cover the core workflows without an obvious dead end.
The cheapest (or lowest-carbon) run of duration_hours starting from the next half hour and finishing by the next finish_by – when to set a washing machine or dishwasher's delay timer.
| Name | Required | Description | Default |
|---|---|---|---|
| kwh | No | Energy the run uses, kWh (0-20), for its cost – on the energy label, or kW times hours. Leave out for no cost. | |
| export | No | How 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). | |
| region | Yes | Agile region: a letter A-P or the slug from list_regions (eg `C` or `london`); list_regions lists well-known places in each. | |
| tariff | No | A tariff's key from list_tariffs (default `agile`), eg `go`, `edf-go-electric`, `eon-next-drive`. | agile |
| optimise | No | `cost` (default) or `carbon` (NESO's regional forecast, about two days ahead). | cost |
| finish_by | No | Local time it must finish by, HH:MM (default 07:00) – the next one at least `duration_hours` away. | 07:00 |
| solar_kwp | No | The home's solar panels, kWp (0.2-50): the answer then counts their forecast spare sun – see the docs' Solar panels section. | |
| export_rate | No | A fixed export rate, p/kWh (0-100). | |
| solar_pitch | No | Their angle from flat, degrees (0-90, default 35). | |
| solar_facing | No | The way they face: S, SE, SW, E, W, NE, NW or N – or a bearing in degrees (south is 180). Default S. | |
| duration_hours | No | How long it runs, 0.5-12 in half hours (default 3.5). | |
| solar_inverter_kw | No | The inverter's limit, kW (0.5-50), if smaller than the panels. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare safe, read-only, idempotent, open-world behavior, so the safety profile is covered. The description adds the useful temporal scoping (start at the next half hour, end by finish_by) that shapes the result, but says nothing about error behavior for unknown tariff/region keys, how forecast horizon limits results, or what the returned window looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with the core outcome first and the practical application last; no filler. It is a little densely packed around the em-dash, but every clause contributes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 12-parameter forecasting tool with no output schema, the description covers the what and a use case but omits what is actually returned (a window start/end, with cost or carbon figure?) and the dependency on region plus tariff. Annotations handle safety, so the remaining gap is mainly about result shape, which matters more here because no output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter including region, tariff, optimise and the solar fields is already fully documented. The description only echoes duration_hours and finish_by and glosses 'cheapest (or lowest-carbon)', adding little meaning beyond the schema, which is the expected baseline when the schema carries the load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific outcome (cheapest or lowest-carbon run of duration_hours) plus the scheduling boundaries (starts from the next half hour, finishes by finish_by), so the agent knows exactly what is being located. It stops short of distinguishing itself from planning siblings such as plan_ev_charging or get_home_battery_times, leaving the agent to infer that this is the generic appliance-timing variant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The trailing clause 'when to set a washing machine or dishwasher's delay timer' gives a concrete use case, which implies when to reach for it. However, it names no alternatives and no exclusions – nothing says to prefer plan_ev_charging for cars or get_home_battery_times for batteries, so sibling selection is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
When the grid operator, NESO, is asking homes in a region to use less electricity (often the evening peak) or more (often in Scotland, when there's more wind than the grid can carry south), through its Demand Flexibility Service: live events from now to the end of tomorrow, usually announced the same morning. Households can sometimes get paid for taking part – but only if they've signed up to a scheme with their energy supplier or another provider (eg Octopus's Saving Sessions), and that provider is taking part in the event; it tells them and says what it pays. These are NESO's requests to such providers. Without a scheme, shifting use still helps the grid but isn't paid.
| Name | Required | Description | Default |
|---|---|---|---|
| region | Yes | Agile region: a letter A-P or the slug from list_regions (eg `C` or `london`); list_regions lists well-known places in each. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, open-world behavior. The description adds valuable context beyond that: the result set is limited to live events through the end of tomorrow, typically announced the same morning, and it clarifies that these are NESO's requests to providers, not household-level payments. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one long, rambling paragraph with parentheticals (winter wind curtailment, Octopus Saving Sessions, payment mechanics). The crucial temporal scope (live events now to end of tomorrow) is buried mid-sentence rather than front-loaded, making it harder to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-region read tool with annotations and full schema coverage, the description supplies sufficient domain and temporal context to call it correctly. It does not describe the response shape, but that is a minor omission for this complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single `region` parameter is fully documented in the schema with examples and a pointer to list_regions. The description adds no further semantics about the parameter, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns live Demand Flexibility Service events from NESO for a region, with a defined time window (now to end of tomorrow). It does not explicitly contrast with the sibling tools, but the domain (grid flexibility events vs. prices/planning) makes it distinguishable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use when a user asks about grid operator requests to shift electricity use. The description explains when events occur and who can be paid, but gives no explicit guidance on alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
For a typical weekday and weekend day at this time of year (on a fixed-window or flat tariff, today's rates): the cheapest time to reheat hot water (and the cheapest ready by 07:00), and the cost of each kWh of heat by hour – price divided by a generic air-source heat pump's efficiency at that hour's typical temperature.
| Name | Required | Description | Default |
|---|---|---|---|
| export | No | How 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). | |
| region | Yes | Agile region: a letter A-P or the slug from list_regions (eg `C` or `london`); list_regions lists well-known places in each. | |
| tariff | No | A tariff's key from list_tariffs (default `agile`), eg `go`, `edf-go-electric`, `eon-next-drive`. | agile |
| solar_kwp | No | The home's solar panels, kWp (0.2-50): the answer then counts their forecast spare sun – see the docs' Solar panels section. | |
| export_rate | No | A fixed export rate, p/kWh (0-100). | |
| solar_pitch | No | Their angle from flat, degrees (0-90, default 35). | |
| solar_facing | No | The way they face: S, SE, SW, E, W, NE, NW or N – or a bearing in degrees (south is 180). Default S. | |
| solar_inverter_kw | No | The inverter's limit, kW (0.5-50), if smaller than the panels. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and open-world behavior, and the description adds meaningful methodology: typical days, current-season temperatures, today's rates, and generic air-source heat-pump efficiency. It does not explain data freshness or forecast assumptions beyond that, but the added context is substantive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is a single front-loaded sentence with no wasted clauses, and it places the scenario before the returned values. The nested parentheticals make it slightly dense, but every element contributes to understanding the result.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an eight-parameter analytical tool with no output schema, the description does a good job explaining the returned quantities: cheapest time, ready-by-07:00 option, and hourly heat cost. It leaves solar/export parameter behavior to the schema, which is reasonable given 100% schema coverage, but it could have clarified whether solar inputs materially change the answer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all eight parameters are already documented by the input schema. The description does not add parameter-level meaning beyond mentioning tariff context and today's rates, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific computation: cheapest times to reheat hot water and the cost per kWh of heat by hour for a heat pump, with typical weekday/weekend scope. It is clearly distinct from generic pricing tools like get_prices, but does not explicitly name or route against siblings such as find_cheapest_window or get_home_battery_times.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear usage context: typical weekday and weekend days at this time of year, on a fixed-window or flat tariff, using today's rates. However, it does not state when not to use it or name alternatives for related tasks such as generic cheapest-window searches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
For a typical weekday and weekend day at this time of year (on a fixed-window or flat tariff, today's rates): the cheapest charge slot to fill a home battery before the 16:00 peak, an optional afternoon top-up, and what it saves a home using usage kWh a year – the battery runs the house after its charge until it's empty, through a typical day's use. No export, and not counting the battery's wear; with solar_kwp, also how full to charge overnight for the next day's sun.
| Name | Required | Description | Default |
|---|---|---|---|
| rate | No | Grid charge rate, kW (0.5-15, default 3). | |
| usage | No | The home's electricity use, kWh a year (500-30000, default 2500 – an average home). | |
| export | No | How 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). | |
| region | Yes | Agile region: a letter A-P or the slug from list_regions (eg `C` or `london`); list_regions lists well-known places in each. | |
| tariff | No | A tariff's key from list_tariffs (default `agile`), eg `go`, `edf-go-electric`, `eon-next-drive`. | agile |
| battery | No | Usable battery, kWh (2-50, default 10). | |
| solar_kwp | No | The home's solar panels, kWp (0.2-50): the answer then counts their forecast spare sun – see the docs' Solar panels section. | |
| export_rate | No | A fixed export rate, p/kWh (0-100). | |
| solar_pitch | No | Their angle from flat, degrees (0-90, default 35). | |
| solar_facing | No | The way they face: S, SE, SW, E, W, NE, NW or N – or a bearing in degrees (south is 180). Default S. | |
| battery_export | No | What the battery may export: `terms` (default) what the export tariff pays for – everything on Octopus's, only what the panels put in on the others; `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` – `evening_export` then says what that leaves. Without panels, give `export` too: everything a battery on its own exports came from the grid. | terms |
| solar_inverter_kw | No | The inverter's limit, kW (0.5-50), if smaller than the panels. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent and openWorld, so the safety profile is covered; the description adds genuinely useful behavioral caveats beyond them – that the savings figure excludes export and battery wear, and that the battery runs the house from its charge until empty through a typical day's use. These modelling assumptions are exactly the kind of context an agent needs to interpret results honestly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The scope constraint is front-loaded, which is good, but the body is a single dense run-on held together by dashes and parentheticals that is hard to parse on first read. Nothing is strictly wasted, yet the packaging works against fast comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a twelve-parameter, no-output-schema tool, the description does state which three results are produced (cheapest slot, top-up, savings), which is the essential shape. It stops short of describing the return structure or units for those results, leaving a meaningful gap for a tool this complex.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all twelve parameters and the baseline is 3. The description adds cross-parameter meaning for only a couple of them – `usage` as the annual kWh driving the savings figure, and `solar_kwp` triggering the overnight-fill-for-tomorrow's-sun output – while rate, battery, export_rate and the solar geometry params are left to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a concrete resource and computation: the cheapest charge slot to fill a home battery before the 16:00 peak, an optional afternoon top-up, and annual savings. It is specific about scope (typical weekday/weekend at this time of year) but never explicitly distinguishes itself from siblings like plan_home_battery or find_cheapest_window, so an agent must infer the boundary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied by the qualifier 'on a fixed-window or flat tariff, today's rates' and by the typical-day framing, which tells the agent this is an illustrative calculation rather than a live schedule. However, there is no explicit when-to-use/when-not-to-use statement and no named alternative for the real-planning case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Half-hourly prices for a region from midnight today. On Agile (the default) and Agile Outgoing, each is published by Octopus or estimated by Renewably (flagged estimate); other tariffs show only their supplier's published prices. An export tariff's are what it pays for export (and take no panels).
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Days from today, 1-5 (default 2: today and tomorrow). | |
| export | No | How 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). | |
| region | Yes | Agile region: a letter A-P or the slug from list_regions (eg `C` or `london`); list_regions lists well-known places in each. | |
| tariff | No | A tariff's key from list_tariffs (default `agile`) – an import tariff, or an export tariff from list_tariffs?direction=export (eg `agile-outgoing`), for what it pays. | agile |
| solar_kwp | No | The home's solar panels, kWp (0.2-50): the answer then counts their forecast spare sun – see the docs' Solar panels section. | |
| export_rate | No | A fixed export rate, p/kWh (0-100). | |
| solar_pitch | No | Their angle from flat, degrees (0-90, default 35). | |
| solar_facing | No | The way they face: S, SE, SW, E, W, NE, NW or N – or a bearing in degrees (south is 180). Default S. | |
| solar_inverter_kw | No | The inverter's limit, kW (0.5-50), if smaller than the panels. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent, openWorld), so the description correctly spends its words on provenance instead: Octopus-published versus Renewably-estimated values, the `estimate` flag, and the fact that other tariffs only carry supplier-published prices. That is real behavioral context an agent cannot get from the structured fields; only rate limits or failure modes are absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the core answer (what, where, when) before the tariff-provenance detail. No filler, but the final sentence is ungrammatical and 'take no panels' is an oblique way of saying solar inputs are ignored, costing a little clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 9-parameter tool with no output schema, the description covers provenance and export semantics but leaves the response shape implicit and defers all solar modelling behaviour to external documentation. An agent has enough to call it, but not a confident picture of what comes back per half-hour slot.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter already carries a thorough description, so the baseline is 3. The description adds one genuinely new cross-parameter fact — that an export tariff's prices are what it pays for export and that solar parameters do not apply there — but that point is stated in a garbled clause ('An export tariff's are...'), which blunts its value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence states the resource (half-hourly prices), the scope (a region), and the time window (from midnight today), which is specific enough to separate it from find_cheapest_window or the plan_* siblings. It does not name an alternative explicitly, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: fetch prices for a region under a given tariff, and the note that export tariffs report what they pay for export helps pick the right mode. There is no guidance on when to use this versus find_cheapest_window (which presumably consumes the same prices) or the plan_* tools, and no mention of prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The 14 Agile regions (GSP groups), each with well-known places in it - to place a home by its town. The regions are the local electricity networks' areas, not counties, so some places surprise (Milton Keynes and Coventry are in the East Midlands, Croydon in South East England, York in North East England). The surest way: the first two digits of the 13-digit MPAN on the home's electricity bill (mpan_prefix).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=true, so the safety profile is covered. The description's value-add is the warning that regions are electricity-network areas rather than counties, which sets expectations for the returned data. It does not state the shape of the returned records (names, IDs, ordering) despite there being no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core statement is front-loaded, but the parenthetical town examples (Milton Keynes, Coventry, Croydon, York) consume roughly a third of the text to make a single point about counterintuitive mappings. One or two examples would have earned the same benefit at half the length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter reference lookup this is close to adequate — it says what the 14 items are and what they contain. With no output schema, though, it should describe the fields returned per region, and the misplaced `mpan_prefix` reference leaves the calling contract slightly ambiguous.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters gives a baseline of 4, but the closing sentence names `mpan_prefix` as if it were an input, while the schema declares `additionalProperties: false` and no properties — an agent could reasonably try to pass it and fail. The MPAN guidance appears to belong to a different tool, which costs a point here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first clause names the specific resource — 'The 14 Agile regions (GSP groups)' — and clarifies what each entry contains ('well-known places in it'), which disambiguates it from generic geographic lists. It stops short of a crisp verb+resource statement ('List ...') and spends its opening on the domain caveat, but an agent can still tell exactly what this returns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'to place a home by its town' implies the use case, and the MPAN hint narrows it further. However, it never says when not to use it, nor does it reference any sibling (list_tariffs, plan_home, etc.) that might also consume a region, so the routing is left implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The time-of-use and standard tariffs from Octopus, EDF and E.ON Next that the tariff parameter accepts – or, with direction=export, their export tariffs (for get_prices and export), each saying which homes can have it.
| Name | Required | Description | Default |
|---|---|---|---|
| direction | No | `import` (default) or `export`. | import |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint and idempotentHint, so safety and mutability are covered. The description adds genuinely new context — which suppliers are covered and that each entry states which homes are eligible — but says nothing about result size, pagination, or the shape/format of a tariff identifier.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is a single sentence with no filler, but that sentence is dense and hard to parse, stacking an em-dash aside, a parenthetical cross-reference, and a trailing clause ('each saying which homes can have it'). Splitting it into action plus direction semantics would read far better without adding length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-optional-parameter, read-only listing tool with no output schema, the description covers what the tool is for and the import/export split, which is the essential part. It stops short of describing what a returned entry looks like — particularly the identifier format that feeds the `tariff` parameter — which is the one thing an agent most needs from a value-listing tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the enum already documents `import` versus `export`, so the baseline is 3. The description goes further by explaining what `direction=export` actually yields (export tariffs used with get_prices' export mode), which adds downstream meaning beyond the one-word enum values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific resource (time-of-use and standard tariffs from Octopus, EDF, E.ON Next) and scopes it as the set the `tariff` parameter accepts, which distinguishes it from siblings like get_prices that consume those values. It is clear what the tool enumerates, though the verb ('list') is only implied and the sentence is built around the downstream parameter rather than the tool's own action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: by saying these are the tariffs 'the `tariff` parameter accepts', it suggests calling this before get_prices, and it notes the export variant is for get_prices/`export`. However, it never explicitly says when to call list_tariffs instead of get_prices, nor any exclusions or preconditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The cheapest or greenest half hours to charge an electric car by a ready-by time up to four days ahead.
| Name | Required | Description | Default |
|---|---|---|---|
| day | No | Ready-by day: today, tomorrow, in2 or in3 (default: the next time `time` comes round, at least four hours away). | |
| mpk | No | Miles per kWh, for the per-mile figures (1.5-6, default 3.3). | |
| now | No | Charge now, % (0-100, default 30). | |
| mode | No | `timer` (one unbroken block, default) or `smart` (any half hours). | timer |
| time | No | Ready-by local time, HH:MM (default 07:00). | 07:00 |
| export | No | How 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). | |
| region | Yes | Agile region: a letter A-P or the slug from list_regions (eg `C` or `london`); list_regions lists well-known places in each. | |
| target | No | Target charge, % (0-100, default 80). | |
| tariff | No | A tariff's key from list_tariffs (default `agile`), eg `go`, `edf-go-electric`, `eon-next-drive`. | agile |
| battery | No | Usable battery, kWh (5-200, default 60). | |
| charger | No | Charging power, kW (1-22, default 7.4). | |
| optimise | No | `cost` (default) or `carbon`. | cost |
| solar_kwp | No | The home's solar panels, kWp (0.2-50): the answer then counts their forecast spare sun – see the docs' Solar panels section. | |
| efficiency | No | Charging efficiency, % (60-100, default 90). | |
| export_rate | No | A fixed export rate, p/kWh (0-100). | |
| solar_pitch | No | Their angle from flat, degrees (0-90, default 35). | |
| solar_facing | No | The way they face: S, SE, SW, E, W, NE, NW or N – or a bearing in degrees (south is 180). Default S. | |
| solar_inverter_kw | No | The inverter's limit, kW (0.5-50), if smaller than the panels. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent and openWorld, so safety is covered. The description adds two real behavioral facts beyond that: the optimisation objective is a choice between cost and carbon, and the horizon is capped at four days. It says nothing about what a plan contains (sessions, prices, savings), which matters because there is no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler. The compression costs a little readability ('by a ready-by time up to four days ahead'), but nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is an 18-parameter planning tool with no output schema, and the description gives no sense of the result shape, no usage context, and no pointer to its nearest alternatives. The schema carries almost all the burden, leaving the description inadequate for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the schema itself routes the agent to list_regions and list_tariffs and explains timer vs smart modes. The description adds no parameter detail beyond loosely echoing optimise and day, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource (the cheapest or greenest half hours to charge an electric car) and a specific constraint (ready-by time, up to four days ahead), which separates it from battery and heat-pump siblings. It never names the closest alternatives (find_cheapest_window, plan_home_battery), so differentiation is implied rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use or when-not-to-use guidance, and no mention of find_cheapest_window or plan_home_battery as alternatives. An agent must infer routing criteria from the one-line purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A home's past year on every tariff in list_tariffs and at Ofgem's price cap – and what switching tariff, an electric car, a heat pump, solar panels or a battery would save, each added to everything before it (tariff, car, heating, solar, battery). Each of car, heating, solar and battery is something the home has (it explains the bill) or is considering. Totals are electricity, gas at the price cap and petrol or diesel – only what changes.
| Name | Required | Description | Default |
|---|---|---|---|
| car | No | What the home drives now: `petrol` (default) or `diesel` (counted only with consider_ev=1), `ev` (the bill includes an electric car), or `none`. | petrol |
| gas | No | With heating=gas and consider_heat_pump=1: gas a year on the bill, kWh (1000-60000, default 9500). | |
| kwp | No | Panels, kWp (0.2-50; default 4 on a roof, 0.8 for a plug-in kit, at most 2) – the first roof face's, with more faces. | |
| mpg | No | With consider_ev=1: its real-world mpg (10-120; default the average car on the road, 36 petrol, 42 diesel). | |
| mpk | No | Electric car, miles per kWh at the battery (1.5-6, default 3.3). | |
| ppl | No | With consider_ev=1: what you pay, p/litre (50-400; default the UK weekly average over the past year). | |
| kwp2 | No | Roof panels on a second face, kWp (0.2-50), with `aspect2` and `tilt2` – and `kwp3`, `aspect3`, `tilt3` for a third. One inverter for them all. | |
| kwp3 | No | Roof panels on a third face, kWp (0.2-50). | |
| scop | No | With consider_heat_pump=1: the installer's seasonal efficiency for heating (1.5-6; default a typical installation). | |
| tilt | No | Or their exact angle from flat, degrees (0-90). Replaces `pitch` (or `mount`). | |
| unit | No | With tariff=custom: its unit rate, p/kWh (5-100). | |
| boost | No | With heating=storage: the share of their heat from evening boost at the day rate, % (0, 10 or 25; default 10). | 10 |
| miles | No | Car miles a year (500-40000, default 7100). | |
| mount | No | With panels=plug_in: its angle from flat – 90 (upright on a balcony or wall, default), 60 (leaning), 30 (on a stand), 10 (flat). | 90 |
| pitch | No | The roof: 35 (pitched, default), 20 (shallow), 50 (steep), 10 (flat). | 35 |
| shift | No | Share of everyday use run at the day's cheapest times, % (0, 15 or 30; default 0) – for fine-tuning. | 0 |
| solar | No | `no` (default), `have`, or `consider`. | no |
| tilt2 | No | The second face's angle from flat, degrees (0-90, default 35). | |
| tilt3 | No | The third face's angle from flat, degrees (0-90, default 35). | |
| usage | No | Electricity a year as on the bill, kWh – what's bought now (500-30000, default 2500). | |
| aspect | No | The way the panels face: S (default), SE, SW, E, W, NE, NW, N. | S |
| boiler | No | With consider_heat_pump=1: `condensing` (default) or `older` (pre-2005). | condensing |
| export | No | How export is paid: `paired` (default: each tariff's own export tariff), `fixed` (at `export_rate`), `fit` (the Feed-in Tariff's deemed export), `none`, or an export tariff's key from list_tariffs?direction=export – used with every tariff that can have it, and each tariff's own with the rest. | paired |
| hp_kwh | No | With heating=heat_pump: its own use, kWh a year, if known (0-20000; default estimated). | |
| panels | No | With solar=have or consider: `roof` (default) or `plug_in` (a plug-in kit: its inverter capped at 800 W, export unpaid, panels up to 2 kWp). | roof |
| region | Yes | Agile region: a letter A-P or the slug from list_regions (eg `C` or `london`); list_regions lists well-known places in each. | |
| switch | No | 1 (default) to find the best tariff at each step, staying put included; 0 to keep `tariff` throughout. | 1 |
| tariff | No | The tariff the home is on: `price-cap` (default), a key from list_tariffs, `tracker` (Octopus Tracker, off sale but priced for the homes on it), or `custom` with `unit` and `standing`. | price-cap |
| aspect2 | No | The second face's direction: S (default), SE, SW, E, W, NE, NW, N. | |
| aspect3 | No | The third face's direction. | |
| battery | No | `no` (default), `have`, or `consider`. | no |
| bearing | No | Or the exact compass bearing the panels face, degrees (0-359; south 180). Replaces `aspect`. | |
| charger | No | Home charger, kW (2-22, default 7). | |
| daytime | No | Whether anyone's home in the day: `usual` (default), `out` (rarely – out at work), or `home` (most days). Decides how much of the panels' output the home uses. | usual |
| heating | No | What heats the home now: `gas` (default), `oil` or `lpg` (a boiler), `solid` (wood or coal: `solid_fuel` says which) – counted only with consider_heat_pump=1 – `heat_pump` (the bill includes one), `storage` (storage heaters), `electric` (panel or other direct electric heaters), or `other`. | gas |
| hp_cost | No | With consider_heat_pump=1: the quote after grants, £ (0-100000; default typical, outside Scotland). | |
| plug_in | No | Hour the car is plugged in, 0-23 local (default 18). | |
| preheat | No | With heating=electric: `1` to heat from 1pm rather than 4pm–7pm when that's cheaper (default `0`). | 0 |
| heat_ppl | No | With heating=oil or lpg and consider_heat_pump=1: what's paid a litre, pence (20-300). Oil defaults to a recent national average; LPG has no default and needs it. | |
| keep_gas | No | With consider_heat_pump=1: 1 to keep gas for cooking (default 0). | 0 |
| plug_out | No | Hour it's unplugged, 0-23 local (default 7; the same as `plug_in`: always plugged in). | |
| standing | No | With tariff=custom: its standing charge, p/day (0-200). | |
| appliance | No | With heating=solid: `stove` (a stove or boiler, default) or `fire` (an open fire). | stove |
| night_gmt | No | `1`: the meter keeps GMT, so its night hours are an hour later in summer (default `0`). | 0 |
| replacing | No | With consider_heat_pump=1: 1 if the boiler is due for replacing anyway (default 0). | 0 |
| standby_w | No | Battery standby draw, W (0-200, default 20). | |
| battery_kw | No | Battery power, kW (0.5-15, default 3). | |
| charge_eff | No | Car charging efficiency, % (70-100, default 90). | |
| heat_spend | No | With heating=solid and consider_heat_pump=1: what the home spends on it a year, £ (10-20000). Needed, with heat_amount. | |
| heater_kwh | No | With heating=storage or electric: the heaters' own use, kWh a year, if known (0-30000; default estimated). Hot water is taken as an immersion heater. | |
| round_trip | No | Battery round-trip efficiency, % (60-100, default 90). | |
| solar_cost | No | With solar=consider: the quote or kit price, £ (0-100000; default typical). | |
| solid_fuel | No | With heating=solid: `logs` (default), `pellets` or `coal` (coal or smokeless fuel). | logs |
| storage_kw | No | With heating=storage: all the heaters' input power together, kW (1-30, default 6). | |
| battery_kwh | No | Battery, usable kWh (0.5-40, default 5). | |
| consider_ev | No | With a petrol or diesel car: 1 to see what an electric car replacing it would save (default 0). | 0 |
| export_rate | No | Your fixed export rate, p/kWh (0-100, default 12), with `export=fixed`. | |
| heat_amount | No | With heating=solid and consider_heat_pump=1: how much the home buys a year – logs in loose cubic metres, pellets and coal in kg (0.1-50000). Needed, with heat_spend. | |
| heat_litres | No | With heating=oil or lpg and consider_heat_pump=1: litres a year (100-10000; default as much heat as 9500 kWh of gas). | |
| inverter_kw | No | Solar inverter rating, kW (0.5-50; default no limit). | |
| night_start | No | The meter's seven night hours, for Economy 7 tariffs and meter-switched heaters: the half hour they start, 0-47 local (44 is 22:00 ... 3 is 01:30; default 1, 00:30-07:30). | 1 |
| battery_cost | No | With battery=consider: the quote, £ (0-100000; no default – no payback without one). | |
| export_limit | No | Export limit set by the network operator, kW (0.5-50; default none). | |
| storage_meter | No | With heating=storage: `1` (default) the meter switches them on in its night hours (and Snug Octopus can schedule them), `0` their own timer, in the cheapest night half hours. | 1 |
| battery_export | No | What the battery may export: `never`, even where the export tariff peaks; `solar`, only what it stored from the panels, even on Octopus's; `terms` (default), what the terms pay for – on Octopus's anything it holds, on other export tariffs only what it stored from the panels; `all`, anything it holds, on any export tariff (check the supplier pays for grid-charged export). | terms |
| battery_charge_kw | No | Battery charging power, kW (0.5-15, default `battery_kw`). | |
| consider_heat_pump | No | With a boiler (heating=gas, oil or lpg), wood or coal (heating=solid), or storage or electric heaters (heating=storage or electric): 1 to see what a heat pump replacing them would save (default 0). | 0 |
| battery_discharge_kw | No | Battery discharging power, kW (0.5-15, default `battery_kw`). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: results are cumulative across measures in a stated order, and each of car/heating/solar/battery is interpreted as either something the home has (explaining the bill) or something being considered. It does not mention any cost, latency or determinism beyond the idempotent annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no filler, and the core computation is front-loaded. However, the parenthetical '(tariff, car, heating, solar, battery)' and the nested clause 'Each of car, heating, solar and battery is something the home has (it explains the bill) or is considering' make it noticeably hard to parse on first read, which works against a tool an agent must interpret quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description bears some burden for describing returns; it gives one sentence on what totals are and that only changes are counted, but not the response shape, per-tariff breakdown, or units. For a 68-parameter, highly interdependent planning tool, the description is adequate but leaves meaningful gaps an agent would want covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the 68 parameters are already documented in detail, including defaults, ranges and conditional applicability. The description adds only a marginal framing statement ('Totals are electricity, gas at the price cap and petrol or diesel – only what changes') and does not clarify the cross-parameter dependencies (e.g. consider_ev, consider_heat_pump gating) beyond what the schema already says. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific computation: a home's past year on every tariff in list_tariffs and at the price cap, plus savings from switching, an EV, a heat pump, solar or a battery, applied cumulatively. That is far more than a restated title. It stops short of a 5 because it never contrasts itself with the siblings that overlap it most (plan_home_battery, plan_ev_charging, plan_home_solar-style single-technology planners), so an agent must infer that this is the whole-home, all-measures variant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: the phrase 'each added to everything before it (tariff, car, heating, solar, battery)' hints at a cumulative whole-home scenario, which suggests using this over the narrower sibling planners. There is no explicit when-to-use, when-not-to-use, or named alternative. An agent can guess the context but is given no routing rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| soc | No | The battery's charge now, per cent (0-100). Default: at its reserve. | |
| rate | No | Charge and discharge rate, kW (0.5-15, default 3). | |
| wear | No | The battery's wear for each kWh it gives back, pence (0-20, default 2). | |
| usage | No | The home's electricity use, kWh a year (500-30000, default 2500). | |
| export | No | How 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). | |
| region | Yes | Agile region: a letter A-P or the slug from list_regions (eg `C` or `london`); list_regions lists well-known places in each. | |
| tariff | No | A tariff's key from list_tariffs (default `agile`), eg `go`, `edf-go-electric`, `eon-next-drive`. | agile |
| battery | No | Usable battery, kWh (2-50, default 10). | |
| ceiling | No | Never charged above this, per cent (10-100, default 100; above `reserve`) – for an inverter set to stop short of full. | |
| reserve | No | Never below this, per cent (0-90, default 0). | |
| solar_kwp | No | The home's solar panels, kWp (0.2-50): the answer then counts their forecast spare sun – see the docs' Solar panels section. | |
| round_trip | No | Round-trip efficiency, per cent (60-100, default 90). | |
| export_rate | No | A fixed export rate, p/kWh (0-100). | |
| solar_pitch | No | Their angle from flat, degrees (0-90, default 35). | |
| export_limit | No | The home's export limit, kW (0-30, default 3.68: a G98 connection). | |
| solar_facing | No | The way they face: S, SE, SW, E, W, NE, NW or N – or a bearing in degrees (south is 180). Default S. | |
| grid_charging | No | `1` (default) may charge from the grid; `0` only from the panels. | 1 |
| battery_export | No | What 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_kw | No | The inverter's limit, kW (0.5-50), if smaller than the panels. |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
plan_home_battery1 field changedInput schema / properties / ceilingAdded 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"
+}find_cheapest_windowget_flexibility_eventsget_heat_pump_timesget_home_battery_timesget_priceslist_regionslist_tariffsplan_ev_chargingplan_homeplan_home_batteryCheapest half-hour Agile electricity prices by UK postcode.
Live and historical electricity prices and demand for 25 grids; carbon intensity for GB.
Electricity prices for Denmark and 40 European zones: spot price, cheapest hours, forecast.
Real-time electricity price signals for AI agents. Spot prices, cheapest hours, and contract recommendations. 31 countries across Europe and Oceania. No authentication required.
Add one secure layer between your agents and this server.