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

With readOnlyHint=true already declared, the description adds value by detailing the output structure (composite_score, component_scores, drivers, coverage), the data source (2 AlpineDataWorks V2 county layers joined on county_fips), and the update cadence ('on source cadence'). No contradiction with annotations exists, and the description goes beyond the annotation by clarifying the read-only nature through 'Returns'.

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 three concise sentences: purpose and outputs, use cases, and update cadence. Every sentence provides necessary information with no fluff or repetition. The structure is front-loaded with the primary action and result.

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?

The description claims the tool returns data 'for a county or address', but the input schema contains no parameter for specifying a location (only 'days'). An agent reading this description cannot determine how to target a specific county or address, which is a critical omission. The tool likely relies on external context (e.g., a pre-selected workspace), but without stating that, the description is incomplete for successful invocation. This is a significant gap given no output schema and only one optional parameter.

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 details about history series, default behavior, and Gold tier requirement. The description itself adds no parameter-specific information, but given the schema coverage is 100%, the baseline of 3 is appropriate. The description's mention of 'for a county or address' is not reflected in the parameter list, which is a gap, but this is more about contextual completeness than parameter semantics.

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 the tool returns a 0-100 county earthquake and seismic risk profile, with specific mention of composite and component scores, drivers, and coverage. The verb 'Returns' and resource description are specific and unambiguous. Although sibling tools are not explicitly differentiated, the unique subject matter (fault and ground-shaking hazard) makes its purpose clear.

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 provides explicit trigger conditions: 'Call when the user asks about local earthquake risk, fault proximity, or shake hazard for a county or address, or when timing site selection, property underwriting, or seismic-resilience spending.' This is strong guidance, though it does not mention when not to use the tool or name specific alternative tools for comparison.

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