Batch update subtitle font size, color, and position by track or clip IDs in a new project revision. Specify a style and target clips to apply consistent formatting.
Batch update subtitle font_size/color/x/y by track or clip IDs, in a new revision.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| style | Yes | ||
| track | No | ||
| dry_run | No | ||
| clip_ids | No | ||
| new_name | Yes | ||
| include_plan | No |
Changes observed during successful MCP inspections.
v0.3.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are minimal (readOnly=false, destructive=false), and the description adds meaningful behavior: the operation is batched, scoped by track or clip IDs, and applied in a new revision, signaling a non-destructive update flow. It does not contradict the annotations, and the 'new revision' detail provides useful safety context.
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 sentence packs the core action, target scope, fields affected, and safety-related revision behavior. There is no filler or redundancy, and the most important information is front-loaded.
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?
The description covers the core styling and targeting details, but with 7 parameters, a nested style object, no output schema, and no parameter descriptions, important gaps remain such as what name/new_name mean, what include_plan does, and whether dry_run prevents actual changes. It is adequate but not fully 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?
With 0% schema description coverage, the description must compensate, and it partially does by naming style fields (font_size/color/x/y) and the targeting parameters (track, clip_ids). However, the required name and new_name parameters remain ambiguous, and dry_run/include_plan semantics are left entirely to inference.
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 specific verb ('Batch update'), a specific resource ('subtitle font_size/color/x/y'), and a targeting mechanism ('by track or clip IDs'). This clearly distinguishes it from generic siblings like batch_edit or edit_draft and makes its scope immediately apparent.
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 a clear usage context: batch restyling subtitles with either track-level or clip-level targeting. It does not explicitly name alternatives or exclusion criteria, so it stops short of 5, but an agent can confidently select this tool for subtitle styling work.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.