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

Annotations (readOnlyHint, idempotent, non-destructive) already establish safety; the description then goes well beyond: it discloses sourcing guarantees ('grounded STRICTLY in USGS ASCE 7 + NOAA climate normals via ACIS'), the 'never estimated' missing-data policy, radius fallback semantics ('unavailable_exceeds_radius'), and geographic coverage limits. It even documents conditional nulls ('extreme_max_wet_bulb_f (null if source lacks it)'). No annotation contradiction.

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?

Zero fluff—every clause earns its place, and the first sentence front-loads the core trigger with strong scoping. The trade-off is density: a multi-line inline return-shape blob sits in the middle, which is hard to parse on sight and could plausibly live in the (available) output schema or be trimmed to key-name snippets. Despite that, the overall structure is tight for a description covering so many critical behaviors.

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 tool this complex (6 params, radius-based geography, multi-source data, geographic/COI/coverage constraints), this description covers the decision surface: when, what, where, data provenance, edge cases, and what the response contract looks like. With output schema plus this rich behavioral text, an agent has no unresolved ambiguity in picking or invoking it. The only minor gaps (e.g., explicit wording on non-US climate fallback, exact input validation rules) are minor against the 100% schema coverage and the detailed behavioral notes.

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% (aliases, defaults, and examples all documented), so the schema does the heavy lifting. The description adds meaning by example ('get_climate_intel lat=33.45 lon=-112.07') and by clarifying radius_km's runtime consequence (snap vs available/success vs exceeds-radius). However, it introduces minor friction by calling lat 'required' in prose and noting the 'available'/'unavailable' states in a way that slightly duplicates rather than extends schema info. Net mild value-add beyond the schema.

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?

Opens with a specific verb+resource ('seismic + climate intel for a lat/lon') tied to concrete business outcomes ('data-center structural bracing cost' and 'cooling design'). It distinguishes itself from siblings by naming get_disaster_risk and get_composite_site_score as the tools for adjacent needs. An agent facing 80+ siblings could unambiguously confirm this is the USGS/NOAA climate-seismic lookup and route elsewhere for ratings or blended scores.

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?

Gives explicit when-to-use ('Use when...'), when-not-to-use ('non-US → seismic unavailable', 'beyond it climate returns unavailable_exceeds_radius'), and names two alternative tools with their distinguishing conditions. The one-line preamble preceding the return shape ('the layer that drives...') also clarifies what problem prompts should mention. For the two closest siblings, routing is unambiguous.

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