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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so safety is covered; the description then adds substantial non-annotation context: a 100-call/day free allowance with $0.03 x402/USDC pricing and a 00:00 UTC reset, the fact that permits are geo/address-derived links rather than raw open-data PIN joins, and the critical caveat that assessment values are ~10% of market. These are exactly the behavioral traits an agent cannot infer from structured fields.

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?

Content is mostly substantive, but the opening two sentences lead with billing tiers before the tool's purpose appears, inverting the ideal front-loading. Emphatic capitalization ("LINKED", "ASSESSED") and restated value claims ("you cannot reproduce with raw open-data queries") add rhetorical weight without new operational information.

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?

With no output schema, the description carries return-value burden, and it handles that well by enumerating dossier sections and flagging the assessment_note divergence. Rich annotations cover the safety profile. Remaining gaps are minor: no error behavior for malformed or unmatched PINs and no statement about response size or latency.

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?

There is a single parameter with 100% schema description coverage — the schema already documents the 10- or 14-digit PIN format, dash allowance, and the address-fallback route. The description adds nothing about the pin argument, so the baseline 3 applies.

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 names a specific verb+resource ("Full Cook County / Chicago property dossier for a PIN") and enumerates the exact contents: parcel basics, recorded sales & deed history, permits, tax assessment history, and neighborhood context. It frames itself as a composite "one-call due-diligence record," which implicitly separates it from the narrower get_cook_county_parcel, though it never names a sibling explicitly.

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 only routing guidance ("If you only have a street address, call search_chicago_property_by_address first") lives in the input schema, not the description. The description instead spends its guidance budget on cost tiers, which is purchase context rather than when-to-use-this-vs-alternatives. Usage is therefore only implied.

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