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

With no annotations, the description does carry real behavioral information: sequential ordering, fail-fast with stopOnError, and one result per op. It omits whether earlier successful ops are rolled back on failure, and whether partial results are returned when it stops, which are the key unknowns for a batch mutation tool.

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 core action, then the item shape, then the failure semantics. The '{operation, args}' sentence partially restates the schema but is justified given 0% schema description coverage.

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 two-parameter tool with no annotations and no output schema, the description covers ordering, failure behavior, and return cardinality ('one result per op'). It falls short only on atomicity and on identifying valid operation values, which are material gaps for a batch executor.

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 0%, so the description must compensate, and it does explain the shape of each op ({operation, args}) and what stopOnError controls. However, the critical ambiguity is left open: 'operation' is a bare string with no enum, and the description never says where valid operation names come from (presumably pr_catalog/pr_do).

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 and resource: runs several operations in order, i.e. a batch executor. It is clear what the tool does, but it never names or contrasts with the obvious sibling pr_do (single-operation execution), so the agent must infer the relationship.

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 statement of when to batch versus calling pr_do repeatedly, no prerequisites, and no exclusions. The error-stopping behavior hints at a use case but does not tell the agent when this tool is the right choice.

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

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

With no annotations, the description carries the behavioral burden and does well: it discloses the two distinct response shapes (categories with counts vs. full operation parameters) and the node_id addressing convention. It doesn't state read-only/safety explicitly, but 'List' plus the response description makes it unambiguous.

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?

Four short sentences, each carrying distinct information, with the core purpose and the mode-dependent output front-loaded. No filler.

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 single-optional-parameter discovery tool with no output schema or annotations, the description covers purpose, usage timing, both return shapes, and the node_id convention for follow-up calls. Only minor gaps (e.g., output format) remain.

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 enum of categories is fully documented in the schema itself, so the baseline is 3. The description adds real value by explaining what happens with and without the category argument, which is semantics the schema cannot express.

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 opens with a specific verb and resource ('List Premiere Pro operations available through pr_do') and clarifies the relationship to the sibling pr_do. It further distinguishes the two listing modes, so an agent can tell exactly what the call returns.

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?

It explicitly instructs the agent to call it before using an operation not yet used in the session, and names pr_do as the executor, giving clear when-to-use context. It stops short of stating when not to call it, but the guidance is actionable.

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

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

With no annotations, the description carries the full load and does most of it: it discloses that returns are operation-result JSON, that writes are verified by readback where Premiere allows, and that property/marker writes leave no undo step — a non-obvious mutation hazard. It does not cover error/failure shapes or any permission requirements per operation, so it falls just short of complete.

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?

Front-loaded with the core verb and a usage example, then layers exception handling (undo versus no-undo writes) in two tight sentences with no filler. The embedding of JSON literals inline makes it slightly dense to parse but every sentence earns its place.

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 2-parameter dispatcher with no output schema, the description supplies what matters: the return is operation result JSON, results may carry undoSteps/undoStackIndex, and reverting has a documented mechanism. The only missing piece is per-operation failure behavior, which is arguably delegated to pr_catalog.

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 baseline would be 3, but the description adds value beyond the schema by showing a worked payload ({'operation':'add_marker','args':{'time_seconds':1.5,'name':'Intro'}}) and making clear that args is an open, operation-specific bag governed by pr_catalog. The {expected_undo_stack_index} reference also explains a parameter-like argument the schema never enumerates.

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 and resource — 'Run one Premiere Pro operation by name (see pr_catalog)' — and includes a concrete inline example of the operation/args payload. The word 'one' implicitly separates it from the batch sibling pr_batch, and the closing line 'Prefer this over writing ExtendScript' names the alternative path an agent might otherwise take.

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?

Explicitly routes the agent to pr_catalog for operation discovery, and gives a concrete when/when-not rule: use the undo operation with {expected_undo_stack_index} to revert, but for property and marker writes checkpoint the sequence beforehand because they record no undo step. That is a real precondition, not a generic 'use this to...' statement.

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

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

With no annotations, the description must carry the full behavioral burden; it does disclose the precondition (an *active* sequence must be open), the mechanism (QE still export) and that output is full resolution rather than downscaled. It says nothing about overwrite behavior if the PNG exists, execution cost/latency, or failure modes, and filesystem side effects are only implied. Useful context, but not complete for an unannotated write-to-disk tool.

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 clauses, front-loaded with the verb and destination, followed by the default behavior and the invocation rationale. Every sentence carries information; nothing is padding.

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?

There is no output schema, so the description is the only place an agent could learn what comes back — yet it never says whether the tool returns image content, a path, or just a success signal. For an agent whose stated goal is to "LOOK at the result," that ambiguity matters. Otherwise adequate for a 2-parameter 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 description coverage is 100%, so the baseline is 3. The description restates the playhead default for `time_seconds` and ties `output_path` to the PNG destination, but adds no syntax, unit, or constraint detail beyond the schema (e.g. whether `time_seconds` must be within sequence bounds).

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 (export), a precisely scoped resource (one frame of the active sequence), the output format (PNG), the destination (`output_path`), and the underlying mechanism (QE still export at full resolution). No sibling in the list does frame export, so it is trivially distinguishable from pr_catalog, pr_do, pr_batch, pr_verify, etc.

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?

"Use it to LOOK at the result of an edit" gives a clear motivating context for invoking it, which is more than most tools offer. It stops short of explicit exclusions or naming an alternative (e.g. a preview/thumbnail sibling or pr_verify), so it lacks the when-not half of the 5 bar.

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

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

No annotations exist, so the description carries the full burden. It helpfully enumerates the returned fields (node_id, name, start/end/in/out, enabled, speed), which compensates for the missing output schema. However, it says nothing about the failure mode when no sequence is active, whether the read is scoped to the active sequence only versus the whole project, or the cost/size of the response on large timelines.

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?

Two sentences, front-loaded with what is returned, then the one downstream fact an agent needs. No filler and no redundancy.

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?

With no output schema and no annotations, the description must describe returns and it largely does by listing the clip fields. The remaining gap is the no-active-sequence case and whether the payload is large enough to warrant batching, but for a parameterless getter this is close to sufficient.

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?

Zero parameters, so baseline is 4. The description still adds useful semantics by explaining that node_id in the response is the key consumed by all clip operations, orienting the agent to the contract of the empty-argument call.

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 the specific resource returned: the structure of the active sequence, enumerated as video/audio tracks containing clips with named fields. An agent can tell this is a read of the current timeline state, not a catalog or a mutation. It does not explicitly contrast with sibling tools like pr_catalog, but the resource is unambiguous.

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?

'node_id is what every clip operation takes' effectively tells the agent this must be called first to obtain node_ids before any clip-level operation, which is clear usage context. It stops short of naming an explicit alternative or stating when not to call it (e.g. when no sequence is open).

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

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

With no annotations provided, the description carries the full burden and does so well. It discloses that status is read-only by default, that install copies files into the user's CEP extensions folder and enables unsigned extensions via PlayerDebugMode, and that user consent is required before install. It also states the required restart and follow-up verification step.

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 definition is a single dense but well-structured paragraph. It front-loads the purpose, then explains actions, then gives the operational sequence. Every sentence adds necessary information without repetition.

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 one-parameter tool with no output schema and no annotations, the description covers the action semantics, the user-consent requirement, the filesystem side effect, the required Premiere restart, and the follow-up call to pr_verify. Nothing an agent needs to invoke it safely is missing.

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 0%, so the description must explain the sole parameter, and it does: action=status is the default read-only check, while action=install performs the copy and PlayerDebugMode change. Both enum values are given concrete meaning beyond the bare enum names.

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 the specific resource (the Premiere-side CEP extension MCPBridgeCEP) and the specific operations (status and install). It clearly distinguishes this tool from pr_verify by explaining that this is the installer/status checker while pr_verify confirms the connector answers.

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?

It explicitly states when to use the tool: 'Use when pr_verify reports that the connector does not answer.' It also gives a clear before/after workflow ('ask the user first', then quit and reopen Premiere, then call pr_verify), leaving little ambiguity about ordering or alternatives.

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

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

No annotations exist, so the description carries the full burden. It discloses the mutation nature (a save/Cmd+S write to disk) and an implicit precondition that a project must be open, plus timing advice; however it never states what happens if no project is open, whether the save is confirmed, or what the call returns.

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?

Two short sentences, zero filler: the action first, then the timing constraint. Every clause earns its place.

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 zero-parameter, low-complexity tool with no output schema, the description covers what it does and when to invoke it, which is nearly all an agent needs. Only failure-mode behavior (no open project, save confirmation) is left unaddressed.

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?

The tool takes zero parameters, which is the baseline-4 case. The description correctly implies a no-argument, whole-project action rather than any parameterized save.

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+resource ('Save the open project') and anchors it to the familiar Cmd+S action, so the agent knows exactly what happens. It doesn't explicitly name sibling tools, but 'project' vs. 'frame export' vs. 'batch' semantics make the scope reasonably distinguishable from the surrounding tools.

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?

Gives explicit when-to-use conditions: before exports and before batches of destructive edits, which map onto the pr_export_frame and pr_batch siblings. No when-not or exclusion guidance is offered, so it stops short of full routing guidance.

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

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

No annotations are provided, so the description carries the full burden. It discloses the mode behavior (router vs. single reference) and enumerates topics, but says nothing about output format, size, caching, or what happens with an invalid `doc` value. For a read-only reference tool the risk is low, but the disclosure is only partial.

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?

Two tight sentences, each front-loaded with the mode it describes, with no filler. The parenthetical list of AI tools is long but functional since it signals coverage. Slight density cost, but nothing reads as wasteful.

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 one-optional-parameter reference lookup with no output schema, the description covers what the tool returns and when to call it. The main residual gap is that the mapping from `doc` values to actual content is not spelled out, so an agent picking 'combos' or 'masking' is guessing from the schema alone.

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 lists the valid `doc` values. The description adds real meaning beyond that by explaining what the absence of `doc` yields (the router) and by characterizing the content of the reference set (AI tools, multi-tool recipes, gotchas). It does not map individual enum values like 'combos' or 'timeline-automation' to topics, leaving that 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 clearly states this is a skill/reference retrieval tool with two modes: no `doc` returns the router (workflow order, capability limits, which reference to read), and `doc` returns a single topical reference. The verb is implicit ('read it') rather than explicit ('retrieve'), but an agent can still tell what it gets. It does not distinguish itself from siblings like pr_catalog or pr_do, which also sound like lookup tools.

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?

Strong usage trigger: 'read it at the start of any Premiere task beyond a single read or edit' gives a concrete when-to-use condition and an implicit exclusion. It also explains the two branches (router vs. one reference). It stops short of naming sibling alternatives for cases not covered here.

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

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

With no annotations, the description carries the behavioral burden and does well: it declares the check read-only and discloses the important condition that the connector does not answer while Premiere is open. It also notes consent requirements for installation, though it does not describe timeout or return-status behavior.

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 description is front-loaded with the core purpose, then immediately gives the usage rule and failure routing. The arrow notation is compact and every clause contributes useful information.

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, but there is no output schema and the description does not explain what a successful verification returns or what failure criteria look like beyond the connector not answering. It is adequate for invocation but leaves output interpretation underspecified.

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?

The tool has zero parameters, so parameter semantics are not a major concern. The description appropriately does not introduce parameter details where none exist.

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 states a specific read-only verification of the MCP-to-Premiere connector chain, including the open project and active sequence. It also distinguishes the failure path by naming pr_install_connector, making the tool's role clear against siblings.

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?

It explicitly says to call this first in a session and prescribes the alternative path when the connector does not answer: use pr_install_connector for status, then install with user consent. That is clear when-to-use and when-to-escalate guidance.

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