pro_render_job

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

The description adds genuinely non-obvious behavior beyond the annotations: temporary poses/camera are restored, requested colors are left unsaved, and the job is two-phase (preview then final) and must be polled rather than resubmitted. That corroborates idempotentHint=false well. What it does not explain is the destructiveHint=true flag — nothing says what persistent state is at risk, and "restores"/"unsaved" actually reads as reassuring, leaving the agent unsure why the tool is marked destructive.

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?

It is short, but the telegraphic comma-fragment style ("diagnose, optional RGB, explicit explosion, framing, preview then final") is hard to parse and front-loads sequencing detail rather than what the tool does. Conciseness is achieved at the cost of comprehensibility, so the density does not pay for itself.

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?

This is a 12-parameter, destructive, asynchronous job-submission tool with no output schema and no parameter documentation; the description covers only workflow sequencing and state-restoration notes. Key facts an agent needs — what the operation returns, what request_id guarantees, what the preview/final phases produce, and what is destructively modified — are absent.

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?

With 12 parameters and 0% schema description coverage, the description must carry the load and largely does not. "Optional RGB" gestures at assignments, "explicit explosion" hints at the mode=exploded/transforms requirement, and "framing" loosely covers view/width/height, but request_id (required, clearly the non-resubmission key), passes, denoiser, quality, result_view, and document_path get no semantic treatment.

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?

The description outlines a pipeline ("diagnose, optional RGB, explicit explosion, framing, preview then final") which implies an asynchronous render/analysis job for a document, and "One job" plus "Poll operation_id" distinguishes it from direct-call siblings. However the purpose is never stated plainly in a verb+resource form; the agent must reconstruct that this submits a render job from telegraphic fragments.

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 operation_id; do not resubmit" gives an operational rule for the async lifecycle, which is useful invocation guidance. But there is no guidance on when to choose this tool over close siblings such as pro_visualize_render, pro_visualize_render_project, pro_shot_pack, or pro_capture_view, and no stated prerequisites.

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