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

Annotations already declare readOnlyHint=true, and the description adds valuable context: the composite nature of the score, the output fields, the optional history behavior (via the schema's days parameter description), and the update cadence ('Updates: on source cadence'). This goes beyond the annotations without contradicting them.

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 compact and packed with useful information. It front-loads the core purpose in the first sentence, then provides clear usage guidance, and ends with a short update cadence note. Every sentence adds value without redundancy.

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?

Despite the rich description, there is a critical gap: the tool claims to return a risk profile for a US county but the input schema contains no parameter for identifying the county (e.g., county_fips). The description mentions 'joined on county_fips' but does not explain how the county is selected, leaving the agent unable to invoke the tool correctly for its stated purpose. This is a major omission for an otherwise well-described tool.

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?

The only parameter (days) is fully described in the input schema with 100% coverage, including its purpose, valid range, and tier requirement. The tool description itself does not add additional parameter semantics, but the schema carries the full burden, so the baseline score of 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 clearly states a specific verb and resource: 'Returns a 0-100 place-risk profile for a US county' and enumerates the composite layers, output fields, and intended use cases. It distinguishes itself from sibling tools by positioning it as a composite risk package covering multiple hazard categories.

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?

Explicit when-to-use guidance is provided: 'Call when the user asks what can go wrong in a place or about hazard and environmental exposure for a county or market...' This gives clear context, but it does not mention when not to use the tool or name specific alternatives, so it falls just short of a 5.

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