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

Annotations already cover the safety profile (readOnly, idempotent, openWorld), and the description adds real behavioral context beyond them: unincorporated areas return county code with no city code, roughly half of municipalities publish no online code, and the response flags that gap. That discloses outcome variability an agent would otherwise misread as failure.

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 verb and the return contents are front-loaded in the first clause, and the second sentence carries a genuinely useful caveat rather than filler. Slightly dense in the parenthetical enumeration of code-source fields, but no wasted sentences.

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?

No output schema exists, yet the description fully enumerates the returned fields (name, publisher, official URL, current-through, whether we host text) and preempts the most likely misreading of a missing city code. Missing only edge behavior such as ambiguous-address handling or what happens with zero inputs (0 required parameters).

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 only 33% (lat/lon undocumented), so the description compensates partially by framing 'address or lat/lon' as alternative input modes. It does not clarify precedence when both are supplied, whether lat and lon must be paired, or the address format beyond 'one-line street address' in the schema.

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?

States a specific verb ('Resolve') and resource ('full jurisdiction stack: federal, state, county, place') and enumerates what each layer carries. A reader knows exactly what the tool produces, though it never names a sibling to distinguish itself from law_coverage or law_search.

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 input forms ('an address or lat/lon') imply the use case of turning a location into its governing codes, but there is no explicit when-to-use, when-not, or pointer to law_coverage/law_search as alternatives. Usage is inferable rather than stated.

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