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

Annotations already cover read-only/idempotent/no-side-effects, yet the description adds substantial non-structured context: cost (Free), auth requirement (API key or OAuth), per-minute rate limits by tier (10/60/300), no pagination, a 10-minute cache refresh, jurisdiction-specific privacy withholding (CA, OR, VT, MT), and a named retryable error (parcels_unavailable). These are exactly the operational facts an agent needs before calling and retrying, and none contradict the readOnlyHint=true annotation.

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 long but front-loaded: purpose and routing come first, then output shape, then cost/behavior/limits, then errors. Some sentences are dense enumerations ('total_parcels and, per state, parcel and county counts, publisher, licence, data vintage, refresh cadence...'), but each carries information an agent would otherwise have to guess at, since there is no output schema.

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?

There is no output schema, so the description carries the full burden of describing return values — and it does, for both the list mode and the single-state mode, plus the negative case and the error contract. Auth, rate limits, caching and privacy caveats round out a complete picture for a one-parameter read tool.

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% and the single optional 'state' parameter is fully documented there, including case-insensitivity and the given-vs-omitted semantics. The description largely restates that contract rather than adding new meaning; its only marginal addition is the covered:false outcome for uncovered states, which is really return-value behavior.

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 specific verb and resource ('List the states with parcel data, or one state in detail') and immediately frames its role relative to siblings parcel_search and parcel_enrich. An agent can tell this is a coverage/capability-check tool, not a data-retrieval tool, without inspecting the schema.

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 an explicit decision rule: use it 'to see whether parcel_search and parcel_enrich can answer there', and names the two modes (omit state vs. supply state) with their respective outcomes. It also names the uncovered-state case ('an uncovered state returns covered: false'), so the agent knows how to interpret a negative result rather than assuming an error.

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