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

With readOnlyHint already covering the safety profile, the description still adds substantial behavior: the four status values, the blocking semantics of wait_s (up to 80 seconds, then gewartet_s in the answer), and the meaning of rechte_klasse values including the nicht_festgehalten edge case. It also flags a non-obvious distinction from eigen/ki under the AI Act, which an agent could easily conflate.

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?

The lead sentence and polling guidance are correctly front-loaded, but a large share of the text is deep domain detail: clip-chain result fields (result.zusammenfassung, result.ketten, result.clips), Umzug import fields, and a multi-line rights-class taxonomy. Much of this is only relevant to specific job types, and none of it reads as wasted, but the density makes the core call pattern harder to extract.

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?

There is no output schema, so the description carries the return-value burden and does so for two concrete job types plus the generic job record with payload/result objects. It leaves the shape of a failed job's record and any error fields unstated, which is the one thing an agent polling on errors would still want.

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, and the description earns above that by supplying the status enum values that the schema omits (job_id has no enum) and by explaining the blocking/waiting behavior of wait_s. It does not add syntax or format detail for job_id beyond the schema's own text.

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?

Opens with a specific verb and resource: 'Get the status of a background job by job_id', plus the status vocabulary (queued|processing|done|failed). It does not distinguish itself from the close siblings lab_job_status, lab_batch_status, and lab_jobs_inflight, which is the main remaining gap for an agent selecting among job-lookup tools.

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?

'Poll this after starting a long-running generate/export' gives a clear triggering condition, and 'Pass wait_s (up to 80) to wait inside the call... instead of polling in quick succession' gives explicit alternative behavior. It stops short of naming when to prefer lab_job_status or lab_jobs_inflight, so a routing ambiguity against those siblings remains.

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