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

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds nothing beyond that: no latency/freshness characteristics for a live-event feed, no coverage limits, no return shape, and no statement about why idempotentHint is false for a read. It reads as a restatement of the resource rather than added behavioral context.

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?

It is a single compact sentence with no waste, which is good, but the brevity comes at the cost of disambiguation and it front-loads nothing actionable. The three-item list reads like a template of return types rather than a decision aid.

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 geospatial live-data tool with one undocumented required parameter, no output schema and two overlapping siblings in the catalog, the description leaves the agent unable to determine mode selection, time-window meaning, or result format. It is too thin for the ambiguity this tool sits in.

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% and there is a single required parameter, 'days', whose meaning is never explained — presumably a look-back window, but the description does not state units semantics (rolling window vs calendar days), acceptable range, or defaults. With a low-coverage schema the description was obligated to compensate and does not mention the parameter at all.

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 the data domain (wildfires, burn perimeter, satellite hotspots), so an agent can tell it is a wildfire-data tool. But it is a bare noun phrase with no verb, and it does not say whether it returns all three at once or requires a mode, nor how it differs from the siblings cell_sensor_wildfire_hotspots and cell_sensor_wildfire_perimeter, whose names map almost exactly onto two of the three listed items.

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?

No when-to-use guidance is given, and critically there is no direction about when to pick this tool versus cell_sensor_wildfire_hotspots or cell_sensor_wildfire_perimeter, which appear to be the narrow versions of the same data. The phrase 'near a point' and 'in a box' hint at spatial modes, but no instruction tells the agent how to select a mode or whether this tool supersedes the specialized siblings.

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