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

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds substantial behavioral context beyond that: the FEMA leg is keyless, the Census leg 'needs a Census key and degrades gracefully,' the parcel leg is limited to Maryland statewide / Texas-Harris County, 'a source that fails is noted, not fatal,' and the output is explicitly an 'INFORMATIONAL public-record synthesis, NOT an insurance rating, a property flood-risk score, or a professional risk assessment.' These key requirements, coverage limitations, failure handling, and scope disclaimers give the agent a realistic model of how the tool behaves.

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?

The description is a single dense paragraph of roughly 170 words covering purpose, sibling distinction, three data sources, key requirements, coverage limits, failure behavior, output format, and a disclaimer — every clause carries information, so nothing is wasted. The purpose is front-loaded in the first sentence. However, the heavy use of parentheticals and one long joined sentence makes it harder to parse than a structured presentation (e.g., separating the data-leg bullets) would be, so it earns a 4 rather than a 5.

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 no output schema present, the description carries the full burden of explaining return values, and it does: a readable profile with a headline exposure band (LOW/MODERATE/HIGH), incident types, frequency, most-recent event, and the federal-assistance program signal. It also discloses per-leg requirements and graceful degradation. The only gap is the absence of explicit differentiation from the sibling tools disaster_declarations and disaster_history_summary — the 'one-call profile' framing implies a distinction but never states when to choose this tool over those.

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 schema already documents all four parameters with examples and notes, establishing a baseline of 3. The description adds cross-parameter meaning beyond the schema: that the tool is keyed by NAME + state together, that state is 'Strongly recommended - required for an accurate county read' (reinforcing the schema nuance), and how the address parameter activates the parcel leg. It also explains the FIPS-code linkage between the FEMA and Census legs, which clarifies the relationship between the area/state inputs and the optional population 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?

The description opens with a specific verb+resource: 'One-call disaster-history and recovery read for a US area (county or place), keyed by NAME + state.' It names the data sources (OpenFEMA declarations, optional Census ACS, optional parcel record) and the concrete output (readable profile with LOW/MODERATE/HIGH exposure banding). It explicitly distinguishes itself from the most confusable sibling, location_risk_report, by contrasting keying (name+state vs address/lat-lon) and scope (area history vs single-site score).

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?

The description explicitly names the alternative tool location_risk_report and the condition that selects it ('scores a single site by address/lat-lon'), which resolves the highest-risk sibling confusion. It also states when the optional legs activate ('when an address is given' for the parcel leg). However, it does not address other nearby disaster siblings such as disaster_declarations or disaster_history_summary, leaving the agent to infer when the profile read is preferable to those raw-query tools.

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