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.