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

Adds substantial behavior beyond the annotations: billing is 1 token per NEW business with existing listings free plus a small per-page minimum, results are auto-enriched, relevance-checked, address-verified, and enrolled in monthly re-checks, and concurrency is limited to two searches. It also discloses the ambiguous-area failure mode and the polling handoff to get_job_status/get_search_results, which the destructive/openWorld annotations alone would not convey.

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?

Purpose and behavior lead, with operational details (cost, polling, disambiguation, concurrency) following in a dense but ordered block. Several sentences are long and pack multiple clauses, so it is efficient without being maximally tight.

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 correctly supplies the return contract (job_id, poll get_job_status with kind 'search', then read with get_search_results). Combined with the cost model, concurrency limit, and disambiguation behavior, an agent has everything needed to invoke and follow up correctly.

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 100%, so the baseline is 3, but the description adds real parameter meaning: the mode tradeoff (grid vs paging from a centre) is quantified with cost/exhaustiveness evidence, and the areas parameter's ambiguity handling (returns candidate ids, starts nothing, requires resend with an id) is documented nowhere else.

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?

Names a specific verb+resource (area search that sweeps a grid of map points live against Google Maps as a background job) and ties it to a concrete outcome (1,061 roofing contractors in Houston vs 255 from paging one centre). The scope and the contrast with centre-paging make it distinct from siblings like search_leads, preview_search, and estimate_area_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?

Gives clear usage context: it is 'the search to use for coverage,' runs as a background job requiring a poll loop, and is capped at two concurrent searches per account. It also tells the agent what to do on an ambiguous area name (ask the user and resend with the id). It never explicitly names when NOT to use it or which sibling (search_leads, preview_search, estimate_area_search) to prefer instead.

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