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.