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

Annotations only cover the read-only/idempotent safety profile; the description adds the operationally critical context an agent cannot infer — status value vocabulary, expected completion windows, and how to interpret failure_side/error ('customer' means the project input is provably at fault and says what to change; 'platform' means escalate rather than edit the schema). That is exactly the extra behavioral depth the dimension asks for.

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-loads the purpose, then blocks of STATUS VALUES and failure handling — well ordered and free of filler. Some sentences are long compound constructions that could be split, but each clause carries distinct actionable information.

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?

No output schema exists, yet the description names the return-relevant fields (status values, failure_side, error, module_code, image/commit) often enough that an agent can act on a response without guessing. Combined with polling cadence and failure triage, nothing needed 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% for the single parameter, so baseline is 3; the description adds value by tying the id's origin to concrete operation types and by explaining what the corresponding job reports back (module_code, built image/commit). It stops short of format or reuse constraints on job_id.

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 ('Check the status of a job') and immediately enumerates which job kinds qualify (create, deploy, promotion, rollback, deletion, module). This separates it cleanly from the sibling list_project_jobs, which enumerates rather than polls a single job.

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 polling guidance: 'Call it until the status is completed or failed,' plus termination reasoning (every job ends; stalled server => failed in ~3 min; deploy up to 15 min). It never names list_project_jobs as the alternative for enumerating jobs, so the when-not side is only implied.

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