Extract a PNG frame from a video at a given time, then add it as an image clip for use as a cover or freeze frame in the timeline.
Extract a NEW PNG at a source time for inspection, covers or freeze frames. Add the output as an image clip to hold it for any desired timeline duration.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| time | Yes | ||
| dry_run | No | ||
| output_dir | Yes |
Changes observed during successful MCP inspections.
v0.3.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No contradiction with annotations: readOnlyHint=false matches the creation of a PNG and adding an image clip. The description adds useful context beyond annotations by specifying a NEW PNG is generated and that the output is placed on the timeline as an image clip with adjustable duration. It does not disclose output file location or naming.
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 efficient sentences with the primary action front-loaded in the first clause. Every phrase earns its place, and the follow-up sentence about the image clip adds genuine behavioral value without bloat.
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 creation tool with no output schema, the description covers the core behavior and the timeline side-effect, which is the most important agent-facing consequence. However, it omits the meaning of path, output_dir, and dry_run, and says nothing about what is returned, leaving meaningful gaps for correct invocation.
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 0% (no parameter descriptions in the schema), so the description must carry the load. It clarifies 'time' as a source time and implies the output is a PNG/image clip, but 'path' (source file identity), 'output_dir', and 'dry_run' are left semantically unexplained, leaving three of four parameters ambiguous.
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 states a specific verb and resource ('Extract a NEW PNG at a source time') and names concrete use cases (inspection, covers, freeze frames). It does not explicitly differentiate from any of the 21 sibling tools, though its purpose is unambiguous enough that an agent could distinguish it from inspect_media or process_media without opening schemas.
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 intended-use context ('for inspection, covers or freeze frames') that signals when an agent should reach for this tool. However, it names no alternatives and gives no exclusions or when-not-to-use guidance, leaving comparison against siblings to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.