UK Charging Solutions

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful provenance by naming the Department for Transport and source datasets (EVCI0102, VEH0142), which helps the agent trust and contextualise the figures, but says nothing about freshness, coverage gaps, or error behavior for unknown councils.

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 sentence that front-loads the resource and enumerates the returned facts without filler. The dataset-code parenthetical is slightly technical but earns its place as provenance.

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-parameter, read-only lookup with no output schema, the description usefully enumerates what comes back (counts, per-capita rate, rank, vehicles), which is exactly what the agent needs since no output schema exists to document the response shape.

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 sole parameter is fully documented in the schema with example name and slug formats. The description adds no parameter-level guidance, so the baseline of 3 applies — the schema does the work.

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 the resource (EV charging facts for a UK council area) and enumerates the specific measures returned — public/rapid chargers, chargers per 100,000, UK rank, plug-in vehicles. That is concrete enough to distinguish it from siblings like charger_size or charging_time, though the verb is implicit 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 guidance on when to use this tool versus alternatives, nor any stated prerequisites beyond the required council input. The agent must infer from the dataset content alone that this is a per-council statistics lookup.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds real value beyond that: data provenance (DESNZ QEP tables), freshness ('latest quarterly'), and the CCL inclusion/exclusion variants, which tells the agent what the numbers actually represent. It does not describe return shape or how far back the series goes.

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 dense sentences, front-loaded with the resource and scope; the caveat 'Statistics, not a quote' lands last for emphasis. Nothing is redundant and no sentence could be dropped without losing 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?

For a one-optional-parameter, read-only statistical lookup with no output schema, the description covers subject, segmentation, variants, and provenance well. Minor gaps: no indication of the time series depth available or the shape of returned values, which an agent might want since 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% and the single 'band' parameter is fully documented with an example and MWh range, so the schema does the heavy lifting. The description adds the framing that bands are annual-use size bands, but no matching syntax or accepted band list beyond the schema's example.

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?

Names a specific verb and resource (latest quarterly price per kWh paid by UK businesses), the segmentation (annual-use size band), the measurement variants (including/excluding Climate Change Levy), and the source (DESNZ QEP tables 3.4.1/3.4.2). The closing 'Statistics, not a quote' separates it from the sibling cost/quote tools such as charging_cost, commercial_solar_cost, and host_income_estimate.

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?

'Statistics, not a quote' gives a clear selection signal: use this for published official price data rather than for a personalised estimate. It stops short of naming an alternative sibling or stating exclusions, so it is clear context rather than explicit routing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful algorithmic context — it picks the *slowest* adequate standard charger and reports aggregate load — but says nothing about assumptions, edge cases, or failure conditions.

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 well-formed sentence that front-loads the primary output and appends the secondary one. It is dense but free of filler; a slightly clearer split of the two outputs would be marginally better.

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 must convey the return content — it does describe both the recommended charger and the bay load. What remains thin is the boundary against sibling tools and the meaning of 'standard charger' tiers.

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 all three parameters are already documented. The description gestures at 'wanted miles', 'typical stay', and 'every bay', which only loosely paraphrases the schema rather than adding units, ranges, or constraints. 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 verb ('suggests') and resource ('slowest standard charger') plus a secondary output ('total load'), so the agent knows exactly what is computed. It is distinguishable from siblings like charging_time, though it never names them explicitly to route the choice.

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?

Use context is implied by the inputs (dwell time, miles wanted, bays) — clearly a sizing/planning tool — but there is no explicit when-to-use, when-not-to-use, or comparison against siblings such as charging_time or area_charging_facts. The agent must infer the scenario.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already establish readOnlyHint=true and openWorldHint=false, so the agent knows this is a safe, self-contained calculation. The description usefully adds that rates come from dated sources and are UK-specific and that an own price can override them, but says nothing about rounding, currency output, or staleness handling.

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 dense sentence with no filler, and the core output units (per charge, per mile, per 100 miles) are front-loaded before the tariff qualifiers. Minor parenthetical load but nothing that wastes the reader's time.

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 no output schema, the description carries the return-shape burden and does describe the three cost figures produced. It is largely sufficient for a 4-parameter pure calculation tool, with only currency and precision left unstated.

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 battery_kwh, start_percent, end_percent and price_pence are already self-documenting. The description adds only the meaning of price_pence as an optional own price, which the schema also states, so 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?

States a specific computation (cost of one charge, per mile and per 100 miles) against named UK tariff bases, so the agent knows exactly what is produced. It does not, however, name or contrast itself with plausible siblings such as charging_time or charger_size, so differentiation relies on the name alone.

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 only implied: the mention of home cap, public and rapid prices suggests this is the costing tool rather than a timing or sizing tool. There is no explicit when-to-use/when-not statement and no routing to siblings such as charging_time for duration questions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already establish this as a read-only, closed-world computation. The description usefully adds that the result includes energy consumed and approximate miles added, which annotations cannot convey, but it does not address AC vs DC modeling, rounding, or assumptions behind the estimate.

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?

One dense, front-loaded sentence that leads with the primary output (duration) before the secondary outputs. Efficient, though the trailing clause about energy and miles is slightly compressed.

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 pure read-only calculator with no output schema, the description covers what it computes and what comes back. Optional parameters are fully documented in the schema, so remaining gaps (AC/DC assumptions, rounding) are minor rather than blocking.

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 all seven parameters are self-documenting including the DC flag and the AC/DC car rate defaults. The description only restates 'charger power' and 'two battery levels' at a conceptual level, adding no syntax or constraint detail beyond the schema baseline.

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?

States a specific computation: charge duration between two battery levels at a given charger power, plus the derived energy and mileage outputs. The resource (EV charging time) is unambiguous and clearly distinct from siblings like charger_size or area_charging_facts, though it does not explicitly name a sibling.

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?

No when-to-use, when-not-to-use, or prerequisite guidance is given. The agent can infer this is a calculator from the parameter-shaped phrasing, but nothing routes it here versus charger_size or area_charging_facts.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already establish readOnlyHint=true and openWorldHint=false, so safety is covered. The description goes further by disclosing data provenance and method (DESNZ/MCS cost records, PVGIS reference-city generation, simple payback at the DESNZ small-business price), which tells the agent how the numbers are constructed and that they are modelled rather than live-queried.

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 sentence with no filler; the three returned metrics are front-loaded and the qualifiers (size band, geography) trail them. It is dense enough that the parenthetical sources interrupt the read slightly, but nothing is redundant.

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 no output schema, the description correctly enumerates the three return values, and the annotations cover the safety profile. Minor gaps remain – units for payback (years) and generation (kWh) are not stated – but an agent has enough to call the tool and interpret the response.

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 schema documents the default kW=30 and the region format, but the description adds the validity range (10-50 kW) for kw and clarifies that region means a Great Britain region – information not present in the schema. That is meaningful added meaning over structured 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 names the exact resource it returns – average cost per kW, yearly generation, and simple payback – plus the size band (10-50 kW) and geography (Great Britain region). It is precise enough that an agent can tell it computes solar economics rather than charging economics, though it never explicitly names or rules out the closest siblings (charging_cost, business_electricity_prices).

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 statement and no alternative tool is named, even though siblings like charging_cost and business_electricity_prices overlap in domain. The only implicit scoping is the 10-50 kW / Great Britain range, so the agent must infer the use case from the metrics listed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already establish that this is a safe, non-writing, closed-domain read (readOnlyHint true, openWorldHint false), so the bar is lower. The description adds useful context by promising 'official sources and checked dates', which hints at provenance and freshness of the answer, but it does not state that results are advisory, may not reflect the latest HMRC/OZEV rule changes, or how stale the checked dates might be.

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 that identifies both schemes immediately, with no preamble or filler. The trailing 'official sources and checked dates' clause earns its place by signalling result provenance.

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 six-parameter tool with no output schema, the description should say more about what comes back — eligibility verdict, grant amount, relief value, or all three — since cost and sockets suggest computed monetary outcomes. It covers what the tool checks but not what the caller receives, leaving a real gap.

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%, with each of the six properties (org, tax, cost, in_uk, sockets, off_street) documented inline, so the schema carries the semantics. The description adds nothing about these inputs, and the baseline of 3 applies when structured fields do the heavy lifting.

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 (checks) and two concrete resources: the Workplace Charging Scheme grant and the 100% first-year allowance. This distinguishes it from informational siblings like area_charging_facts, charger_size and charging_time, though it never explicitly frames itself as an eligibility/entitlement check the way an agent might need.

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 call this vs the sibling tools or what preconditions exist (e.g. must the user already own chargepoints, must the site be in the UK). The schema implies eligibility-checking inputs but the description offers no when/when-not routing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already establish readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds a genuinely non-obvious trait beyond them: that missing inputs silently resolve to calculator example figures, which materially affects result interpretation and drives the explicit 'state the assumptions' instruction.

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, the purpose front-loaded before the defaulting rule, with no redundancy or filler. Each 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 no output schema, the description still conveys that three funding models are compared on three metrics, which is enough to know what comes back. It does not describe the shape of the result (per-model breakdown, units, year basis), a minor remaining gap for a computation tool.

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 per-field meanings are already documented and the baseline would be 3. The description goes beyond it by explaining the default-value semantics for every omitted parameter (example calculator figures), which the schema does not disclose.

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?

States a specific verb ('compares') plus the exact outputs (upfront cost, yearly income, payback) and the scope (fully/part/self funded chargers). This clearly separates it from data-lookup siblings like area_charging_facts or grant_check, though it never names an alternative explicitly.

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?

Gives clear calling context: all inputs are optional and omitted values fall back to the site calculator's example figures, plus an instruction to surface those assumptions to the user. It stops short of naming when to prefer a sibling tool, so it isn't a full 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations only cover the safety profile (readOnly=false, openWorld=true, idempotent=false); the description adds genuinely new behavioral context — third-party data sharing, a possible referral fee, and the success signal ('Returns ok true when sent'). It does not describe failure behavior or whether data is retained, so it stops short of a 5.

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 short sentences with no filler; the disclosure of third-party sharing is front-loaded ahead of the call precondition and the return value, which is the right ordering for an agent deciding whether to invoke.

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 mutation tool with full annotation coverage, a complete schema, and no output schema, the description covers purpose, consent precondition, third-party disclosure, and return shape. It omits error/failure behavior and retry semantics, which keeps it from being fully complete.

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% with 10 well-documented parameters and three enums, so the schema carries the parameter burden and baseline 3 applies. The description only indirectly echoes the consent_to_share requirement ('agreed to share these details') and adds no syntax or format detail beyond 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?

States a specific verb and resource ('sends the user's site details to UK Charging Solutions') and names the downstream recipient, so an agent can instantly tell this submission tool apart from the read-only calculator/fact siblings. The side effect (possible referral fee via an installer partner) is stated up front.

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?

Gives an explicit gating condition: 'Only call this when the user asked to be contacted and agreed to share these details.' That is a clear when-to-use rule, though it never names an alternative tool (e.g. host_income_estimate) for users who are merely exploring rather than requesting contact.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.