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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds genuinely new behavior: the default timeout (30000), the maximum (120000), and that a timeout is not an error but a partial-report return. It doesn't say how long a call may block relative to the requested timeout or whether partial reports are marked, which keeps it below a 5.

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?

A single dense sentence, front-loaded with the action and bound, followed by the timeout consequence and the recovery path. No filler and no repetition of the title or annotations.

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 present, the description needn't explain the report contents, and it covers timeout semantics, bounds, and the fallback path. The only remaining gap is the relationship to get_crawl (the non-blocking alternative) for agents deciding between blocking and polling.

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 50%, and the description compensates well for the undocumented timeoutMs by supplying both the default (30000) and the upper bound (120000), which the schema does not state. It says nothing beyond the schema about the required id, but the schema's 'taskId from crawl' already handles that.

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?

States a specific verb (wait), the resource (a crawl), and the outcome (finish and return its report), which lets an agent distinguish it from the polling sibling get_crawl without opening either 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?

The description gives clear operational guidance for the timeout path ('wait again or read get_crawl_pages'), but it never explicitly contrasts with the non-blocking get_crawl sibling or states when blocking is preferred over polling. That leaves the main sibling choice implicit.

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