Planning operations (intent, cutfiles, timelines, rescue, workflow, repurpose)

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

Annotations already flag destructiveHint=true, openWorldHint=true and idempotentHint=false, so the agent knows the surface is unsafe, but the description adds nothing about which operations are the destructive ones. For a dispatcher whose enum mixes inspection (video_rescue_inspect, video_seek_frame) with rendering, publishing and remote egress, that variance in side effects is the single most important thing to disclose, and it is absent.

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?

Two short sentences, no waste, with the dispatch contract front-loaded ahead of the discovery pointers. The phrasing "Required arguments: list_operations" is slightly compressed and reads as a dangling fragment, which is the only friction.

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 50-operation destructive, open-world dispatcher the definition is thin: it never signals the range of side effects, never says whether operations can be chained or require prior project state, and never mentions that failures differ per operation. The presence of an output schema excuses it from describing return values, but not from the behavioral gaps.

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 67%, and the description does add real meaning for `params`: it tells the agent that the payload shape is operation-specific and that describe_operation is where the contract lives. Beyond that pointer it contributes nothing about `overwrite` or any per-operation argument, so it neither compensates fully for the gap nor is redundant.

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?

"Run one planning operation by name" conveys the dispatcher pattern (operation name + params bag), but the word "planning" misdescribes a 50-value enum that includes video_cutfile_render, video_rescue_render, video_workflow_render, video_publish_validate and video_remote_egress_plan. An agent cannot tell from this text whether the tool covers read-only planning only or also rendering/publishing, nor how it differs from siblings video_edit_ops and video_qc_ops.

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 routes the agent to the right discovery path (list_operations for the argument contract, describe_operation for the full schema), which is genuinely useful for a 50-operation dispatcher. However, it gives no condition for choosing this tool over video_edit_ops, video_qc_ops, video_ai_ops or video_effects_ops, and no guidance on when an operation should be planned versus executed.

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