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

Annotations already declare read-only, idempotent, non-destructive behavior, so the safety profile is covered. The description adds genuine operational context beyond that: per-event-type default radius, a hard 25-event listing cap, and the fact that total/counts_by_type reflect all matches rather than the truncated list.

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-loaded with the core purpose in the first clause, then source list, then the two constraints that affect result interpretation. The source enumeration is slightly listy but each item earns its place by telling the agent which event_types are actually backed by data.

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 structure need not be explained, and the description still flags the 25-event cap and the total/counts_by_type semantics that an agent needs to interpret truncation. Only minor gap is the absence of guidance on place-vs-coordinates resolution and relation to sibling tools.

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 the baseline is 3. The description goes beyond the schema by explaining that radius_km has a sensible per-event-type default (the schema only states the 1-500 bound) and by naming the event categories that event_types accepts, which the schema already enumerates but the prose reinforces in context.

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?

Names the resource precisely ('disasters and hazards') with temporal and spatial scope ('happening now or recently near a place') and an ordering guarantee ('most severe and most recent first'). The enumeration of sources and event types makes it immediately distinguishable from weather-forecast and climate-profile siblings.

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 rather than stated: 'happening now or recently' hints at the recency window, but there is no explicit when-to-use, no mention of alternatives like get_forecast, and no guidance that find_place may be needed to resolve a place name. Context is inferable but not spelled out.

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