Runs arbitrary ExtendScript code in Premiere Pro to perform operations not covered by other tools and returns the JSON result.
Execute arbitrary ExtendScript code in Premiere Pro. Use for operations not covered by other tools. Returns the result as JSON.
| Name | Required | Description | Default |
|---|---|---|---|
| script | Yes | ExtendScript code to execute. Must return a JSON.stringify'd result. |
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, and it discloses very little. It does state returns are JSON, but it never warns that this runs arbitrary code with real side effects on a live project, whether it is sandboxed, whether failures are atomic, or whether changes are undoable. For a maximal-power 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?
Three short sentences, front-loaded with the purpose before the usage rule and the return note. No filler and no repetition, though the return sentence is slightly redundant given it is not the main concern here.
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?
This is an arbitrary-code-execution tool with no annotations and no output schema. The description does not cover error behavior, whether partial writes persist, what scope and permissions the script runs under, or how it relates to execute_qe_script. Too much an agent needs is missing for a tool of this power.
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%, and the schema already tells the caller the script must return a JSON.stringify'd result, so the description adds nothing about the single parameter. With the schema doing all the work, the baseline of 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?
The definition names a specific verb and resource: execute ExtendScript in Premiere Pro. It positions itself as the general fallback ('operations not covered by other tools'), which distinguishes it from the large sibling set at a category level. However, it never names the obvious sibling alternative, execute_qe_script, so the boundary is only implied.
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 'Use for operations not covered by other tools' gives an implied when-to-use, but there is no explicit when-not-to-use, no preference ordering, and no mention of execute_qe_script, which is a near-twin in the sibling list. An agent cannot tell from the description which of the two script executors is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.