GB solar/battery comparisons and Ofgem rates. Five trial calls, then 0.01 USDC per eligible call.
Scored across 6 tools
The tools are mostly distinct: compare_solar_battery creates a new comparison, the two recover_* tools retrieve existing results, and the get_* tools return reference or account information. The only potential confusion is between recover_saved_lookup and recover_solar_battery_comparison, but the descriptions clarify that they handle different resource types (general saved lookups vs. solar-battery scenarios).
All tool names follow a consistent snake_case verb_noun pattern, with verbs get_, compare_, and recover_ clearly mapping to distinct operation types. The naming is predictable and internally coherent.
Six tools is well within the ideal range and each tool earns its place: one core computation, three information lookups, and two recovery operations. There is no redundancy or bloat relative to the server's stated scope.
The core solar-battery comparison workflow is fully covered with create and recover operations, supported by price cap, data freshness, and registration requirement lookups. The mention of EV lookups in recover_saved_lookup suggests a missing EV lookup tool, but the primary solar/battery domain is well served.
Compare solar alone with up to three battery sizes for a GB household. Supplied monthly kWh, hourly shapes, fixed rates and costs; screening estimate, not a forecast. Reports losses, forgone exports, marginal battery savings and generation sensitivity. Five shared trial uses, then 0.01 USDC per comparison. See /docs/solar/ and /v1/solar/example.
| Name | Required | Description | Default |
|---|---|---|---|
| country | Yes | ||
| input_basis | Yes | ||
| inputs_as_of | Yes | ||
| model_version | Yes | ||
| battery_options | Yes | ||
| export_rate_pence | Yes | ||
| import_rate_pence | Yes | ||
| solar_hourly_weights | Yes | ||
| demand_hourly_weights | Yes | ||
| monthly_generation_kwh | Yes | ||
| monthly_consumption_kwh | Yes | ||
| solar_installed_cost_gbp | Yes | ||
| standing_charge_pence_per_day | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It discloses the screening nature, the outputs reported, the cost after five trial uses, and directs to docs/example. It does not mention whether comparisons are saved or recoverable, which the sibling recover_solar_battery_comparison hints at, so the disclosure is good but not exhaustive.
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 with the main purpose front-loaded and no filler. The cost and docs references are useful, though the middle sentence packs output details and caveats densely rather than using structured formatting.
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?
The tool has 13 required parameters, no output schema, and no annotations, so the description needs to carry a heavy load. It provides an overview, cost model, output areas, and docs links, but it does not describe the input format, array constraints, enum meanings, or return structure sufficiently for an agent to invoke it correctly without external documentation.
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 0%, so the description must compensate for 13 undocumented required parameters. It loosely groups inputs into 'monthly kWh, hourly shapes, fixed rates and costs,' but does not explain key parameters such as input_basis, inputs_as_of, model_version, battery_options fields, or the meaning of hourly weight arrays. This leaves significant semantic gaps.
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?
Description states a specific verb and resource: compare solar alone against up to three battery sizes for a GB household. It also distinguishes this from the sibling retrieval/lookup tools by indicating this is an analytical comparison tool, with a clear caveat that it is a screening estimate, not a forecast.
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: the tool is for comparing solar/battery configurations using monthly kWh, hourly shapes, and cost inputs. It does not explicitly name alternatives or state when not to use it, though 'not a forecast' provides a partial exclusion. No sibling routing is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free business customer registration requirements for paid lookups. Registration uses REST; pass the resulting token as customer-token in MCP request metadata.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the authentication method (REST, token in metadata) but does not clarify whether the tool itself performs registration or merely returns instructions. There are no annotations to contradict, but side effects, network calls, or state changes are not mentioned.
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 concise, consisting of two clear sentences. The first sentence states the primary purpose, and the second sentence provides authentication guidance, with no redundant or filler content.
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?
The description gives enough context to understand the tool's role and how to use the token, but it is ambiguous whether the tool outputs the requirements or performs the registration. It does not describe the output format or what the user should do with the requirements, which leaves some gaps given there is 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?
The tool has zero parameters, and the schema coverage is trivially 100%. The description does not need to explain any parameters, but it also adds no parameter-related semantics beyond the token passing instruction, which is relevant to MCP metadata rather than tool parameters.
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 the tool provides 'free business customer registration requirements for paid lookups,' which clearly indicates its purpose is related to registration requirements. It is distinguishable from sibling tools like get_data_freshness and get_ofgem_price_cap, though the phrase could be more explicit about the tool returning a list of requirements.
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 description explains that registration uses REST and that the resulting token should be passed as customer-token in MCP request metadata, giving practical usage guidance. However, it does not explicitly say when to use this tool over the siblings, such as 'use this before paid lookups' or 'use this to obtain access requirements.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free pilot coverage, trial allowance and payment mode. Also identifies the free REST freshness endpoint.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of explaining behavior. It mentions identifying an endpoint but does not disclose what the tool returns, whether it performs a read-only lookup, whether it makes external calls, or what 'free pilot coverage' means in relation to the operation.
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 two sentences are short but poorly structured and not front-loaded. The first sentence is an unexplained list, and the second uses 'Also' without a clear connection, so neither sentence earns its place effectively.
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?
Despite having no parameters and no output schema, the description still leaves an agent without enough context to know what invoking this tool will yield or how it relates to the sibling tools. The meaning of 'free pilot coverage, trial allowance and payment mode' is undeveloped and the freshness endpoint identification is underspecified.
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?
The tool has zero parameters and the schema is empty, so there is nothing the description needs to add. The baseline of 4 applies because no parameter documentation burden exists.
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 does not state a clear verb+resource pair. 'Free pilot coverage, trial allowance and payment mode' is an unclear noun phrase, and 'identifies the free REST freshness endpoint' only vaguely connects to the tool name without explaining what the tool actually does or 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?
There is no guidance on when to use this tool or how it compares to siblings like get_customer_requirements or get_ofgem_price_cap. The phrase 'Also identifies...' hints at a purpose but provides no decision context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Single-rate GB Ofgem reference price. Supply exact region or explicit GB average, fuel and payment method. Unsupported, empty or stale results are not charged. Not a household bill ceiling.
| Name | Required | Description | Default |
|---|---|---|---|
| fuel | Yes | ||
| period | No | ||
| region | Yes | ||
| payment_method | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
It discloses that unsupported, empty, or stale results will not be charged, giving a hint about error behavior. However, it does not mention any side effects, rate limits, or other behavioral aspects. Since no annotations are provided, the description carries the burden but only partially covers it.
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 concise and to the point, with no redundant words. It efficiently conveys the tool's purpose and key constraints in a few sentences.
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?
The description lacks details about the return structure (only states 'reference price' without specifying format) and does not explain the 'period' parameter or potential error responses. Given the absence of an output schema, the agent may not know what to expect from the response or how to handle edge cases beyond the single note about unsupported/stale results.
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?
The description mentions fuel and payment method but does not explain the 'period' parameter or the allowed region values (beyond 'exact region or explicit GB average'). With a schema coverage of 0%, the description fails to elaborate on the meaning or format of most parameters, leaving the agent to infer from the schema enums alone.
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 that the tool returns the GB Ofgem reference price for single-rate tariffs, and distinguishes it from a household bill ceiling. It also specifies the required inputs (fuel, payment method, region or GB average), making the purpose unambiguous.
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 description provides some differentiation (it is a reference price, not a bill ceiling) and notes that unsupported, empty, or stale results are not charged, but it does not explicitly indicate when to use this tool over the sibling tools or provide a clear decision context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recover an existing paid or trial result with its original credential, idempotency key and exact query, including withdrawn EV lookups. Never starts a new lookup or payment.
| Name | Required | Description | Default |
|---|---|---|---|
| fuel | No | ||
| kind | Yes | ||
| period | No | ||
| region | Yes | ||
| payment_method | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must convey behavior. It states that the operation recovers a result with the original credential and key, and never starts new work, indicating a read-only, idempotent retrieval. It also mentions including withdrawn EV lookups, which is a specific behavioral detail.
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 two sentences, with the purpose stated first and a key constraint second. It contains no filler or redundant information.
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?
The description provides a clear purpose and constraint but lacks parameter semantics, which are essential for invoking the tool correctly. Given there is no output schema and no parameter descriptions, the description alone is insufficient for a complete understanding. However, the tool's scope is limited to recovery, so the missing details are mostly about input fields.
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?
The schema has five properties with no descriptions, and the description does not explain any of them. There is no mapping from 'fuel', 'kind', 'period', 'region', or 'payment_method' to the recovery process. The description mentions 'exact query' but doesn't connect it to the parameters, leaving the agent without guidance on how to populate the fields.
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's purpose: recovering an existing paid or trial result with original credential, idempotency key and exact query, including withdrawn EV lookups. It also explicitly states it never starts a new lookup or payment, which distinguishes it from any new-lookup functionality. The sibling tools are all 'get' operations for other data, so this is distinct.
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 gives a clear constraint: 'Never starts a new lookup or payment,' which tells the agent when not to use it. However, it doesn't explicitly name alternative tools for starting new lookups, but the sibling list doesn't include such a tool, so the guidance is adequate. The term 'Recover' implies using it when a saved result is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recover an existing solar-battery-v1 result with the identical scenario and original trial UUID or payment credential. Never starts a calculation or purchase.
| Name | Required | Description | Default |
|---|---|---|---|
| country | Yes | ||
| input_basis | Yes | ||
| inputs_as_of | Yes | ||
| model_version | Yes | ||
| battery_options | Yes | ||
| export_rate_pence | Yes | ||
| import_rate_pence | Yes | ||
| solar_hourly_weights | Yes | ||
| demand_hourly_weights | Yes | ||
| monthly_generation_kwh | Yes | ||
| monthly_consumption_kwh | Yes | ||
| solar_installed_cost_gbp | Yes | ||
| standing_charge_pence_per_day | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden. It adds a valuable non-side-effect guarantee ('Never starts a calculation or purchase') that is especially relevant given the mention of 'payment credential'. But it does not disclose what happens on a mismatched UUID/credential, whether payment is re-validated, or what data is returned.
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?
Two sentences, front-loaded with the recovery purpose and closed by a useful exclusion. There is zero filler, and every clause adds meaning.
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 tool with 13 required parameters, no output schema, and a sibling with overlapping recovery scope (recover_saved_lookup), this description is too thin. An agent still cannot determine how the parameters encode the 'identical scenario', what the recovered result looks like, or when to prefer this tool over recover_saved_lookup.
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 0%, so the description needed to compensate, yet it explains none of the 13 required parameters. It also introduces 'trial UUID or payment credential' as the identification mechanism while the schema contains no such field, leaving the matching semantics ambiguous.
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 uses the specific verb 'Recover' with a concrete resource ('existing solar-battery-v1 result'), and states the retrieval key ('identical scenario and original trial UUID or payment credential'). 'Never starts a calculation or purchase' explicitly separates it from the sibling compare_solar_battery, so an agent can pick this tool without opening any schema.
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?
'Never starts a calculation or purchase' provides a clear boundary: use this when an existing result must be retrieved, not when new work is wanted. However, it never names an alternative (e.g., compare_solar_battery or recover_saved_lookup) or spells out the exact conditions that should route an agent to one of them.
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.
compare_solar_batteryrecover_solar_battery_comparisoncompare_ev_charging_costget_customer_requirementsget_ev_charging_pricesget_ofgem_price_cap6 fields changedInput schema / properties / include_historyRemoved value: -{
- "description": "Return all stored cap periods, not just the one in force.",
- "type": "boolean"
-}Input schema / properties / period / descriptionRemoved value: -"A date inside the cap period you want, YYYY-MM-DD. Default today."Input schema / properties / period / patternRemoved value: -"^\\d{4}-\\d{2}-\\d{2}$"Input schema / properties / region / descriptionRemoved value: -"GB electricity region: GSP group letter A to P (no I or O), or GB for the national average. Omit to get every region."Input schema / properties / region / enumRemoved value: -[
- "A",
- "B",
- "C",
- "D",
- "E",
- "F",
- "G",
- "H",
- "J",
- "K",
- "L",
- "M",
- "N",
- "P",
- "GB"
-]Input schema / requiredAdded value: +[
+ "region",
+ "fuel",
+ "payment_method"
+]get_uk_energy_tariffsget_uk_ev_tariffsrecover_saved_lookupcompare_ev_charging_costget_data_freshnessget_ev_charging_pricesget_ofgem_price_capget_uk_energy_tariffsget_uk_ev_tariffsReal-time electricity price signals for AI agents. Spot prices, cheapest hours, and contract recommendations. 31 countries across Europe and Oceania. No authentication required.
Real-time electricity prices for AI agents. 40+ countries, 100+ zones. No auth required.
Rooftop solar potential, RGE installer search and quote requests. France only, no API key.
Live and historical electricity prices and demand for 25 grids; carbon intensity for GB.
Add one secure layer between your agents and this server.