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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds genuinely new behavioral context beyond that: data is cached, it returns a frozen snapshot with station distance/dates/licences, forecasts are not observations, and no paid API/LLM call/publication occurs.

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?

Front-loads the core action and stays dense and earn-your-place, with only mild redundancy in the trailing negative list (no paid API, LLM call, publication). Multi-sentence but well organized for a tool with this much behavioral nuance.

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 an output schema present, return-value explanation is optional yet the description still notes the snapshot contents, and the annotations plus description together fully characterize a read-only cached fetch. The main remaining gap is the absence of explicit guidance against sibling farm_weather_search.

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 0%, so the description must carry the param burden, and it does add meaning: commune_code is a French INSEE code, and start_date/station_id retain an existing game's station/start when refreshing. It doesn't give format details (date syntax, station id format) for the optional fields, keeping it short of a 5.

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 (Read) and resource (cached MET Norway forecasts + Météo-France station archive) scoped to a French commune INSEE code, so the agent knows exactly what it fetches. It does not, however, differentiate itself from the sibling farm_weather_search, so an agent must guess which one to pick.

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 explains the refresh case for the optional start_date/station_id and notes that applying the result needs a separate closed weather_station command, which is useful context. But it never states when to use this tool versus farm_weather_search or other siblings, leaving the routing decision implicit.

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