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

With no annotations, the description carries the full behavioral burden. It usefully discloses a side effect (enabling time-varying/keyframing on the property) and that readback is verified, which is meaningful beyond the schema. However, it omits idempotency, failure behavior, permission requirements, and what happens if keyframing was already enabled, leaving notable gaps for a 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?

A single front-loaded sentence that packs the enable step, the add step, and the verification step with no filler. It is slightly crammed into one compound sentence, but 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 14-parameter mutation tool with no output schema and no annotations, the description covers the core action and notes the readback verification. It still lacks guidance on which of the many identification params (clip_name vs clip_index vs clip_node_id; property_name vs property_index) to prefer and on prerequisites, so it is adequate but not 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?

Schema description coverage is 100%, so the schema already documents all 14 parameters, including the value normalization behavior and time_reference enum. The description only restates time_seconds and value generically and adds no syntax or format detail beyond the schema, so 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?

The description states a specific verb+resource: enable keyframing on a clip property and add a keyframe at a time with a value. It clearly distinguishes itself from get_property_keyframes, update_property_keyframe, and remove_property_keyframe via the 'add' verb. It does not explicitly name siblings or contrast with set_supported_clip_property, so it stops short of 5.

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?

Usage is only implied: 'supported clip property' hints that the property must support keyframing, but it never tells the agent to consult list_supported_keyframe_properties first or to use get_property_keyframes to inspect existing keys before adding. No explicit when/when-not or alternative routing is provided, so it is minimum-viable at best.

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 burden. It usefully discloses non-deterministic behavior ('Attempt to cancel' and possible fallback to reporting API limitations), which is a genuine behavioral trait. But it says nothing about irreversibility, permissions, or what the response contains when cancellation succeeds versus fails.

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 sentence that leads with the action and immediately qualifies the failure mode. No filler, though the phrasing is slightly dense.

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, the description should explain outcomes, and it only partially does: it says it may 'report limitations' but not the shape of a successful cancellation result or error. Purpose and the key caveat are covered, leaving a gap on return semantics.

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% with a single well-documented parameter (job_id: 'Export job ID to cancel.'), so the schema does the heavy lifting. The description adds no format or sourcing details (e.g., where to obtain job_id from get_export_status).

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 (cancel) and resource (export job), and explains the 'when_supported' hedge: for in-progress renders it may only report Premiere Pro 2019 API limitations. An agent can distinguish this from list/get export siblings. However, it does not explicitly name the alternative tools (get_export_status, get_export_capabilities) it sits alongside.

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 real context: it applies to a *queued* export job, and for in-progress renders it may be unavailable, in which case the tool surfaces an explicit API limitation. This is meaningful when-to-use/when-it-won't-work guidance, though it stops short of naming alternative tools or a fallback workflow.

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 behavioral disclosure, and it does note the 2019-version and 'verified preset' constraints. It omits what happens on unsupported presets, whether the new sequence becomes active, name-collision behavior, and permissions requirements.

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?

One front-loaded sentence that leads with the action and resource, with no filler preamble. It is slightly padded by re-listing seven aliases already present in the schema, which could be trimmed.

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, no-output-schema tool with no annotations, the description covers the essential action, host context, and input modality. It is adequate, though side effects such as whether the created sequence becomes active are unstated.

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 both the preset and sequence_name parameters are already documented in the schema. The description only repeats the alias list and the file-vs-alias duality that the schema already states, adding no new syntax or default-behavior detail.

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) plus resource (a new sequence) inside a named host context (open Premiere Pro 2019 project), and pins the creation mechanism to a .sqpreset file or alias. This clearly separates it from read-oriented siblings like list_sequences and get_sequence_settings.

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 implicitly frames usage by requiring a verified 2019 .sqpreset or alias, which tells the agent the supported input path. It never states when to prefer this over any alternative workflow, nor what happens if the preset is unsupported, so guidance is implied rather than explicit.

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 disclosure burden and does well on the critical safety facts: it is a write/export operation, it demands an explicit confirm_export=true, and it flags the destructive overwrite case via confirm_overwrite=true. It stops short of describing the asynchronous nature of ame_queue mode, permissions needed, or what is returned.

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 that front-load the core action and then the authorization constraints. No filler, though it could have used the second sentence to carry more differentiated behavioral detail instead of only confirmation gates.

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 7-parameter mutation tool with no annotations and no output schema, the confirmation gates and preset mechanism are covered, but the asynchronous ame_queue behavior, the effect of start_ame_batch, and the result of the call are left to inference. Adequate but with visible gaps.

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 every parameter including work_area, export_mode, preset_path, start_ame_batch, and the confirm flags is already documented in the schema. The description only restates the two confirmation flags, adding no syntax or format detail beyond the schema, 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 (Export) and resource (the active sequence) with a version qualifier (Premiere Pro 2019) and hints at the preset/format mechanism. It does not explicitly differentiate itself from the export-related siblings (get_export_capabilities, validate_export_settings, get_export_status, cancel_export_when_supported), so an agent must infer the boundary.

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?

Usage is only implied through the confirmation requirements ('requires explicit confirm_export=true'), which describe how to authorize the call rather than when to choose it over siblings or which export_mode to pick. There is no guidance on when to route through validate_export_settings first or when ame_queue is preferable to direct.

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 behavioral burden. It makes the read-only nature evident ('Get detailed information') and discloses the returned fields, but says nothing about prerequisites (host app running, sequence open), what happens when no sequence is active, or any permission/rate constraints.

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 sentence with the resource and scope stated first, followed by the return contents. The long comma-separated field list is dense but each item adds information; no filler or 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 does the work of enumerating the return payload, which is the main thing an agent needs for a zero-parameter read. The remaining gap is error/precondition behavior when no sequence is active.

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, so the baseline of 4 applies. The description correctly describes only outputs rather than inventing parameter semantics, though its field enumeration is really return-value content that belongs in an output schema.

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 ('Get detailed information about the currently active sequence') and enumerates exactly what is returned: ID, name, duration, CTI position, In/Out points, track counts, and per-track clip counts. The 'currently active sequence' scoping cleanly separates it from siblings like list_sequences, get_sequence_settings, and get_project_info.

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 'currently active sequence' implies the precondition that a sequence must be open and active in Premiere Pro 2019, which is useful contextual guidance. However, there is no explicit when-to-use/when-not statement and no alternative sibling (e.g., get_sequence_settings for configuration, list_sequences for enumeration) is named, so routing is left to inference.

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 does disclose the read-oriented behavior indirectly and lists the fields returned (times, in/out points, duration, speed, linked items, source item, effect components), which is genuine behavioral content. However it omits what happens when a clip is not found, how ambiguous clip_name matches are resolved, and any permission/context requirements.

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?

One front-loaded sentence that names the resource first and then lists return fields. It is efficient with no filler, though the long enumerated field list is slightly dense.

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 usefully compensates by enumerating what the call returns. With 0 required parameters and identification precedence already handled by the schema, the definition is close to complete, missing only failure/ambiguity behavior.

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 all five identification parameters (clip_name, clip_index, track_type, track_index, clip_node_id) are already documented in the schema, including nodeId being preferred. The description adds no parameter-level detail beyond what the schema provides, making the baseline 3 correct.

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 ('Get') and resource ('detailed information about a specific timeline clip in the active sequence'), then enumerates the returned fields. This distinguishes it from a generic getter, but it never contrasts itself with close siblings like read_clip_properties, list_clip_components, or get_selected_timeline_clips, so the agent must guess which read tool applies.

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?

No when-to-use / when-not-to-use guidance and no mention of alternatives. The only implicit context is 'in the active sequence', leaving the agent to infer how it differs from read_clip_properties or get_selected_timeline_clips.

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 behavioral burden. It does convey that this is a non-mutating inspection ('Inspect... and list') and scopes the result to 'verified system' presets, but it omits return shape, whether the host app must be running, and any failure/version caveats beyond the '2019' qualifier.

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 sentence with no filler; the verb and resource come first and the parenthetical enumeration is tightly scoped to defining what 'export methods' means.

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 parameterless, annotation-free discovery tool with no output schema, the description adequately conveys both what is inspected and the categories returned. It stops short of describing the response structure, which an agent may need in order to consume the result.

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, so the baseline is 4. Nothing in the description is needed to disambiguate inputs, and it correctly frames the call as argument-free.

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?

Names a specific verb (Inspect) and resource (export capabilities), then enumerates the exact surfaces covered: exportAsMediaDirect, app.encoder queue, FCP XML, project export, plus verified .epr presets. This distinguishes it cleanly from validate_export_settings and export_active_sequence, which act on a configured export rather than discovering what is possible.

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 phrasing implies a discovery step that precedes export/validation, and the sibling set suggests validate_export_settings and export_active_sequence are the downstream tools. However, it never explicitly states when to call this versus those, nor any prerequisites such as Premiere being connected.

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 disclosure burden. It implies a read-only probe but says nothing about permission requirements, whether the disk check requires a local filesystem path, behavior for expired/unknown job IDs, or whether polling is rate-limited.

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 sentence with no filler; the verb comes first and the two capabilities (job status, disk inspection) are grouped economically.

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 should carry more of the load. It identifies the sources (Premiere Pro / Adobe Media Encoder) and the two modes of operation, but never describes the returned status vocabulary or progress/error reporting, which is the primary reason an agent would call it.

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 both parameters are already well documented, and the baseline is 3. The description adds only light framing by implying job_id maps to status and output_path maps to the on-disk check.

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 gives a specific verb+resource: it checks export job status and verifies an output file on disk. It is distinguishable in practice from export_active_sequence (which initiates) and cancel_export_when_supported, though it never names those siblings explicitly.

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?

Usage is implied rather than stated: the job_id parameter description ties it to 'export_active_sequence', suggesting a poll-after-start workflow, and the word 'recent' hints it works without args. However there is no explicit when-to-use vs when-not, and no guidance on choosing between the two optional parameters.

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. 'Inspect' implies read-only and the description scopes it to the 'currently open' project, which is useful. But it says nothing about error conditions (e.g., no open project), permissions, or response shape beyond the field names.

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 sentence with no wasted words. The comma-separated field list is dense but appropriate for communicating scope.

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, the description compensates by enumerating the exact data returned (name, path, document ID, proxy state, sequence count, active sequence summary, root bin counts). An agent knows what to expect, though no annotation coverage means failure modes remain unstated.

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, so per the baseline rule a 4 applies. The description adds no parameter concepts, which is correct since there are none to document.

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 ('Inspect') plus resource ('currently open Adobe Premiere Pro 2019 project'), followed by an explicit enumeration of returned fields. This clearly differentiates it from sibling listing tools like list_sequences and list_project_items, which enumerate items rather than summarizing the project.

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?

Usage is implied: 'currently open project' and the summary-style field list signal a top-level overview call. However, there is no explicit when-to-use guidance and no mention of the alternative summary tools (premiere_health_check, get_active_sequence) an agent might confuse this with.

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 does disclose the return shape (clip-relative, timeline, and source seconds/ticks plus values), which is genuine behavioral context, but it never states read-only semantics, error behavior when no keyframes exist, or any prerequisites.

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, front-loaded with the action and resource, with the return detail appended efficiently. No padding or redundant restatement of the tool name.

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, the description helpfully covers what is returned, but for a 9-parameter tool with 0 required parameters and three parallel ways to identify the target (clip_name/index, track_type/index, clip_node_id, plus property_name/index and component_name/index), the description gives no help on which identifiers are needed or how they compose.

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 every parameter is already documented, giving a baseline of 3. The description adds only the domain framing ('specified component property of a timeline clip') and no extra meaning about how the name/index/nodeId parameters interact.

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 (inspect) and precise resource (all keyframes on a specified component property of a timeline clip). This clearly separates it from the write siblings add_property_keyframe, update_property_keyframe, and remove_property_keyframe, and from the enumeration helper list_supported_keyframe_properties.

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 read-oriented purpose implies when the tool is used, but there is no explicit when/when-not, no prerequisite stating that keyframes must already exist, and no pointer to alternatives such as list_supported_keyframe_properties for discovering keyframable properties.

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 behavioral burden. It usefully discloses that the result reflects the user's live selection and is scoped to the 2019 Project panel, but says nothing about empty-selection behavior, blocking/failure modes, or whether the snapshot is stable.

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, tightly worded sentence with the resource and scope front-loaded. Nothing is wasted and no explanation is buried.

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 parameterless read tool with no output schema, the description tells the agent what selection is returned and from which panel. The only modest gap is the absence of return-shape or empty-result expectations, which is minor given the tool's simplicity.

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, so per the rubric the baseline is 4. There is nothing for the description to document beyond confirming it acts on the current selection, which it does.

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 (get) and resource (project items currently selected by the user), and scopes it to the Premiere Pro 2019 Project panel. This implicitly differentiates it from get_selected_timeline_clips, but it never names that sibling explicitly, so a reader must infer the distinction.

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?

Usage is only implied by the phrase 'currently selected by the user' — an agent can infer this is for reading the active selection. There is no explicit when-to-use, when-not-to-use, or naming of the alternative (get_selected_timeline_clips) for other selection sources.

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 behavioral burden. It usefully discloses two behavioral facts an agent needs: the result depends on live selection state and on an active sequence, and it spans both video and audio tracks. It does not say what is returned when nothing is selected, whether an error is raised, or that the operation is non-mutating.

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?

One sentence, zero waste, with the scope constraint front-loaded before the track-type qualifier. Nothing to trim and nothing essential buried.

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 read tool with no output schema, the definition is nearly sufficient: it tells the agent what set is returned and from where. The only real gap is the empty-selection outcome, which matters because the tool's whole premise is a conditional UI state.

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, so the baseline is 4. The description does add meaningful scope semantics for the implicit selection input ('currently selected', 'active sequence', 'across video and audio tracks') rather than being silent about context.

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 ('Get') and resource ('timeline clips (TrackItems)') and scopes it precisely to 'currently selected in the active sequence across video and audio tracks.' That scope implicitly separates it from the project-item sibling, but no sibling is named explicitly, so it stops short of a 5.

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?

Usage is only implied by the phrase 'currently selected' – an agent can infer this is the tool for reading the current timeline selection, but there is no explicit when-to-use guidance, no exclusion, and no pointer to the alternative (get_selected_project_items) for selection outside the timeline.

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 behavioral burden. 'Retrieve' implies a read-only, side-effect-free operation and the description discloses the payload contents, but it says nothing explicit about read-only safety, behavior when the named sequence does not exist, or precedence when both sequence_id and sequence_name are supplied.

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 sentence with the action first and the target-selection rule parenthetically embedded. Every clause (the field list) conveys real information about the return payload; 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?

With no output schema, the description usefully enumerates the returned settings fields, which is what an agent needs to know this getter answers 'what are the sequence's technical specs'. It stops short of covering error behavior or id-vs-name precedence, which is the only meaningful gap for such a simple read.

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% and both parameters already document that they default to the active sequence. The description echoes that same default behavior and the name/ID option without adding syntax or conflict-resolution detail, so 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?

Specific verb (Retrieve) plus resource (sequence settings) with an explicit enumeration of what is returned: frame size, frame rate, pixel aspect ratio, field type, audio sample rate, display formats. That field list clearly separates it from siblings like get_active_sequence, get_project_info, and list_sequences.

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 notes that the target defaults to the active sequence and can be overridden by name/ID, which is useful selection context, but it never says when to prefer this over get_active_sequence or list_sequences, nor any preconditions. Usage is implied rather than stated.

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. 'Inspect' correctly implies a read-only operation, and it usefully enumerates what is returned (track names, mute/lock/target states, clips), but it says nothing about prerequisites such as requiring an open sequence or what happens when none is active.

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 sentence covering purpose and returned data with no filler. The trailing enumeration of returned fields is dense but informative rather than redundant.

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 annotations and no output schema, the description does real work by listing the fields returned, which is what an agent needs to interpret results. The remaining gap is the unstated prerequisite that an active sequence must exist.

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 both parameters are already fully documented, establishing a baseline of 3. The description's mention of 'video and/or audio tracks' loosely echoes track_type but adds no syntax or default behavior beyond the schema.

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 (inspect) and resource (video/audio tracks in the active sequence) with the fields it surfaces. It is clearly distinguishable from clip-oriented siblings like get_clip_information, though it never explicitly contrasts itself with them.

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?

No when-to-use, when-not, or alternative guidance is given. The scope phrase 'in the active sequence' implies context, but nothing tells the agent when to reach for this tool versus get_active_sequence or get_clip_information.

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 burden, and it does disclose one meaningful trait: it verifies the imported items appear in the project. However, it omits permission requirements, duplicate/overwrite handling, failure behavior, and the fact that it mutates project state.

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 sentence naming the action, the input, the destination, and the verification step with no filler. 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?

No output schema or annotations exist, so the description should do more for a state-mutating 4-parameter tool. The verification clause helps, but permissions, error conditions, and duplicate handling are absent, leaving meaningful gaps.

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 four parameters are already well documented, establishing a baseline of 3. The description's mention of 'video, audio, or image files' loosely connects to import_as_numbered_stills but adds no syntax or format detail beyond the schema.

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 ('Import') and resource ('local video, audio, or image files') with the target ('Premiere Pro 2019 project'). It is the only import tool among the siblings, and its function is immediately distinguishable from readers like list_project_items or search_project_media.

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 no when-to-use guidance, no prerequisites (e.g. an open project/running Premiere instance), and no contrast with alternatives such as search_project_media or place_media_on_timeline. An agent must infer the correct invocation context entirely.

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, so the description carries full burden. It usefully enumerates what kinds of components are returned (intrinsic vs applied effects), adding content context. However it says nothing about whether it is read-only, requires a loaded sequence/clip, or what happens when no clip matches the optional filters.

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 sentence that defines the resource immediately. Efficient and free of padding, though the parenthetical slightly crowds the core statement.

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 should ideally convey the return shape, which it only partly does by naming component categories. With five all-optional selector parameters and no annotations, important context (how to target a clip, read-only nature) is left unstated.

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 all five parameters are already documented. The description adds no meaning beyond the schema — notably it does not explain that all five parameters are optional and how they combine to select a clip.

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 clear verb (List) and resource (components on a timeline clip) and even parenthetically defines what a component is (intrinsic effects like Opacity, Motion, Volume, plus applied effects). This distinguishes it from siblings like get_clip_information, though it does not explicitly differentiate from list_component_properties or list_component_properties.

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?

No when-to-use context, no prerequisites, and no alternatives named. With siblings like get_clip_information, read_clip_properties, and list_component_properties, an agent gets no signal on which to pick for what need.

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 behavioral burden. It does disclose the returned content (current values and keyframe state), which is useful, but it says nothing about read-only safety, ordering, error behavior when a component is not found, or how the 7 optional parameters interact for identification.

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 sentence with a clarifying parenthetical and the valuable return-scope clause; 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 7-parameter tool with no annotations and no output schema, the description does describe the returned shape, but it never explains the identification model implied by zero required parameters (which combination of clip and component identifiers is needed). That gap matters for correct invocation.

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 schema already explains all seven parameters (clip_name, clip_index, track_type, track_index, clip_node_id, component_name, component_index). The description adds only the notion that component identification is required, not the alternative ways to identify the clip/component. 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?

The description gives a specific verb (list) and resource (parameters/properties of a component/effect on a timeline clip), and clarifies the return content (current values and keyframe state). It does not, however, distinguish itself from nearby siblings like list_clip_components, read_clip_properties, or list_supported_keyframe_properties.

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 when-to-use guidance, no preconditions (e.g., 'call list_clip_components first to obtain component_name/index'), and no named alternatives such as read_clip_properties or get_property_keyframes. Usage can only be inferred from the phrase 'a specific component (effect) on a timeline clip'.

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. 'List' clearly implies a read-only, non-mutating operation and the recursive traversal scope is disclosed, but nothing is said about pagination behavior relative to the limit, permissions, or result shape on empty/missing bins.

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, front-loaded with the resource and followed by the two salient capabilities. No filler or 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, the description could reasonably convey the shape of returned items or ordering, and it also omits any sibling disambiguation in a crowded project/timeline tool set. It is adequate for a simple read-only list call but leaves these gaps.

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 all four parameters (limit, bin_path, item_type, recursive) are already documented with defaults and an example path. The description only restates recursion and type filtering, adding no syntax or format detail beyond the schema — the expected baseline of 3.

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 (List) and resource scope (media, bins, and sequences in the Premiere Pro Project panel), and mentions recursive traversal and type filtering. It does not, however, explicitly distinguish itself from close siblings like list_sequences, search_project_media, or get_selected_project_items.

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?

Usage is implied by the resource being listed (project panel contents), and the recursive/filter options hint at traversal scenarios. There is no explicit when-to-use guidance or routing to alternatives such as list_sequences for sequences only or search_project_media for name-based lookup.

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 burden, and it discloses the concrete payload (names, sequence IDs, active status, durations, track counts, clip counts), which tells the agent this is a non-mutating enumeration. It does not state pagination, ordering, or behavior on an empty project, so it is solid but not exhaustive.

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 sentence with no filler; the scoping phrase ('all sequences in the current ... project') comes before the field list, so the most decision-relevant information leads.

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 parameterless read-only listing tool with no output schema, the description supplies exactly what the schema cannot: the identity and shape of the returned records. Absent only minor operational details such as ordering or empty-project behavior.

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, so there is nothing for the description to disambiguate; baseline 4 applies. The one sentence spent on output fields is arguably output semantics rather than parameter semantics.

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 (List) and resource (sequences) with explicit scope ('all sequences in the current Premiere Pro 2019 project') and enumerates the returned fields. The word 'all' plus the field list distinguishes it from the sibling get_active_sequence, which returns a single one.

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?

Usage is implied rather than stated: an agent can infer this is for enumerating every sequence rather than the active one, and it naturally contrasts with get_active_sequence. There is, however, no explicit when-to-use/when-not guidance or named alternative.

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 behavioral burden, but it only notes the Premiere Pro 2019 platform. It does not state whether the operation is read-only, what returns look like, or what prerequisites (open project/sequence) are required.

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 a single front-loaded sentence with no filler. Every word contributes to identifying what the tool lists.

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 tool with five optional identifier parameters, no required parameters, no annotations, and no output schema, the description does little beyond stating the purpose. It omits usage guidance, return expectations, and identifier-selection semantics, leaving the agent under-equipped to invoke it confidently among siblings.

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 five parameters are already documented in the schema, and the description adds only the framing 'on a timeline clip.' It does not clarify how clip identifiers relate to each other or which combination is required, leaving an important semantic gap despite high coverage.

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 verb ('List'), resource ('component properties on a timeline clip'), and scope ('that support time-varying keyframes in Premiere Pro 2019'). This differentiates it from broader sibling tools like list_component_properties, though it does not explicitly name an alternative.

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 no when-to-use guidance, no prerequisites, and no comparison to related tools such as list_component_properties, read_clip_properties, or get_property_keyframes. Usage is only implied by the keyframe-supporting filter.

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 behavioral burden. It does disclose that the tool mutates the timeline and then verifies the updated clip boundaries, which is real information beyond structured fields, but it says nothing about how the move interacts with neighboring clips (ripple vs overwrite), permissions, or undo 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?

A single front-loaded sentence that leads with the action and the resource, with no filler. The trailing 'verify the updated clip boundaries' clause is slightly vague about what verification means, keeping it out of the 5 range.

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?

Seven parameters with zero required, no output schema, and no annotations mean the description should explain how a clip is identified and that either new_start_time_seconds or delta_seconds drives the move. It does none of that, leaving the agent to guess which identifier combination is valid and what happens when neither time parameter is supplied.

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 that the new start time is in seconds, which the schema already says, and it never mentions the delta_seconds alternative path or the clip identification parameters (clip_name, clip_index, clip_node_id, track_type, track_index), which are the confusing part of this parameter set.

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 (Move), resource (timeline clip), and the axis of change (new start time in seconds on its track), which cleanly separates it from trim_clip, split_clip_at_time, and remove_clip. It stops short of explicitly naming or contrasting those siblings, so an agent must infer the boundary from the verb alone.

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?

Usage is implied by the operation itself (repositioning an existing clip rather than trimming or splitting it), but there is no explicit when-to-use guidance, no mention of prerequisites such as selecting or obtaining a valid clip identifier, and no named 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?

With no annotations, the description carries the full burden. It usefully discloses that insert ripples subsequent clips and that the tool verifies the resulting timeline clip (a post-condition), but it never states that overwrite destroys/replaces existing clips on the target track, nor mentions any permission or failure 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?

Two tight sentences, front-loaded with the action and its target, followed by mode semantics and the verification guarantee. 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 an 8-parameter mutation tool with no annotations and no output schema, the description covers the action, placement coordinates, mode semantics, and verification. It falls short only on prerequisites (active sequence, prior import) and the destructive nature of overwrite.

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 already 100%, so baseline is 3, but the description adds real semantic value by explaining that insert 'ripples subsequent clips', which the schema's bare enum listing does not convey. It also clarifies that start time is in seconds.

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 (place) and resource (imported project media item onto the active sequence timeline), plus the key locating parameters (start time, track index). It implicitly distinguishes itself from the sibling import_media by specifying the item must already be imported, though it never names an alternative explicitly.

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 'imported project media item' implies import_media is a prerequisite and 'active sequence' implies a sequence must be open, but neither is stated as a condition. The insert/overwrite distinction is described but without guidance on when to prefer one over the other.

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 behavioral burden. It usefully scopes what is inspected (six distinct components) and implies a non-destructive read, but says nothing about latency or blocking behaviour, whether the live ping causes side effects in Premiere, or what a failure response looks like.

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 sentence with no filler or repetition; the component list is informative rather than padding. It could be marginally tightened, but every clause contributes scope 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?

There is no output schema and no annotations, so the description should ideally say what the check returns (per-component pass/fail status? a single boolean?) and how to act on failures. It also omits any routing relative to premiere_ping. For a diagnostic tool that is otherwise self-explanatory, this is adequate but incomplete.

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?

There is a single optional parameter with 100% schema description coverage, so the schema already documents verify_live_ping fully, including its default. The description's mention of 'live ExtendScript connectivity' loosely echoes the parameter but adds no new syntax or conditional detail. 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?

The description uses a specific verb ('Run a comprehensive health check') and then enumerates exactly what is inspected: MCP server, HTTP bridge, Premiere installation, CEP extension, process status, and ExtendScript connectivity. That is far more precise than a generic 'check health'. It does not, however, distinguish itself from the sibling premiere_ping, which an agent will also see in the tool list.

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 call this versus premiere_ping, which is the obvious alternative for a liveness check. No preconditions, no 'use this before attempting other operations' framing, and no exclusions. The agent must infer usage entirely from the tool name.

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 and no output schema, the description carries the full burden, and it does disclose the transport path (CEP bridge/ExtendScript host) and the returned payload (version, build, project state, latency). It omits failure modes, timeouts, and what happens when Premiere is not running, which matter for a connectivity probe.

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, both earning their place: the first covers what it does and over what transport, the second enumerates the return payload. Nothing is redundant or padded.

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 diagnostic tool with no output schema, the description supplies the return-value summary an agent would otherwise lack. Only failure/timeout behavior is missing, a minor gap for this tool's complexity.

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, so there is nothing to document and the baseline is 4. The description correctly implies the tool is argument-free by describing a pure round-trip probe.

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 (send a live round-trip ping) and resource (Adobe Premiere Pro 2019 via the local CEP bridge/ExtendScript host), so the agent knows exactly what it does. However, it offers no differentiation from the sibling premiere_health_check, which sounds functionally adjacent.

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?

No when-to-use guidance is given. The description never says to call this to verify connectivity before other operations, nor does it explain how it relates to or differs from premiere_health_check. The agent must infer the use case from the word 'ping' alone.

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 does disclose the scope of what is returned (Motion, Opacity, Blend, effects), which is useful. But it says nothing about how a clip is targeted when all five parameters are optional, nor about failure behavior if no clip is specified.

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 well-formed sentence, front-loaded with the action and resource, with the returned property groups listed compactly. No wasted text.

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 five parameters and zero required, the description does not explain the clip-selection strategy (e.g. node id vs name+index, or what happens when nothing is supplied), and there is no output schema to absorb return-value detail. Adequate but leaves real gaps for a tool with this many optional selectors.

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 schema already documents clip_name, clip_index, track_type, track_index, and clip_node_id. The description adds no parameter-level meaning beyond that, which is the expected baseline when the schema does the heavy lifting.

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 clear verb (Read) and resource (clip components and their parameter values) and enumerates the specific property groups returned (Motion, Opacity, Blend Mode, effects). However, it offers no differentiation from close siblings list_clip_components and list_component_properties, which sound like they cover overlapping ground.

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 guidance on when to use this tool versus list_clip_components, list_component_properties, or get_clip_information, all of which appear adjacent in purpose. No prerequisites or exclusions are stated.

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 burden, and it does disclose the single most important behavior: the operation is a destructive edit gated behind a confirmation flag. It says nothing about reversibility/undo, and the backup_project safeguard is only surfaced in the schema, so the coverage is adequate rather than rich.

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, and the destructive/confirmation constraint is front-loaded immediately after the action statement. Nothing could be cut without losing 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?

For a nine-parameter mutation tool with no annotations and no output schema, the description covers the safety gate but omits how a clip is targeted (node id vs name vs track/index coordinates), the ripple/backup side effects, and any failure or undo behavior. The schema fills those gaps, so the definition is workable but thin.

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 all nine parameters, including ripple, backup_project and the clip-identification options, are already documented in structured form. The description only restates the semantics of confirm_removal, which the schema also explains, so it adds little beyond the baseline.

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 gives a specific verb+resource ('Remove a clip') scoped to 'the active sequence timeline,' which naturally separates it from move_clip, trim_clip, split_clip_at_time and set_clip_enabled. It stops short of explicitly naming a sibling or contrasting with the disable-instead-of-delete alternative, so it lands just below the top mark.

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 states the precondition for invoking the tool (confirm_removal=true is mandatory because the edit is destructive), which is genuinely useful. However, it never says when to prefer removal over alternatives such as set_clip_enabled, nor when ripple-delete is appropriate versus a plain delete that leaves a gap.

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 behavioral burden. It usefully discloses the destructive nature (removing keyframes) and an unusual post-condition — that it 'verify[s] that the keyframe count decreased'. However, it omits whether removal is reversible/undoable, what happens when no keyframe exists at the target time, and how tolerance_seconds affects matching.

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 sentence with no filler; the mode clarification is parenthetical and efficient. It could be tighter still, but nothing is wasted.

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 13-parameter, destructive, annotation-free tool with no output schema, the description is adequate but thin. It never explains how the clip/track/component/property selectors combine, how tolerance works, or the failure mode when the keyframe count does not decrease.

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 85%, so the schema already documents nearly all 13 parameters. The description reinforces the single-time vs range behavior but adds no syntax or format detail beyond the schema, and says nothing about tolerance_seconds or the clip/track targeting params.

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 gives a specific verb and resource ('Remove a keyframe ... from a clip component property') and clarifies the two operating modes (single time point or a time range). It is readily distinguishable from siblings like add_property_keyframe, update_property_keyframe, and get_property_keyframes, though it never names them explicitly.

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 states what can be removed but never says when to choose this tool over update_property_keyframe (e.g., setting a value to null) or how removal interacts with surrounding keyframes. No prerequisites, no exclusions, no alternatives are offered.

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 burden and does well: it discloses that a backup is created before in-place saving and that overwriting the original requires an explicit confirmation flag, signaling the destructive path. It does not mention failure modes, return values, or prerequisites such as a currently open project, leaving some behavioral gaps.

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 sentences, zero filler, front-loaded with the core action and then the mode-specific requirements in priority order.

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 3-parameter, no-output-schema tool with no annotations, the description covers the operation modes and the safety gate adequately. Minor omissions remain around error behavior and whether the project must already be open.

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 3 is the baseline, but the description adds the inter-parameter relationship the schema only states per-field: confirm_overwrite is required specifically when saving in-place without save_as_path. That is meaningful semantics beyond the individual field docs.

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 ('save the current Premiere Pro 2019 project') and immediately enumerates the three distinct modes of operation. No sibling tool in the list performs saving, so the agent can place it unambiguously.

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 states the conditions that select each mode: save_as_path for saving a copy, create_backup for a timestamped backup, confirm_overwrite=true for in-place overwrite. There is no explicit when-not-to-use guidance, but for an isolated save operation the routing conditions are clear.

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 behavioral burden, yet it only restates what the search does. It says nothing about the return shape, pagination, whether results are flat or nested by bin, or any auth/rate constraints, which is thin for a search tool with zero annotation coverage.

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 sentence with no filler or redundancy. It is efficiently sized, though the version-pinning to '2019' adds a detail of questionable value for tool selection.

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 fully convey behavior plus return expectations. It covers scope and match criteria but omits what a match actually returns, which matters for a search tool whose whole purpose is producing a result set.

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 both parameters are already fully documented in the schema, including the enum values and the case-insensitive substring semantics. The description's 'by name or file path' restates the query parameter rather than adding new meaning, 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 (search), the resources it covers (media items, bins, sequences), the scope (inside the open Premiere Pro 2019 project), and the match fields (name or file path). It is clear but never differentiates itself from the sibling list_project_items, which covers overlapping ground.

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 'inside the open Premiere Pro 2019 project' implies the project must be open, but there is no explicit when-to-use guidance and no routing against alternatives such as list_project_items or get_selected_project_items. The agent is left to infer the situation.

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 behavioral burden. It usefully discloses that the tool verifies the updated state and that disabling equates to muting, but it omits permission/auth requirements, error behavior when a clip cannot be resolved, and what the verification 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?

A single front-loaded sentence that names the action, scope, and side effect with no filler. 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 mutation tool with six parameters, only one required, no annotations, and no output schema, the description covers the action but not clip-targeting resolution or the shape of the verification result. It is adequate but leaves the agent to infer how to address a specific clip.

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 all six parameters are already documented, and the description only adds the '(mute)' gloss on enabled. It does not explain how the five optional clip identifiers (clip_name, clip_index, clip_node_id, track_type, track_index) combine or which are needed to target a clip, so it adds little beyond the schema.

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 pair (enable/disable) on a specific resource (timeline clip) scoped to the active sequence, and adds the verification behavior. This is clearly distinguishable from generic siblings like set_supported_clip_property or set_opacity, which mutate different attributes.

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 only usage context is the implicit 'in the active sequence' scoping; there is no statement of when to prefer this over set_supported_clip_property, no prerequisites, and no guidance on when the tool should not be used. The alternative of just muting via a property setter is left unaddressed.

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 disclosure burden. It usefully signals that a keyframe must pre-exist (this won't create one) and that it mutates existing state, but omits what happens on failure, whether the change is reversible, or any auth/permission needs.

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, well-front-loaded sentence with the verb and resource leading. No redundant or filler content.

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 13-parameter tool with multiple ways to identify the target clip/property, the description is thin. It doesn't clarify the identity-resolution options or the capability-gating implied by 'when_supported', though the rich schema mitigates the gap and no output schema needs explaining.

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 85%, so the schema already documents the parameters, including the interpolation_mode enum values. The description's mode list adds no meaning beyond the schema, so 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?

States a specific verb (Set) and resource (keyframe interpolation mode) and enumerates the accepted modes, pinpointing it against siblings like add_property_keyframe and update_property_keyframe. The phrase 'at an existing keyframe on a clip property' scopes the operation precisely.

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?

'at an existing keyframe' implies the prerequisite that a keyframe must already exist, which is useful when-to-use context. However, it never names alternatives (add_property_keyframe, update_property_keyframe) or states when not to use it, leaving usage largely to inference.

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 behavioral burden. It usefully discloses that the tool verifies the readback value and supports two coordinate modes, but omits permissions, reversibility, required clip-targeting context, and failure behavior for a mutation operation.

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 the action and resource. The coordinate examples are compact and useful, with no wasted text.

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 an 8-parameter mutation tool with no annotations and no output schema, the description covers the core operation and coordinate modes, and the schema covers most parameters. It still leaves clip-targeting prerequisites implicit and does not explain what the readback verification returns, so 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?

Schema description coverage is 88%, so the baseline is 3. The description adds concrete examples (960,540 for a 1920x1080 sequence; 0.5,0.5 for center) that reinforce coordinate_mode, but this is largely redundant with the schema's own parameter descriptions.

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 'Set' and resource 'Motion Position (X,Y) of a video clip on the timeline', clearly differentiating it from sibling motion tools like set_motion_scale and set_motion_rotation. The coordinate-mode support is also stated up front.

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?

No explicit when-to-use guidance versus alternatives such as move_clip or set_motion_scale; usage is implied by the purpose. It explains coordinate modes but does not state prerequisites or when to choose this tool over other timeline motion tools.

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 behavioral burden. It usefully notes a readback verification step, but says nothing about permissions, reversibility, failure behavior, or the response shape for a 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?

A single front-loaded sentence with no padding; the trailing verification clause earns its place by adding behavior rather than repeating the schema.

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 mutation tool with no annotations and no output schema, the definition leaves gaps: it never explains how clip_name, clip_index, and clip_node_id relate or which takes precedence, though the readback mention partially covers the return value.

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 83%, so the schema already documents rotation_degrees (with example angles) and the clip identifiers; the description adds only the unit restatement ('in degrees'). 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?

States a specific verb (Set), resource (Motion Rotation angle), and target (on a video clip), which cleanly separates it from the sibling set_motion_position and set_motion_scale. It does not, however, explicitly name those siblings or route the agent among them.

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?

No when-to-use guidance, prerequisites, or alternatives. The agent is not told whether the clip must be selected first, nor how the three clip-identification parameters relate.

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 does disclose one genuine behavioral trait beyond the schema: the tool verifies the readback value after setting. However, it says nothing about required permissions, whether the change is undoable, what happens on failure or readback mismatch, or how clip targeting parameters interact.

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 sentence that names the action, the unit, the target object, and the post-write verification. Every clause earns its place with no 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?

For an 8-parameter mutation tool with no annotations and no output schema, the description covers purpose and verification but leaves open how the multiple clip-identification parameters (clip_name vs clip_index vs clip_node_id) resolve and how uniform_scale and scale_width interact. Adequate but with clear gaps.

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 88%, so the schema already documents scale, clip_name, clip_index, track_index, clip_node_id, uniform_scale, and scale_width. The description's only parameter-level contribution is repeating the percentage example, which the schema also gives. Baseline 3 is appropriate when the schema does the heavy lifting.

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 (Set) and resource (Motion Scale percentage on a video clip), which clearly separates it from siblings like set_motion_position and set_motion_rotation. The parenthetical example (100 for 100%) pins down the unit. It does not explicitly name the sibling alternatives, so it stops short of a 5.

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 when-to-use/when-not guidance and no named alternative among the many motion/clip-setting siblings. Usage is only implied by the verb and resource. An agent must infer that this is the tool for uniform/non-uniform scaling versus position or rotation.

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 burden. It does disclose a genuine behavioral trait beyond the schema: the tool verifies the readback value after writing. However, it says nothing about failure behavior, idempotency, or what a failed verification means.

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 with zero filler, with the action and target front-loaded before the verification clause.

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 are no annotations and no output schema, so the description must explain the return side; it gestures at this by mentioning readback verification but never says what value or format comes back. The ambiguity of six parameters offering three alternate clip-identification routes is also left unresolved.

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 83% and every meaningful parameter is documented, so the baseline is 3. The description only restates the opacity range already in the schema and adds no guidance on how clip_name, clip_index, and clip_node_id interact when locating the target clip.

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 ('Set the Opacity percentage... on a video clip') plus the value domain (0 to 100), which separates it from the motion siblings (set_motion_position/scale/rotation) and set_supported_blend_mode. It stops short of clarifying why an agent would pick it over the generic set_supported_clip_property, which could plausibly also set opacity.

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?

No when-to-use context, no prerequisites, and no mention of the overlapping generic setter (set_supported_clip_property) or of read_clip_properties for inspection. The agent has to infer context from the name and sibling list.

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 burden. It usefully discloses that the tool verifies the readback value after setting, which is behavioral context beyond the schema. However, it says nothing about failure modes (e.g. when a blend mode is unsupported), permission needs, or how the readback is surfaced in the response.

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 sentence with no filler; the long parenthetical example list is slightly padded but still informative and not 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 6-parameter mutation tool with no annotations and no output schema, the description covers the core action and the verification step, which is adequate. It stops short of explaining return/readback shape or error behavior, leaving gaps an agent might need when the call fails.

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 high (83%), so the schema already documents the parameters well. The description restates blend-mode examples and mentions the video-clip target, but adds no new syntax or meaning (e.g. how blend_mode interacts with clip_name vs clip_index vs clip_node_id) beyond what the schema provides.

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 (Set) and resource (Blend Mode on a video clip's Opacity component), which is more precise than a generic 'set property' tool. The target component (Opacity) distinguishes it from set_opacity and set_supported_clip_property, though it never names those siblings explicitly.

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?

Usage is implied by the name and description (set a blend mode), but there is no explicit guidance on when to pick this over set_opacity or set_supported_clip_property, nor any prerequisites such as needing a clip selected or located. No exclusions or alternatives are offered.

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 burden, but it does disclose one meaningful trait beyond the name: the value is verified by reading it back from Premiere Pro. It does not cover mutation semantics, permission requirements, or what 'supported' excludes, leaving substantial behavioral gaps for a write 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?

A single tightly constructed sentence that front-loads the action and appends the verification behavior with no filler. 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 10-parameter mutation tool with no annotations and no output schema, the description omits important context: what makes a property 'supported', how a failed read-back verification is surfaced to the caller, and whether this is the intended fallback over the specialized setters. The verification mention is a start but the definition is not fully self-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?

Schema description coverage is 100%, so all 10 parameters are already documented in the schema (including the value type union and the property/component name-vs-index distinction). The description adds no additional parameter meaning, so 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 description gives a specific verb and resource: 'Set a supported property value on any component/effect of a timeline clip.' It is clear what the tool does, but it does not distinguish itself from the specialized siblings (set_motion_scale, set_opacity, set_supported_blend_mode), so an agent must infer that this is the generic fallback.

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 'any component/effect' implies this is the general-purpose setter usable when no dedicated tool applies, which is useful implied scope. However, there is no explicit when-to-use/when-not guidance or routing away from the many specialized setter siblings, so usage is only inferred rather than stated.

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 burden, and it does real work: it discloses the QE DOM adapter workaround for Premiere Pro 2019's missing TrackItem.split() and states that the operation verifies the clip count increased. It still omits failure behavior (what happens if the time is not inside a clip), whether the split is reversible, and how linked audio/video clips are treated.

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 the action and scope. The second sentence is implementation rationale rather than a spec, but it earns its place by explaining why the tool exists and that it self-verifies. 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 mutation tool with no annotations and no output schema, the description covers the core action, precondition, and verification, but leaves out what is returned (e.g., new clip IDs), error semantics, and effects on linked clips or adjacent segments. Adequate but with clear gaps.

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 track_type, track_index, and split_time_seconds are already fully documented in the schema. The description restates the timeline-time-in-seconds semantics but adds no format, edge-case, or constraint detail beyond what the schema provides; 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 (split/razor), the resource (a clip), and the exact scope (a specified video or audio track at a given timeline time in seconds). This clearly distinguishes it from the sibling mutation tools trim_clip, move_clip, and remove_clip without the agent needing to open any schema.

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 when the tool applies by stating the split time must lie strictly inside a clip on the track, which is a usable precondition. However, it names no alternatives (e.g., trim_clip, remove_clip) and gives no explicit when-to-use/when-not-to-use 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 behavioral burden. It hints at frame-accuracy and a post-trim duration verification, but never states that this mutates the project, whether changes are reversible, what permissions or clip-identification are required, or how the all-optional parameter set is resolved. Significant gaps for a 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?

A single sentence with no padding, and the core action (trim) is front-loaded before the verification clause. Slightly compound, but every clause carries 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?

For an annotation-free mutation tool with 8 all-optional parameters and no output schema, the description is too thin: it omits destructive/state-changing behavior, response shape, and how the clip is identified, leaving the agent without enough to call it correctly.

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 adds the useful mapping of inPoint/outPoint to source vs. timeline boundaries and the frame-accuracy note, but says nothing about the clip identification parameters (clip_name/clip_index/track_type/track_index/clip_node_id) that the schema already covers.

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 (trim) and resource (timeline clip's source inPoint/outPoint or timeline boundaries), which clearly separates it from siblings like move_clip, split_clip_at_time and remove_clip. It does not explicitly name a sibling to disambiguate against, so it falls just short of a 5.

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 explains what trimming means but gives no when-to-use guidance, no comparison to split_clip_at_time or move_clip, and no prerequisites (e.g. which identifier parameters are needed, whether the clip must be selected first). Usage must be inferred.

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 does usefully disclose that the tool verifies readback after the write, but says nothing about permissions, what happens when no keyframe matches within tolerance, reversibility, or failure modes expected of a mutation.

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 sentence with no filler; the mutation target comes first and the readback verification trails as a secondary clause. Nothing can be trimmed without losing 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?

For a 15-parameter mutation tool with no annotations and no output schema, the description is thin: it never explains the clip/component/property identifier resolution, the meaning of time_reference or tolerance_seconds, or how it interacts with the sibling interpolation 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 80%, so the schema already documents nearly every parameter. The description only restates the value and optional interpolation mode, adding nothing about time_reference semantics, the tolerance-based keyframe matching, or the clip identifier alternatives.

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 ('Update the value ... of an existing keyframe on a clip property') plus an extra behavior (verify readback). The word 'existing' implicitly separates it from add_property_keyframe and remove_property_keyframe, but no sibling is named explicitly, so it stops short of a 5.

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 or when-not guidance and no mention of alternatives such as add_property_keyframe for new keyframes or set_keyframe_interpolation_when_supported for interpolation-only changes. The overlap with the interpolation sibling is left for the agent to resolve on its own.

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 burden. 'Validate' implies a read-only pre-flight check with no side effects, and the enumerated checks are useful. However, it doesn't disclose what happens on failure (error vs. warning list) or whether any checks have side effects, leaving behavior partly unspecified.

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 sentence with zero filler, leading with the verb and the full list of validated aspects. Nothing could be trimmed without losing substance.

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?

Parameters are fully documented in the schema, but with no output schema the description never indicates the return shape (pass/fail, warning list, error details). For a validation tool whose primary value is its result, that omission is a meaningful gap.

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 parameters such as output_path, preset_path, work_area, and export_mode are already documented in the schema. The description's mention of output path and preset existence loosely maps to those fields but adds no format or syntax detail beyond the schema. 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 ('Validate') and enumerates exactly what is checked: output path, .epr preset existence, overwrite hazards, and sequence readiness. This clearly distinguishes it from sibling export_active_sequence, which actually performs the export.

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 'before starting an export' establishes clear timing context for when to call it. It stops short of naming the alternative tool or stating when-not to use it, but the pre-flight framing is unambiguous.

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