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

Annotations already establish readOnly/idempotent/non-destructive, and the description adds genuinely new behavioral facts: expected latency (one to three minutes), incremental result availability, best-match-first ordering, and the existence of a "searching" state. It does not enumerate the other terminal states (e.g. completed/failed) or what an unknown id returns, which is the main remaining gap.

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?

Two sentences, front-loaded with what the agent gets back, then the timing/polling behavior. No filler. Minor cost: the opening is a noun fragment rather than a verb phrase, and the polling hint could tie more directly to `wait_seconds` instead of repeating separately.

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 an output schema covering return values and rich read-only annotations, the description needs only to explain timing, ordering, and polling — all of which it does. Missing only error/unknown-id behavior and the full set of states, which are modest gaps for a two-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%, so both `search_id` and `wait_seconds` (max 25, default 15) are already fully documented. The description reinforces where `search_id` comes from ("returned when the search was started") but says nothing about the long-poll semantics of `wait_seconds`, so this is baseline territory.

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 the resource and the key returned ("Progress of a customer search by its search id, and the leads it has found so far"), so an agent can tell this is a status/results poll rather than the search-start tool. It stops short of naming the sibling `search` explicitly, but the object and scope are unambiguous.

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 clear operational context: a search runs one to three minutes and "while the state is 'searching', checking again shows newer results", which tells the agent to poll this tool rather than call it once. It does not state when not to use it or name an alternative for retrieving leads after completion, so it falls short of explicit routing guidance.

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