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

No annotations are provided, so the description carries the full burden. It usefully discloses cost ('Free') and the side effect/refund behavior of `cancel: true`, but omits permissions, rate limits, whether the crawl keeps running, and error behavior — meaningful gaps for a job-status tool.

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 tight sentences, front-loaded with what is returned, then the cancellation option. No filler and no redundancy.

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 correctly enumerates the return payload and the cancel side effect, which is the key missing information. It falls short on auth/rate-limit context and the undocumented `jobId` parameter is left unexplained.

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 67%: `limit` and `cancel` are documented in the schema, while `jobId` is undocumented in both places. The description repeats the cancel/refund semantics already present in the schema rather than adding new meaning, so it does little beyond the structured fields.

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 and resource ('Checks a crawl') and enumerates the fields returned (status, pages read, discovered, queued, pages). It is distinguishable from the sibling web_crawl (which starts one) by implication, but it never names or contrasts the sibling to make the routing explicit.

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 intended context (polling an in-flight crawl) is implied, and it surfaces a real alternative mode via `cancel: true`. However there is no explicit guidance on when to call this versus web_batch_status or when to re-check, so the agent must infer the usage pattern.

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