Create a subclip from a specific portion of a project item by defining in and out points in seconds, letting you isolate and reuse selected ranges of source media in Premiere Pro.
Create a subclip from part of a project item
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| nodeId | Yes | Project item nodeId (from get_project_items / find_project_items) | |
| inPoint | Yes | Seconds | |
| outPoint | Yes | Seconds | |
| hardBoundaries | No | Restrict trimming to the subclip range (default true) |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It says a subclip is created but does not disclose whether the original item is modified, whether the operation is reversible/undoable, what permissions or active project state are required, or where the new subclip appears. For a mutation tool, this is a significant gap.
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 short sentence with no filler. It is efficient and front-loaded, though the terseness comes at the cost of substance captured elsewhere.
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 5-parameter creation tool with no annotations and no output schema, the description is too thin. It does not explain prerequisites (e.g., an open project), the relationship between in/out points and hardBoundaries, or what the caller gets back, so an agent lacks enough context to invoke it confidently.
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 80%, so the schema already documents nodeId provenance (from get_project_items / find_project_items), inPoint/outPoint in seconds, and hardBoundaries. The description adds no parameter-level meaning beyond the vague phrase 'part of a project item', so the baseline 3 applies.
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 (Create) and resource (subclip) and names the source (part of a project item). It is clear what it does, but it does not distinguish itself from related siblings such as create_subsequence or duplicate_clip, leaving the agent to infer when this exact tool is appropriate.
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?
There is no explicit when-to-use guidance, no exclusions, and no mention of alternatives like create_subsequence or razor_clip. The name implies a scenario, but the description offers no routing information beyond the one-line purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.