cineflow_frames_generate

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

No annotations are supplied, so the description carries the full behavioral burden. It usefully discloses one real constraint — the reference policy requiring every <Subject N> to be addressed in the prompt — but says nothing about what happens on violation (hard error vs. silent rewrite), whether generation is synchronous or a long-running job, or whether calls incur cost. That leaves the mutation/generation risk profile largely undisclosed.

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 compact sentences with the core action front-loaded and the constraint second. No filler, though the terse style leaves gaps that a slightly longer treatment could have closed.

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 generation tool with no annotations and no output schema, the description should cover what comes back (frame IDs? paths? count?) and failure behavior for the policy check. It covers the action and one constraint but leaves the return contract entirely undocumented, which is a meaningful gap for an agent chaining into later steps.

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 50%: project_id and prompt are documented, while frame_specs, shot_index, and subjects are not. The description partially compensates by explaining the relationship between the declared subjects and the prompt text (every <Subject N> must be addressed), which is genuinely useful meaning beyond the schema. It still says nothing about shot_index semantics or ordering/uniqueness expectations.

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: 'Generate starting keyframes for shots', which is concrete enough to distinguish it from asset, script, and TTS siblings. It stops short of explicitly naming which sibling to use instead when the task is something other than first-frame generation.

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 phrase 'starting keyframes' hints at pipeline position, but there is no explicit when-to-use, when-not-to-use, or prerequisite guidance (e.g., whether a project must already be initialized, or whether this precedes or follows dependency script generation). An agent must infer placement in the workflow.

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