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

Annotations already declare readOnlyHint=true, openWorldHint=false, and idempotentHint=true, establishing the operation is safe and deterministic. The description adds valuable non-annotation context: the data source and vintage ('Data is from FCC Form 477 (as of June 2021)') and the explicit purpose (digital divide analysis). It does not contradict annotations. No side effects or edge cases are discussed, but given the annotations, this is sufficient.

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 five sentences, each purposeful: the core function, its primary use case, supported geographies, data provenance, and a policy-specific recommendation. It is front-loaded with the most important information (what it returns) and contains no filler or redundant wording. Every sentence earns its place.

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?

Given the tool's complexity (6 params, 5 enums, output schema present), the description covers the essentials: what it does, what data it uses, when to use it, and which geography levels it supports. The output schema exists, so the return format need not be described. An agent can safely select and invoke this tool without further information.

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 input schema has 100% description coverage, with each parameter already explained in detail (e.g., speed_down enum meanings, tech filter codes, and geography ID formats). The description's parameter-related advice—'Use 100 Mbps as the speed threshold for BEAD program policy analysis'—duplicates the schema's own recommendation ('100 = BEAD program standard (use this for current policy analysis)'). It adds no meaning beyond the schema, so the baseline 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 opens with a precise action and resource: 'Returns a broadband coverage summary for a geography' and specifies exactly what the summary contains (population with zero/one/two/three-plus providers, urban/rural, tribal/non-tribal). It declares itself 'The primary tool for digital divide and equity analysis,' which clearly positions it relative to siblings. No other sibling performs this exact aggregation, so distinguishing is unambiguous.

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?

It gives strong contextual guidance: 'primary tool for digital divide and equity analysis' and recommends the 100 Mbps threshold for BEAD policy analysis. It also lists the supported geography levels. However, it never explicitly says when NOT to use this tool or names alternatives (e.g., fcc_compare_areas for head-to-head area comparisons). The absence of explicit exclusion points to a score of 4 rather than 5.

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