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

Annotations already establish readOnlyHint=true and openWorldHint=false, so the safety profile is covered; the description adds genuinely new behavior: partial progress reporting before completion, result delivery only on finish, and the two terminal states done/failed. It doesn't cover intermediate state names or whether repeated polls are rate-limited, keeping 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?

Two sentences, both front-loaded: what is returned first, then how to poll. Every clause carries information (return fields, timing, termination); nothing is redundant with the annotations or schema.

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 one parameter, no output schema, and read-only annotations, the description covers what an agent needs: where jobId comes from, what comes back over time, and when to stop polling. Remaining gaps are minor — the full set of non-terminal state values and error/failure payload semantics are unstated.

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 0% (jobId is typed as a bare string with no description), so the description must compensate — and it does, explaining that jobId is the identifier returned by the original long-running tool call. It still doesn't say whether jobId is opaque, session-scoped, or whether it expires, so not a full 5.

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 set (report status, progress, and result) against a specific resource (a tool call identified by jobId). The precondition 'a tool call that returned a jobId' uniquely identifies this as the async-polling tool, distinguishing it from the many analysis/setup siblings without needing a named alternative.

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 explicit invocation guidance — 'Poll every few seconds until status is done or failed' — including cadence and the stopping condition, plus the implied trigger (a prior call returned a jobId). It stops short of saying what to do on a failed status (retry vs. abandon) or what not to do, so it is clear context rather than full when/when-not routing.

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