Define in and out points on a Premiere Pro project item to isolate the exact source clip range for editing.
Set in and out points on a project item (source clip)
| Name | Required | Description | Default |
|---|---|---|---|
| nodeId | Yes | The nodeId of the project item | |
| inPoint | Yes | In point in seconds | |
| outPoint | Yes | Out point in seconds |
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 disclosure burden, and it does little: it doesn't say whether existing in/out values are overwritten, whether inPoint must precede outPoint, whether the duration must fit within the source media, or whether an open project is required. For a mutating tool with zero annotation coverage that is a meaningful 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 front-loaded clause with the resource and target stated immediately and no filler. Nothing to remove.
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 tool is simple (3 required scalars, no nested objects, no output schema), so the otherwise terse description is close to sufficient. It is still thin for an unannotated mutation in a large sibling family where the target object is the whole point of the tool.
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 100%, so nodeId, inPoint and outPoint (seconds) are already fully documented. The description adds only the object identity ('project item / source clip'), which helps map nodeId to the right entity but adds nothing on ordering or value constraints. Baseline 3 is appropriate.
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?
Specific verb (set) plus resource (in and out points) plus the target object (project item), with the parenthetical '(source clip)' doing real disambiguation work against the many timeline-level siblings. It stops short of naming which sibling to prefer, but an agent can tell this is the source/project-item variant rather than set_clip_in_out or set_sequence_in_out.
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 implies the scope via '(source clip)' but never states when to use this versus clear_project_item_in_out, set_source_in_out, set_clip_in_out, or set_sequence_in_out — a crowded, easy-to-confuse family. There are no preconditions (project open, item selected) and no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.