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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=false, destructiveHint=false, so safety is covered. The description contributes only 'hour by hour from open sources' (data provenance/granularity); it says nothing about pagination, time-range expectations, rate limits, or what the response looks like for each of the three claimed modes.

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 sentence with no filler, which is the right size in principle. However, the front-loaded phrasing 'told hour by hour' is evocative rather than informative, and the post-colon list is compressed to the point of ambiguity rather than clarity.

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 read-only, open-world data tool with an untyped catch-all parameter and no output schema, the description carries the full burden of explaining invocation — and it does not. An agent cannot tell how to shape 'input' for list vs. single-event vs. sources, nor what it will receive back.

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?

There is exactly one parameter, named 'input', with a completely empty schema and 0% description coverage — its type, accepted fields, and shape are entirely undocumented. The description's phrase 'the list, one event, or its sources' implies the input is polymorphic, but gives no indication how to express each case, so an agent cannot construct a valid call from either the schema or the description.

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?

"Major disasters told hour by hour from open sources" identifies the resource (disaster events) and hints at temporal granularity, but the operative verb is missing — the tool apparently either lists events, fetches one event, or returns its sources, and the description never says which mode it selects or how. That ambiguity is worsened by siblings cell_data_disasters and cell_data_disasters_sources, whose overlap with this tool is not disambiguated.

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?

There is no statement of when to use this instead of cell_data_disasters or cell_data_disasters_sources, despite those siblings existing and this description claiming to cover 'the list, one event, or its sources' — i.e. the same territory. No preconditions, no exclusions, and no guidance on which input shape triggers which mode.

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