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

Annotations only say this is a non-read-only, non-destructive, closed-world mutation. The description adds genuinely useful behavior the annotations cannot convey: matte computation happens asynchronously on first use per file, takes about a minute for a 15 s clip, the clip renders nothing until the matte is ready, progress is visible via 'mattes', and export blocks on it. It stops short of saying what the call itself returns or whether repeated calls on already-matted files are cheap.

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 effect is front-loaded in the first sentence, followed by the latency/progress caveat and the reversal note. Three sentences, no filler, though the parenthetical about 'mattes' and the 'Montik makes its subject matte in the background' phrasing are slightly dense. 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 4-parameter mutation with no output schema, the description covers the critical unknowns: asynchronous latency, blocked playback until ready, progress reporting, and reversibility. Remaining gaps are the response shape and the approval flow implied by approvalId, both of which an agent would still need to discover.

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 only 50% – 'on' and 'clipIds' carry no schema descriptions. The description rescues 'on' by explaining that false restores the background, and implies clipIds are video clips, but it never states the default value of 'on' or that multiple clipIds can be processed in one call. With half the parameters undocumented in the schema, this partial compensation lands at the baseline.

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 gives a specific verb and effect: cutting the (person) subject out of video clips so the background shows around them, and it names the inverse operation ('on=false puts the background back'). That is far more than a restatement of the name. It never references the closely related siblings like text_behind_subject or follow_subject, so an agent must infer the boundary itself.

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?

Usage is implied rather than stated: you call it on clips whose subject you want isolated, and 'on=false puts the background back' signals the undo path. There is no explicit when-to-use/when-not guidance and no mention of how it relates to text_behind_subject, which also depends on the subject matte. The approvalId note in the schema hints at a gated workflow the description never explains.

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