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 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 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 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 already declare this is a non-read-only, open-world, non-idempotent write, so the bar is lower; the description still adds material context they cannot convey: third-party data sharing with an installer partner, a possible referral fee, and the consent gate. It also notes the success signal ('Returns ok true when sent'), 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?

Three sentences, each earning its place: purpose and recipient first, the consent precondition second, the return signal last. No filler or repetition of schema 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?

For a 9-parameter, 7-required write tool with no output schema, the description covers purpose, gate, data-sharing implications, and success signal adequately. It omits what happens on failure or after submission (contact timing, error responses), which would round it out.

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 two enums are fully documented in the schema, so the baseline is 3. The description only echoes the consent requirement already stated in consent_to_share's schema description and does not add format, validation, or default guidance beyond it.

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 ('Sends the user's site details') and identifies the recipient (UK Charging Solutions), making the write/submission nature unmistakable versus the informational siblings (area_charging_facts, charger_size, host_income_estimate). An agent can distinguish it from every sibling 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?

It gives an explicit precondition: 'Only call this when the user asked to be contacted and agreed to share these details.' That is clear when-to-use guidance with a hard gate, though it does not name alternatives or spell out when-not to call beyond the consent condition.

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