job_status

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

Annotations already declare readOnly, non-destructive, closed-world, so safety is covered. The description adds value beyond them by enumerating the returned facets (status, progress, message, structured error) and by disclosing the two-stage retrieval pattern with include_result. It does not mention retention/expiry of results or any polling cadence, which are the remaining behavioral unknowns.

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, no filler, and the primary capability is front-loaded ahead of the conditional flag instruction. Every clause carries information an agent needs.

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 names the returned fields, and it covers the one non-obvious parameter. Minor gaps remain: the set of possible status values is not enumerated, and behavior when include_result=true is sent before success is unspecified.

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%, so the description must carry the load, and it does for include_result: it explains the flag's purpose, its precondition (status is succeeded), and what it yields (the full report) — far more than the bare boolean in the schema. job_id is left undefined, though it is self-evident from the tool name.

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 background job's status, progress, message and structured error'), so the agent knows exactly what comes back. It never names a sibling, so the distinction from list_jobs or submit_job has to be inferred from the singular 'a background job' plus the required job_id.

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?

'Set include_result=true once status is succeeded to fetch the full report' gives an explicit conditional workflow: poll, then re-fetch with the flag. There is no guidance on when to use this tool versus list_jobs or cancel_job, so tool selection is left implicit.

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