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

readOnlyHint already covers safety, and the description adds useful context about return fields, national percentile ranking, and update cadence. However, it claims the tool works for 'any of 3,222 US counties' yet the input schema has no county parameter, leaving the county selection mechanism unexplained. The 'Updates: on source cadence' line is also vague, but there is no contradiction with annotations.

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 tight and front-loaded: it opens with the primary return value, then lists output fields, usage triggers, and update cadence. Every sentence earns its place without unnecessary elaboration.

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 covers purpose, use cases, and return fields, which is substantial given the simple schema and read-only annotations. However, it fails to explain how the target county is selected when no county parameter exists, and it does not clarify default snapshot behavior versus the optional history series beyond what the schema already states. This ambiguity prevents full completeness.

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 schema provides 100% coverage for the single optional 'days' parameter, including its purpose and Gold tier requirement. The tool description does not add parameter-level detail, so the baseline score of 3 applies because the schema already carries the semantic weight.

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 business density score for US counties and lists the exact output fields. It distinguishes itself from the opaque sibling names by specifying the exact metric, scope, and return structure.

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 says when to call the tool: for local business activity, commercial density, market saturation, county comparisons, site selection, retail expansion, or market-entry decisions. It does not mention exclusions or alternatives, but the use cases are clear and actionable.

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