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

Annotations only cover readOnly and closed-world; the description adds substantial behavior beyond that. It discloses per-source result states (unavailable / outside-study / no-mapped-feature), that observation times and attributions are returned, that cleanup observations require documented commercial reuse permission, and a critical epistemic caveat that absence of a mapped feature does not establish safety or disclosure compliance.

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?

Five sentences, all load-bearing, with the resource inventory front-loaded. It is dense but not padded; the only mild inefficiency is stacking the permission note and the safety disclaimer as separate trailing sentences rather than grouping caveats.

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?

An output schema exists, so return shape needn't be spelled out, yet the description still usefully previews per-source status values, timestamps, and attributions. Combined with the coordinate requirement and the non-guarantee disclaimer, an agent has nearly everything needed; only the longitude semantics and any latency/availability expectations are unaddressed.

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?

With only 2 parameters and 50% schema coverage, the schema documents latitude's bounds and the 'no address match implied' caveat but leaves longitude bare. The description compensates somewhat by requiring a 'verified coordinate' and clarifying the result describes a point, but it adds no format or precision guidance beyond what the schema already says. Baseline 3 is appropriate.

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 opens with a specific verb ('Query') and enumerates the exact resource set: FEMA flood mapping, landslide coverage/inventory, liquefaction, mapped faults within 5 km, and an Ecology cleanup lookup link. That resource list is distinctive enough to separate it from wa_property_lookup or wa_local_context by content, though it never names a sibling or states the boundary explicitly.

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?

'Supply a verified coordinate; results describe a point, not an entire parcel or structure' implies the appropriate use case (point-level environmental screening) and warns against over-generalizing to a parcel. However, there is no explicit when-to-use vs. when-to-choose-a-sibling guidance, and no statement of what the tool is not for beyond the point/parcel caveat.

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