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

Discloses a lot beyond the annotations: the validation gate and resolution constraint, that the file is copied out and turned into a completed library project that plays and opens in the editor, that the call is free, and how to behave on timeout. The retry-with-same-inputs advice is slightly at odds with idempotentHint=false, but it is scoped to timeouts where no delivery occurred, so it reads as operational guidance rather than a contradiction.

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 core action and its precondition are front-loaded before the cadence and retry rules. It is dense with nested parentheticals (the workflow call and the resolution check), but every clause carries operational information and nothing is wasted.

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 non-idempotent mutation tool, the description covers the prerequisites, the validation gate, the side effects, the retry policy, and the cost, all of which an agent needs before calling. Since an output schema exists, the absence of return-value documentation is not a 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?

Schema coverage is 100%, so the schema already documents all eight parameters including videoPath, slug, and title. The description only echoes videoPath indirectly (the MP4 in the workspace, 1080x1920) and adds no format or source-of-value detail beyond the schema, so baseline 3 applies.

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: deliver one finished video from the faceless-production workflow and save it as a completed project in the VidGuy library. It is clearly separable from siblings like video_project_export, create_video, or publish_playable because it names the exact workflow step and end state.

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 clear prerequisites (MP4 must pass `vg deliver --check` at 1080x1920), timing (after the loudness pass), cadence (once per final video/episode), and a retry rule that also excludes re-rendering. No sibling alternatives are named, so it stops short of a 5.

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