media_review_movie

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

Annotations declare readOnlyHint=false, destructiveHint=false and openWorldHint=false; the description corroborates localness ('free local') and adds genuine behavioral detail not in annotations: that MOV output preserves alpha while MP4 explicitly composites onto black, which materially affects output correctness. It still omits what gets written where and any failure/side-effect behavior for the pinned frames, but the alpha/compositing disclosure is real added value.

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?

A single front-loaded sentence with no filler; the codec consequence is stated compactly with a semicolon. It is dense with unidentified jargon ('pinned frames', 'receipt'), which trades clarity for brevity, but nothing is redundant.

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?

An output schema exists, so return values need not be explained, but for a 3-parameter tool with zero schema descriptions the definition leaves key call-blocking gaps: what a 'receipt' is or how to obtain one, what 'directory' refers to (source vs destination), and whether a file is written. Only the codec dimension is adequately covered.

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 description coverage is 0%, so the description must compensate for three undocumented parameters and does so only partially. The MOV/MP4 sentence implicitly maps to the codec enum (prores_alpha vs h264_black) but never names or maps the enum values explicitly, and 'receipt' and 'directory' — two of three parameters, both required — get no explanation whatsoever.

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 mechanism (local FFmpeg/ffprobe over pinned frames) and a concrete output distinction (MOV alpha vs MP4 black), which separates it from siblings like after_effects_render and adobe_export. However, it never plainly states that the tool produces/encodes a movie file from a receipt, and terms like 'pinned frames' and 'receipt' are left undefined, so the core purpose is only inferable.

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 guidance on when to choose this tool over after_effects_render or adobe_export, nor on prerequisites (does a render/receipt need to exist first?). The MOV-vs-MP4 note is really codec-choice guidance for a parameter, not when-to-use guidance, leaving the agent to infer selection criteria.

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