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

With no annotations, the description carries the behavioral disclosure burden. It explains the preconditions and the post-call behavior (continues rendering and poll afterward), which is useful. However, it doesn't cover potential failure modes, side effects, or what happens if the run is not in awaiting_review, so it is only partially transparent.

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?

Three sentences, all useful: the purpose and condition, the input and effect, and the next action. No filler or repetition of schema details, and the core action is front-loaded.

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 a two-parameter resume action with no output schema, the description covers the essential flow: precondition status, input value, continuation of rendering, and how to check the result. It doesn't specify immediate return behavior or error cases, but the 'poll afterwards' guidance compensates for most of that gap.

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 schema already documents both parameters fully (id and srt_text) with meaningful descriptions, so the description adds little beyond what the schema provides. The phrase 'approved (optionally edited) SRT' adds some contextual nuance about the expected input, but the schema already says 'reviewed/edited SRT transcript.'

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 uses a specific verb ('Resume') and resource ('caption-video blueprint run'), and immediately distinguishes its purpose from starting a new run by noting it continues after pausing in awaiting_review. This clearly differentiates it from siblings like run_blueprint and run_blueprint_and_wait.

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?

The description gives clear usage context: resume only a run paused in awaiting_review, pass the approved SRT, and then poll with get_blueprint_run. It doesn't explicitly state when not to use this tool versus alternatives, but the status condition and follow-up instruction make the intended workflow clear.

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