import_video

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

With no annotations at all, the description carries the full burden and does substantial work: it discloses the side effect of creating a new document, the frame cap (max 1000), fps resampling, and aspect-preserving width scaling. It stops short of stating what happens past the frame cap, whether an error is returned, or what the result looks like, which are meaningful gaps for a resource-heavy import.

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 tight sentences, front-loaded with the core action and formats, then the document-creation rule, then a compact parameter clause. No filler, and the most decision-relevant fact (new document vs into_current) lands early.

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 an 8-parameter tool with no annotations and no output schema, the description covers side effects, limits and most parameter meanings well enough to call it correctly. It leaves the return value and failure behavior unspecified, and the 'name' parameter ambiguous, which keeps it just short of complete.

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% with 8 parameters, so the description must compensate, and it does for most: start/duration units (seconds), fps resampling effect, width scaling with aspect preserved, into_current's document behavior, and max_frames (with a 1000 cap vs the 240 default). 'path' and 'name' are left unexplained — notably whether 'name' labels the document or the resulting layer.

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 ('Decode a video ... into an animated layer') plus the supported formats, and the phrase 'so every frame can be painted, filtered or adjusted' distinguishes it from import_frames, import_image and video_info without opening any schema.

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?

It clearly frames the use case (bring a workspace video in as an editable frame layer) and gives the key decision rule: 'Opens a new document sized to the video unless into_current'. It never explicitly names alternatives such as video_info for inspection or import_frames for image sequences, so the routing is implied rather than spelled out.

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