Verified UK energy tariffs, the Ofgem price cap by region and EV charging prices, with sources.
Use this when a user wants to know what a specific public charge would cost, e.g. "adding 40 kWh at a rapid charger", or which network is cheapest for a given session. Give the energy in kWh and the charger power band; optionally restrict to a pricing basis. Returns a cost table sorted cheapest first, with pence per kWh, connection fee, subscription fee, idle fee, and the session cost in GBP for each network and plan, each with source_url and verified_at.
| Name | Required | Description | Default |
|---|---|---|---|
| kwh | Yes | Energy to add in kWh, e.g. 40. | |
| basis | No | Restrict to one pricing basis; omit to compare all. | |
| power_band | Yes | Charger power band. | |
| include_unverified | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does disclose the return shape: a cost table sorted cheapest first with fields like pence per kWh, connection fee, subscription fee, and source_url. However, it does not mention side effects, data limitations, or how unverified data is handled, leaving some behavioral ambiguity.
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 compact and front-loaded with the usage trigger, followed by required inputs and the output shape. Every sentence contributes useful information, and there is no filler or repetition.
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?
Given the absence of an output schema, the description does well by listing the returned fields, sort order, and source metadata. The main gap is the unexplained include_unverified boolean parameter, which could affect result interpretation, but the overall description is sufficient for correct tool selection and basic invocation.
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 already covers 75% of the parameters with descriptions, and the tool description adds usable context by explaining that energy, power band, and optional pricing basis are what the caller supplies. The description does not add meaningful detail beyond the schema, and the include_unverified parameter is undocumented in both schema and description, so it cannot fully compensate for that gap.
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 a specific verb and resource: compare the cost of one public charging session across networks. It gives an explicit use case and examples ('adding 40 kWh at a rapid charger'), and it distinguishes itself by focusing on per-session cost comparison and cheapest-network ranking rather than general price listings.
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 says exactly when to use this tool ('when a user wants to know what a specific public charge would cost' or which network is cheapest) and explains the required inputs ('Give the energy in kWh and the charger power band'). It provides clear contextual guidance but does not explicitly name sibling alternatives or state 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.
Use this before quoting figures when the user cares how current the data is, or when another tool returns an as_of date that looks old. Returns, per dataset (tariffs, tariff rates, price cap, charging networks, charging prices), the number of verified rows and the newest and oldest verified_at dates, the price cap period currently in force, and recent sync runs. Free to call and not counted against the free tier.
| 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 behavioral disclosure burden. It states that the tool is free to call and not counted against the free tier, and it details exactly what information will be returned across datasets. This is sufficient for a read-only freshness check and contains no contradictions.
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 no filler. The first sentence front-loads the intended use case, and the second condenses the full return summary and cost note. Every sentence earns its place.
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?
With zero parameters and no output schema, the description provides all needed operational context: when to call the tool, what it returns, which datasets it covers, and its cost behavior. An agent can decide to invoke it correctly without additional inference.
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, so the empty schema is fully self-describing and there are no parameter ambiguities. The description adds useful context by explaining that results are organized per dataset, which helps the agent interpret the output even without an output 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 clearly states the tool's purpose: checking data freshness before quoting figures or when an as_of date looks old. It enumerates the specific return values per dataset, which distinguishes it functionally from the sibling data-query tools even without naming them.
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 gives explicit triggering conditions: use it when the user cares about data currency or when another tool returns a stale-looking as_of date. It does not explicitly state when not to use it or name alternative tools, but the context is clear enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when a user asks how much it costs to charge an electric car at a public charger in the UK, what a named network (InstaVolt, Gridserve, BP Pulse, Tesla, Ionity, Osprey, Shell Recharge, Pod Point and others) charges per kWh, or what subscription, connection and idle fees apply. Filter by network slug, power band (ac_slow_7kw, ac_fast_22kw, dc_rapid_50kw, dc_ultra_150kw_plus) and pricing basis (contactless_payg, app_payg, member, subscription). Prices are pence per kWh including VAT with source_url and verified_at. For a cost comparison of one charging session use compare_ev_charging_cost.
| Name | Required | Description | Default |
|---|---|---|---|
| basis | No | ||
| limit | No | ||
| network | No | Network slug, e.g. instavolt, gridserve, bp-pulse, tesla-supercharger, ionity, osprey, shell-recharge, pod-point. | |
| power_band | No | ||
| include_unverified | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and discloses useful behavioral traits: prices are pence per kWh including VAT, results carry source_url and verified_at provenance, and subscription/connection/idle fee dimensions are covered. However, the default behavior of the include_unverified parameter (whether unverified prices are filtered out by default) is not stated, which is a meaningful data-quality trait left undisclosed.
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, each with a distinct job: trigger condition, filter dimensions, output format plus sibling routing. The trigger is front-loaded and there is no filler, though the middle sentence packs four enum lists inline and is slightly dense 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 tool with 5 parameters, no annotations, and no output schema, the description covers the core purpose, filter semantics, units, and provenance well. But it omits the semantics of limit and include_unverified, and since there is no output schema it only partially describes the response shape (source_url and verified_at named, but not the actual price/fee fields returned).
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 only 20% (network), so the description must compensate. It does add meaning to the two bare enums by decoding them (ac_slow_7kw, ac_fast_22kw, dc_rapid_50kw, dc_ultra_150kw_plus; contactless_payg, app_payg, member, subscription) and gives example network slugs. But limit (what it caps) and include_unverified (what 'unverified' means, default behavior) are left unexplained in both the schema and the description, so compensation is only partial.
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 opens with a specific, actionable trigger ('Use this when a user asks how much it costs to charge an electric car at a public charger in the UK') and names the exact domain (UK public EV charging prices). It enumerates the covered content (per-kWh rates, subscription, connection, and idle fees) and named networks, and explicitly distinguishes itself from compare_ev_charging_cost, so an agent can separate it from siblings without opening the 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?
Provides an explicit when-to-use condition ('Use this when...') covering multiple query phrasings, and gives a direct alternative routing for the nearest sibling ('For a cost comparison of one charging session use compare_ev_charging_cost'). The 'public charger in the UK' framing implicitly excludes home-tariff siblings like get_uk_ev_tariffs and get_ofgem_price_cap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when a user asks what the current UK energy price cap is, the default tariff unit rate or standing charge in their region, or how the cap compares between direct debit, standard credit and prepayment. Returns Ofgem's default tariff cap per region, fuel and payment method for the period in force today, or for a given date via period (the next quarter is usually on file as soon as Ofgem announces it; the response note lists every period held). Values are pence per kWh and pence per day including VAT, with the Ofgem source_url and verified_at. Not for individual supplier tariffs (use get_uk_energy_tariffs).
| Name | Required | Description | Default |
|---|---|---|---|
| fuel | No | ||
| period | No | A date inside the cap period you want, YYYY-MM-DD. Default today. | |
| region | No | GB electricity region: GSP group letter A to P (no I or O), or GB for the national average. Omit to get every region. | |
| payment_method | No | ||
| include_history | No | Return all stored cap periods, not just the one in force. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does a good job: it states what is returned (cap per region, fuel, payment method), units (pence per kWh and pence per day including VAT), metadata (source_url and verified_at), and the period behavior including advance availability of the next quarter. It does not explicitly state 'read-only' or discuss rate limits, but 'Returns...' makes the read nature clear enough.
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 information-dense with no filler. Every sentence earns its place: the opening sentence defines the use case, the middle sentences specify output units and period behavior, and the final sentence excludes the wrong tool. It is slightly longer than minimal but all content is directly useful to an agent.
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 read-only data lookup with five optional parameters and no output schema, the description covers the input intent, the output format, the units, the temporal behavior, and the boundary against sibling tools. Nothing an agent needs to decide whether to call it or interpret its result is missing.
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 60%, and the description adds meaningful context beyond the schema: it explains the default period behavior, that the next quarter is usually on file, the unit semantics, and that values include VAT. It also clarifies what the three payment methods refer to and ties the return values to unit rates and standing charges. It does not add much for the region parameter beyond what the schema already states, but overall it compensates well for the coverage gap.
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 verb ('Use this when...'), the resource ('Ofgem default tariff cap'), and the exact scope: current UK energy price cap, unit rate, standing charge, and payment method comparisons. It also distinguishes itself from individual supplier tariffs, so an agent can reliably separate it from get_uk_energy_tariffs.
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 explicitly states when to use the tool ('when a user asks what the current UK energy price cap is, the default tariff unit rate or standing charge in their region...') and explicitly excludes the alternative use case ('Not for individual supplier tariffs') while naming the sibling tool to use instead (get_uk_energy_tariffs). This is strong routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when a user asks what a UK domestic electricity or gas tariff costs, wants to compare suppliers, or needs unit rates (p/kWh), standing charges (p/day), off-peak windows, exit fees or export (SEG) rates. Covers standard variable, fixed, time-of-use, Economy 7, tracker, Agile, heat pump and export tariffs from Octopus Energy and other GB suppliers. Filter by region (GSP letter), tariff type, supplier slug or fuel. Every row carries source_url and verified_at; quote them. Not for public EV charging prices (use get_ev_charging_prices) or the Ofgem cap (use get_ofgem_price_cap).
| Name | Required | Description | Default |
|---|---|---|---|
| fuel | No | ||
| type | No | Tariff type. ev_tou = cheap overnight EV tariffs; smart_tou = other time-of-use; export = SEG export tariffs. | |
| limit | No | ||
| region | No | GB electricity region: GSP group letter A to P (no I or O), or GB for the national average. Omit to get every region. | |
| supplier | No | Supplier slug, e.g. octopus-energy, edf, eon-next, british-gas, ovo-energy, scottishpower. | |
| payment_method | No | ||
| include_unverified | No | Also return rows we have not verified against a primary source. Default false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does substantial work: it discloses that every returned row carries source_url and verified_at and instructs the agent to quote them, and it explains the verification posture by covering unverified rows. It does not mention pagination, result limits, or operational failure modes, but for a read-only query tool the citation-behavior disclosure is the most decision-relevant trait and it is present.
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?
Four dense sentences, each earning its place: trigger conditions, data/coverage scope, filter guidance, output-citation behavior, and exclusions with alternative routings. The structure is front-loaded with the 'when to use' trigger. It is slightly long-winded ('Use this when a user asks what...') but no sentence 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?
For a 7-parameter tool with no annotations and no output schema, the description covers triggers, data fields, coverage, and citation behavior well. However, it never disambiguates against the sibling get_uk_ev_tariffs despite the schema containing ev_tou and ev_addon tariff types that plausibly overlap, and it does not explain limit/default result behavior or how freshness relates to get_data_freshness.
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 57% (region, supplier, type, include_unverified documented in schema; fuel, limit, payment_method undocumented). The description adds domain meaning that helps fill gaps — it maps tariff types to real-world concepts (Economy 7, Agile, tracker) and explains that fuel covers electricity/gas — but it largely restates the filter parameters ('Filter by region (GSP letter), tariff type, supplier slug or fuel') rather than clarifying limit or payment_method semantics.
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 verb and resource ('get' + 'UK domestic electricity or gas tariff') and enumerates the exact data returned: unit rates (p/kWh), standing charges (p/day), off-peak windows, exit fees and SEG export rates. It also distinguishes itself from siblings by explicitly excluding public EV charging prices and the Ofgem cap, and by naming the alternative tools for those cases.
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 opens with explicit trigger conditions ('Use this when a user asks what a UK domestic electricity or gas tariff costs...') and gives explicit negative routing: 'Not for public EV charging prices (use get_ev_charging_prices) or the Ofgem cap (use get_ofgem_price_cap).' It also describes the coverage scope (Octopus Energy and other GB suppliers, standard variable through export tariffs), making the selection decision nearly unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when a user with an electric vehicle asks which home electricity tariff is cheapest for charging, what the overnight rate and window are, or whether a tariff needs a smart meter, a compatible charger or a specific car. Returns EV time-of-use tariffs (cheap whole-home overnight window) and EV add-ons (credits for smart-scheduled charging on a standard tariff). Filter by region. Every row carries source_url and verified_at. For public rapid charger prices use get_ev_charging_prices instead.
| Name | Required | Description | Default |
|---|---|---|---|
| region | No | GB electricity region: GSP group letter A to P (no I or O), or GB for the national average. Omit to get every region. | |
| supplier | No | ||
| include_unverified | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It does disclose the output kinds and the per-row presence of source_url and verified_at, and it implies a read-only data lookup. But it does not explain the default behavior of include_unverified or what 'unverified' means, and 'Every row carries verified_at' sits awkwardly with an include_unverified parameter.
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 use cases and ending with a sibling alternative. Every sentence contributes: usage triggers, return content, row metadata, and when not to use it. No filler or redundant restatement of the tool name.
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 is responsible for explaining return values; it does so at a high level by naming the two tariff types and provenance fields. However, it leaves the optional filter parameters underspecified and does not fully resolve routing against compare_ev_charging_cost, making it adequate but not complete for agent decision-making.
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 only 33%; only region is documented. The description repeats 'Filter by region' but adds nothing about supplier or include_unverified, so it fails to compensate for the low coverage. The include_unverified boolean is particularly consequential and is left largely to inference from its name.
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 starts with concrete user intents: cheapest home tariff for EV charging, overnight rate/window, and hardware requirements. It then names the exact outputs: EV time-of-use tariffs and EV add-ons, which clearly distinguishes it from sibling tools like get_ev_charging_prices and get_uk_energy_tariffs.
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 gives explicit when-to-use scenarios and explicitly routes public rapid charging to get_ev_charging_prices instead. However, given the sibling compare_ev_charging_cost, it would be stronger to also clarify how to choose between this tariff-data tool and a cost-comparison tool for 'cheapest' questions.
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. Dates show when Glama detected each change.
compare_ev_charging_costget_data_freshnessget_ev_charging_pricesget_ofgem_price_capget_uk_energy_tariffsget_uk_ev_tariffsClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Current UK tax-year rates and thresholds, verified against gov.uk with source URLs and dates.
Live and historical electricity prices and demand for 25 grids; carbon intensity for GB.
Real-time electricity prices for AI agents. 40+ countries, 100+ zones. No auth required.
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.
Each tool maps to a distinct resource: Ofgem price cap, general domestic tariffs, EV-specific home tariffs, public charging prices, a charging-session cost comparison, and dataset freshness. The descriptions actively cross-reference the two pairs that could seem similar, so an agent should not misselect.
All tool names follow a clear lower_snake_case verb_noun pattern, mostly get_<domain> with compare_ev_charging_cost as a purposeful exception for a distinct comparison action. There is no mixed casing or inconsistent verb style.
Six tools is a well-scoped size for a UK energy data server. Each tool covers a meaningful slice of the domain and none are redundant or trivial.
The set covers the advertised domain end-to-end: Ofgem price cap, domestic energy tariffs, EV home tariffs, public charging prices, specific charging-session cost comparison, and data-freshness metadata. A user can obtain rates, calculate a session cost, and verify data currency without dead ends.