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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description is fully consistent with that read-only framing. Beyond the annotations it discloses the return contract (status/job on success, typed { code, error } on failure), the long-poll default of 0 with a 55s cap, that job ids are key-scoped, and that jobs expire 15 minutes after completion — all operationally important details an agent cannot get from structured fields.

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?

Four tight sentences, front-loaded with purpose, then return shape, then the wait parameter, then retention constraints. No filler, and the distinguishing detail (authorized job ids, expiry) comes before the agent would need it.

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 carries the return contract itself and does so precisely, including the failure shape. Together with the poll timing and retention window, nothing an agent needs to call this correctly is missing.

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 100%, so the baseline is 3, but the description adds real meaning: wait_ms is a long poll whose 0 default means immediate return, and a job id from another key will resolve as not found. Those are semantic consequences the schema's terse property text does not convey.

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 ("Read a slow job") and ties it to the two producing tools, publish_preview and upload_build, so the agent can immediately place it relative to siblings. No ambiguity about what it returns or what it operates on.

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?

Makes clear this is for polling a job previously started by publish_preview or upload_build, and tells the agent to supply wait_ms for long-polling rather than re-polling tightly. It does not spell out an explicit alternative (e.g. what to do instead of polling at all), which keeps it below a 5.

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