postfader_render_get_job

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

Annotations already provide readOnlyHint, idempotentHint, and destructiveHint=false, and the description does not contradict them. The 'completed also requires FL exit' phrase adds a behavioral nuance beyond those annotations, but it is ambiguous and does not clarify side effects or conditions. No annotation contradiction is present.

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 description is short two-clause sentence with no filler or repetition of the annotation data. The front-loaded 'Get render progress and decoded WAV evidence' is efficient, even though the trailing 'completed also requires FL exit' is syntactically opaque.

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?

For an inspect-by-id tool with one fully documented parameter and an available output schema, the description is mostly sufficient. However, it does not explain the saved-project render context, when to treat 'completed' as the terminal state, or what the 'FL exit' requirement means, so agents may still need to infer workflow timings from sibling tool names.

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?

The parameter schema already fully documents job_id, its type, pattern, and source ('Render job ID from this MCP process'). With 100% schema coverage, the description adds no additional meaning about how to obtain or format the job_id, which matches the baseline for high schema coverage.

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 names a concrete action and resource: 'Get render progress and decoded WAV evidence.' It clearly identifies this as an inspection/polling tool rather than a render-starting or render-canceling tool, which distinguishes it from named siblings like postfader_render_saved_project and postfader_render_cancel.

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?

There is no explicit statement about when to use this tool versus alternatives, nor any mention of polling cadence or the render-creation flow. The phrase 'completed also requires 2 exits' offers a thin timing clue, but fails to say whether to call this after postfadel_render_saved_project, before postfader_render_cancel, or how it relates to postfader_get_run.

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