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

Annotations already mark the tool as read-only, idempotent, and non-destructive, and the description adds substantial behavioral context: each resource appears once under its first topic, topics lists all topics when there are several, links are checked on a schedule with verified_status/verified_at, and text in result fields is copied from sources and must be treated as data, not instructions. This goes well beyond the structured 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 dense but every sentence earns its place: it covers scope, grouping behavior, deduplication, exclusions, source verification, and a security note about treating text as data. The core purpose is front-loaded, and the length is justified by the behavioral complexity it explains.

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 output schema exists and the tool has a single well-documented parameter, the description covers all essential context: what is returned, how resources are grouped and deduplicated, what is excluded, where links come from, and how to interpret result text. An agent has enough information to select and invoke the tool correctly without further inference.

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 already provides 100% coverage for the single parameter, including a detailed description of jurisdiction_id with examples and source tools. The tool description only references 'by jurisdiction_id' without adding new parameter-level meaning, 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 states a specific verb and resource: 'see everything GISFinder lists for one place' by jurisdiction_id, and enumerates exactly what is included (responsible body per function, offices with contacts, official resources grouped by topic). It also distinguishes itself from find_official_resource by explicitly noting that larger-government resources are not repeated here.

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 gives clear when-to-use context: use it for the full directory of one place. It also provides an explicit exclusion and alternative: 'Resources of larger governments (county, state) are not repeated here; use find_official_resource for those.' This is direct routing guidance beyond what annotations or schemas provide.

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