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

Annotations already indicate readOnly, idempotent, and non-destructive behavior, so the bar for additional disclosure is lower. The description adds meaningful behavioral context: it geocodes an address, resolves the parcel, returns a specific bundle of attributes, and explicitly discloses source provenance ('Zoning, setbacks and building facts carry the city/county source they came from; geocode, lot geometry and assessor records do not'). It also mentions the 30-day cache behavior through the forceRefresh parameter, which is beyond the 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 three dense but well-organized sentences: the first scopes the tool, the second enumerates returned data and provenance nuances, and the third gives concrete use cases. No sentence is wasted; the structure front-loads the core identity and flows into details and usage guidance.

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 annotations cover safety semantics, the description supplies the remaining situational context: geographic scope, workflow positioning before other permit tools, cache/refresh behavior, and data provenance. Nothing an agent needs to decide whether to call this tool or invoke it correctly appears missing.

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 description coverage is 100%, with both address and forceRefresh already documented in the input schema. The tool description reiterates the county restriction and implies the address format through the example use case, but it does not add new semantic detail about the parameters themselves. Baseline 3 is appropriate because the schema fully covers parameter meaning.

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 uses a specific verb-resource pairing: 'Address-first parcel lookup' that geocodes an address, resolves the parcel from county GIS, and returns a detailed set of zoning/overlay/permit facts. It defines the geographic scope (King, Pierce, or Snohomish County, WA) and names the workflow position relative to check_permit_requirements and estimate_permit_fee, which helps distinguish it from sibling permit tools.

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 explicit use cases: 'Use for "what can be built at 123 Main St Seattle?" or before calling check_permit_requirements / estimate_permit_fee for a specific parcel.' This clearly states when to use the tool and its role in a permit workflow. It does not explicitly list exclusions or when-not-to-use scenarios, but the sibling references provide strong selection context.

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