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

With no annotations, the description carries the full burden and does so: background/asynchronous execution, email notification at pause/finish, partial-result streaming, and the fact that results carry a `handle` usable with other tools. It enumerates every status value with its meaning, including the throttling case (waiting, resume_at, auto-resume) and the 'wait a day' case, plus guidance that `message` is safe to relay verbatim.

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?

Front-loaded with the core action, then structured into behavior, status enumeration, and an Args block, all of which earn their place. A few phrases are conversational filler ('do not make you wait', 'it says it in plain words'), and the status list is dense but necessary for polling logic.

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?

For a 2-param, no-annotation, no-output-schema tool, the description covers execution model, return shape (status, done count, results, handle, message) and status lifecycle. The remaining gap is pagination: it says limit is 'most results to return' but never says whether more results exist beyond the limit or how to fetch them.

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 0%, so the Args block is doing real work: job_id is explained as 'the job to read, omit to list the latest 10' — behavior the nullable schema does not convey — and limit is described as max results. The limit text largely restates the schema's min/max/default, and the interaction between limit and job_id (does limit apply to listing jobs or to results?) is not spelled out.

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 the verb and resource precisely ('check on a search that is running in the background, and read what it has found so far') and covers both modes: with job_id you read one job, without it you list the latest jobs. An agent can distinguish it from siblings like cancel_job or get_activity_log from the text alone.

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?

Explains the triggering context well: large searches return a job_id instead of blocking, and you can work on partial results while the rest runs. It also tells the agent when to omit job_id (list latest 10). It stops short of naming alternatives or explicit exclusions (e.g., use cancel_job to stop a job), so it is clear context rather than a full routing rule.

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