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

Annotations already cover the safety profile (readOnly, idempotent, open world, non-destructive), so the bar is lower. The description adds two pieces of genuinely useful context beyond annotations: the upstream data source (MET Norway) and the cost of 1 credit. It does not disclose units, forecast freshness, or which days default applies, which are behavioral traits an agent would benefit from.

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 covering capability, input modes, and source, with the credit cost neatly bracketed at the end. Nothing is wasted, though the parenthetical cost could sit more prominently for cost-sensitive agents.

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 should indicate what comes back; it does so at a high level ('current conditions and daily forecast'). For a 4-parameter, zero-required, read-only tool this is largely sufficient, with the remaining gap being default behavior when only some or none of the inputs are supplied.

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 baseline is 3. The schema descriptions are extremely terse ('number 1-9', 'number'), and the description only marginally compensates by indicating that 'days' relates to the daily forecast horizon and that place must be a UK place or postcode. It adds little meaningful parameter meaning beyond that.

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 resource and scope: current conditions plus daily forecast, for either worldwide coordinates or a UK place/postcode. That is clear enough to distinguish it from every sibling tool, none of which return weather. It stops short of a 5 only because it does not state the geographic restriction asymmetry very explicitly (place is UK-only while coordinates are global).

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 implied by the nature of the tool ('weather') rather than stated. There is no guidance on which input form to choose, whether place and lat/long are alternatives or can be combined, or what happens with zero arguments (0 required parameters). An agent must infer the calling contract.

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