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

No annotations are provided, so the description carries full burden. It discloses that the tool 'imports if needed' and allows trimming via inSeconds/outSeconds. However, it does not mention the behavior of the 'mode' parameter (overwrite/insert), whether tracks are created if missing, or any error conditions.

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 concisely convey the main purpose and optional trimming. Front-loaded with the primary action. Could include more behavioral details without being verbose, but current structure is efficient 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?

Given the tool has 6 parameters, no output schema, and no annotations, the description is adequate but not exhaustive. It covers the core functionality and trimming, but lacks explanations for mode, track handling, and import implicit steps. For a tool of this complexity, more details would enhance completeness.

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 50% (3 of 6 parameters described). The description adds context by naming media types and mentioning trimming parameters (inSeconds/outSeconds), but does not explain mode or atSeconds beyond what the schema provides (e.g., start time default 0). Baseline of 3 is appropriate with moderate added value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Place an audio file on an audio track'), specifies the resource ('audio file: music, SFX, voiceover'), and mentions optional trimming. It distinguishes itself from sibling tools like premiere_place_clip and premiere_add_overlay by focusing specifically on audio placement.

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 usage for adding audio to a track at a given time, but lacks explicit guidance on when to use this tool vs. alternatives (e.g., premiere_place_clip for general clips, premiere_add_effect for effects). No prerequisites or when-not-to-use conditions are mentioned.

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 only 'openWorldHint' annotation, the description carries the burden. It states the tool detects beats and places markers, returning the count, but does not confirm that the audio file remains unmodified, or discuss error handling for invalid paths or missing sequences.

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 two sentences, front-loading the primary action and purpose, then stating the return value. Every sentence adds value with no repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 4 parameters, no output schema, and minimal annotations, the description covers the core functionality and return. It could be improved by mentioning prerequisites (e.g., audio must be imported) or limitations, but it is largely complete for a simple 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?

The input schema has 100% description coverage, so the schema already explains each parameter. The description adds context like 'sensitivity defaults to 0.5' and 'offsetSeconds shifts markers', but does not significantly expand on the schema's meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool detects beats in an audio file and drops timeline markers on each beat, specifically for cutting/editing to music. It distinguishes itself from siblings like 'premiere_add_marker' (single marker) and 'premiere_detect_beats' (detection only).

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 usage when aligning cuts to music beats and mentions working on the active or specified sequence. However, it does not explicitly state when not to use this tool or provide alternatives, though sibling names offer some context.

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?

Annotations already provide destructiveHint=true, indicating mutation. Description adds the 'Experimental' warning and notes 0-based clipIndex. However, it does not disclose broader behavioral traits like persistence, error handling for invalid effect names, or impact on 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?

Two concise sentences with an example list. Every sentence provides essential information: action, resource, examples, experimental status, and key parameter details. No unnecessary words.

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?

Lacks critical context such as whether a sequence must be active, what happens after applying (no output schema), and how to interpret results. For a destructive tool, more completeness is needed to ensure safe 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 low (33%), but the description adds value by giving example effect names for the 'name' parameter and explaining clipIndex is 0-based. However, 'videoTrack' parameter lacks any description, so meaning is incomplete.

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?

Description clearly states the verb 'apply' and resource 'video effect by name' to a clip. Provides concrete examples like 'Directional Blur', which distinguishes it from sibling tools like premiere_add_audio or premiere_add_transition that handle different media types.

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 guidance on when to use this tool vs alternatives. Mentions 'Experimental' but does not specify prerequisites, when not to use, or compare with other effect-adding tools. Sibling list shows many similar tools but no selection criteria.

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 full behavioral disclosure. It states the add operation but omits potential side effects, requirements (active sequence), or behavior when timeSeconds is out of range. It does not contradict any annotations.

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 that efficiently conveys the core action and optional parameters. No redundant or unnecessary words.

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?

Given no output schema or annotations, the description should provide more context about the result (e.g., whether a marker object is returned), constraints (timeSeconds must be within sequence duration), and default behavior for 'sequenceId'. It leaves significant gaps for an agent to infer 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?

The description adds meaning for 'type' by listing its enum values and clarifies that 'name' and 'comment' are optional. However, it does not explain 'sequenceId' (defaults to active sequence) and schema coverage is only 40%, so the description only partially compensates.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action 'Add a timeline marker' and specifies the resource and scope: 'to a sequence at a given time (seconds)'. It differentiates from sibling tools like 'premiere_add_beat_markers' and 'premiere_list_markers'.

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 guidance is given on when to use this tool vs. alternatives (e.g., 'premiere_add_beat_markers'), or prerequisites such as needing an active sequence. The description lacks context for proper tool selection.

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?

The description lacks detail on behavioral traits beyond the basic operation. It does not disclose whether the overlay overwrites existing clips, whether the track must exist, or any side effects. Annotations only provide openWorldHint: true, which contradicts the schema's additionalProperties: false. The description adds some context (default V2 track, blend mode list), but without readOnlyHint or destructiveHint, the agent needs more clarity on mutability and safety.

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 very concise: two sentences that efficiently convey the primary purpose, default behavior, and a complementary tool. Every word adds value, with no redundancy or filler. The key information is front-loaded, making it easy for an agent to quickly understand the tool's core function.

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?

Given the tool has 6 parameters (1 required) and no output schema, the description covers the main intent and default values but omits details on timing parameters (atSeconds, outSeconds) and behavior when they are absent. The reference to a sibling tool is helpful, but the description does not explain what happens after the overlay is placed (e.g., does it return anything?). It is adequate but not comprehensive.

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 description adds meaning beyond the schema by stating default values for videoTrack (2) and blendMode (screen), and listing common blend modes. It explains the purpose of blend modes for cinematic effects. However, atSeconds and outSeconds lack descriptions in both schema and description, which is a gap. Overall, the description compensates well for the 67% schema 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 clearly states the tool's purpose: placing a media clip as an overlay on a higher video track with a blend mode and opacity. It specifies the resource (overlay media), the action (place), and the context (cinematic use for light leaks, dust, grain). It distinguishes from sibling tools like premiere_add_audio (audio) and premiere_place_clip (standard clip placement) by emphasizing the overlay and blend mode functionality.

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 provides clear context for when to use this tool: for adding overlays with blend modes like light leaks. It also suggests combining with premiere_keyframe for fades. However, it does not explicitly state when not to use it or mention alternatives (e.g., for simpler clip placement use premiere_place_clip). The guidance is good but not exhaustive.

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 provided, but description discloses non-destructive addition of a title element. However, it lacks details on results or potential conflicts, which is acceptable for a simple additive tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences: first defines the action, second gives placement tip, third notes default and optional param. Efficient and front-loaded, with no unnecessary words.

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 simple tool with 5 parameters fully documented in schema, the description provides key behavioral context. Lacks mention of return value, but not critical given no output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. Description adds minor context about videoTrack placement and durationSeconds being optional, but no significant extra meaning for other parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool adds an animated title using .mogrt templates with a default Basic Title, distinguishing it from sibling tools like premiere_add_overlay or premiere_add_effect.

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 provides guidance to place on a video track above footage, implying usage for adding titles. It does not explicitly exclude alternatives but context differentiates it from other 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?

Annotations already declare destructiveHint=true, indicating mutation. Description adds that clipIndex is 0-based and mentions experimental nature, which is useful. However, it does not disclose potential failure modes or side effects beyond the annotation.

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 focused sentences with no wasted words. Front-loaded with the tool's purpose, then important caveats and parameter details.

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?

Covers all parameters with defaults, experimental status, and indexing detail. Lacks mention of return value or failure handling, but since there is no output schema, the description is reasonably complete for a 5-parameter tool with no required params.

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%, but description adds default values for each parameter (e.g., name='Cross Dissolve', duration=0.5) and clarifies clipIndex is 0-based. This adds meaning beyond the schema's min constraints.

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?

Clearly states it adds a video transition to a clip's cut, with examples like 'Cross Dissolve'. The verb 'add' and resource 'transition' are unambiguous, and it distinguishes from sibling tools like 'premiere_add_effect' by specifying it's for transitions.

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?

Provides context by noting it's experimental and unsupported but works on PPro 25, guiding agents to use cautiously. Does not explicitly state when not to use or list alternatives, but the context is sufficient for typical use.

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?

Annotations declare destructiveHint=true, and the description adds context: 'best-effort', 'via QE', version fragility warning. It does not contradict annotations. The description enriches behavioral understanding beyond the annotation alone, though it could mention the destructive nature explicitly.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core action in the first sentence. The note and usage guidance are additional but relevant. It is not overly verbose, though the note could be condensed. Overall, it maintains good structure and clarity without waste.

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?

Given no output schema, the description mentions 'report its parameters' indicating return value. The tool is simple with two parameters. It explains the context of version fragility and alternatives. While it doesn't detail return format or parameter selection logic, it is sufficiently complete for an AI agent to understand the tool's purpose and scope.

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 has 2 parameters (videoTrack, clipIndex) with 0% description coverage. The description does not explain these parameters or their meaning (e.g., videoTrack is integer >=1, clipIndex >=0). It mentions 'add to a clip' but provides no detail on how to identify the clip via these parameters, leaving ambiguity. For a tool with no schema descriptions, the description should compensate but fails to do so.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Add a Lumetri Color effect to a clip (via QE) and report its parameters.' It uses a specific verb ('Add') and resource ('Lumetri Color effect'), distinguishing it from sibling tools like 'premiere_add_effect' which is more generic. The title also includes 'best-effort' hinting at reliability.

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 provides explicit guidance: 'Use this to attach Lumetri so you can grade by hand, or pair with premiere_run_extendscript to set specific params.' It also warns against using it for reliable preset grades ('bake it into the Remotion render instead') and notes version fragility. This clearly tells when to use and when not.

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?

Given no annotations, the description provides good transparency by stating the backup is timestamped, saved next to the original, and is non-destructive. This helps the agent understand the tool's behavior without surprises.

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, well-structured sentence that conveys all essential information without redundancy. Every word contributes to clarity.

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 simple tool with one parameter and no output schema, the description is nearly complete. It covers the purpose, output, and safety, though it could mention potential errors (e.g., file not found) or behavior if the backup file already exists.

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 single parameter 'path' is fully described in the schema, and the tool description adds value by explaining the backup location and naming, which goes beyond the schema's description.

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?

Description clearly states the action (backup), the resource (.prproj file), and the output naming convention (timestamped .bak-<timestamp>). It also declares the tool as safe and non-destructive, which further clarifies its purpose and distinguishes it from potentially destructive sibling tools like close_project or save_project_as.

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 usage (backup before making changes) but lacks explicit guidance on when to use this tool versus alternatives such as save_project or close_project. No conditions for use or when not to use 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 only 'openWorldHint: true' in annotations, the description adds substantial behavioral context: it detects beats, builds shots that switch exactly on the beat, places trimmed segments on V1, lays music on A1, and optionally renders. No contradictions with annotations.

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 concise with four sentences, each adding essential information. It is front-loaded with the purpose and follows with key behavioral details, leaving no waste.

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?

Despite lacking an output schema, the description covers the tool's inputs, process, and outputs (shots on V1, music on A1, optional rendering). It is complete enough for an AI agent to understand the overall functionality and expected results.

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 each parameter. The description adds value by explaining 'every beatsPerCut beats' and the conforming behavior related to the 'aspect' parameter, going beyond the schema's basic 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?

The description clearly states the tool automatically cuts footage clips to the beat of a music track, using a specific verb and resource. It distinguishes itself from siblings like 'premiere_detect_beats' and 'premiere_add_beat_markers' which only detect or add markers without performing the edit.

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 advises to provide a footage folder or explicit clip paths along with a music file, giving clear context on inputs. It also notes conforming to 1080p or 9:16, but does not explicitly state when not to use this tool versus 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?

Description declares read-only, matching annotation, and specifies exact checks. No hidden side effects; fully transparent.

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?

Single clear sentence with essential information, no wasted words.

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 simple read-only status check with no parameters, description provides sufficient context. Might lack details on return format, but acceptable given 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?

No parameters; schema coverage is 100% trivially. Baseline 4 for 0-param tools as description doesn't need to add param info.

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?

Description clearly states it checks two specific statuses (bridge panel installed, unsigned CEP extensions enabled) and identifies as read-only. Distinguishes from siblings like install or selftest.

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?

Purpose is self-explanatory; clear it's a status check. No explicit when-not or alternatives, but context from sibling names implies when to use.

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?

Annotations already declare readOnlyHint=true, and the description reinforces safety and reports step-by-step pass/fail results, adding value beyond annotations.

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 concise sentences with no fluff: first describes action, second provides usage guidance. Every word 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 simple self-test tool with no parameters and output described as pass/fail per step, the description is complete and sufficient without an output schema.

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?

No parameters exist; schema coverage is 100%. The description doesn't need to add parameter details, and baseline for zero params is 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it runs safe, read-only checks and reports pass/fail per step. It distinguishes itself from sibling tools like premiere_bridge_panel_status by emphasizing the whole chain verification.

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 explicitly says 'Use to verify the whole chain (MCP -> panel -> ExtendScript) is healthy,' providing clear context for when to use it. It doesn't exclude alternatives but is sufficient for a diagnostic tool.

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?

Description adds behavioral info beyond sparse annotations: it returns a per-step report with warnings, and applies even if some steps fail. Does not mention auth or rate limits, but openWorldHint covers some context.

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, front-loaded with purpose, then components, then additional notes. Efficient but could be more structured with bullet points for clarity.

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?

Covers assembly steps, asset path requirement, optional rendering, and return value. No output schema, but return value described adequately. Could be more explicit about working on active sequence.

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 baseline 3. Description does not add significant meaning beyond schema parameter descriptions; it echoes them without deeper guidance.

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?

Clear verb 'Assemble a whole timeline' and lists specific actions (create sequence, place clips, add titles, audio, transitions, effects, render). Distinguishes from siblings like premiere_add_audio, etc., as the bulk assembly tool.

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?

States it is the 'main fully-automatic assembly tool' and notes asset paths must exist. Lacks explicit when-not-to-use or alternatives, but context from siblings implies use for full builds.

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?

Adds significant detail beyond the destructiveHint annotation: explains default save behavior, that save:false discards changes, and the confirm requirement. No contradiction with annotations.

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, no wasted words, front-loaded with main action. Efficient and clear.

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?

Complete for a simple tool with two boolean params and no output schema. Explains behavior, defaults, and requirements adequately.

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 already describes both parameters well, but description adds extra context about default behavior and the interplay between save and confirm, enhancing semantic understanding.

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?

Clearly states the tool closes the current project, distinguishing it from related tools like save, open, new, and quit. The verb 'Close' and resource 'current project' are specific.

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?

Provides explicit guidance on using save:false vs save:true and the required confirm:true when discarding. While it doesn't explicitly contrast with siblings, the context makes it clear when to use this tool.

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 discloses the creation action and optional nesting, which is sufficient. However, it does not mention side effects like project modification or 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?

The description is one sentence, front-loaded with the verb and resource, and contains no unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is complete enough for a simple creation tool with no output schema. It covers the essential behavior, though it could mention that the bin is added to the current project.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline 3. The description adds 'optionally inside an existing parent bin' which is already implied by the schema description for parentBinName. Minimal added value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates a bin (folder) in the project, with an optional parent bin. This is a specific verb-resource pairing and distinguishes it from sibling tools like create_sequence or import_files.

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 to use (to organize project items) but provides no explicit when-not or alternatives. It is adequate for a straightforward creation tool.

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?

The description discloses the automation pipeline: rendering Remotion visual, synthesizing sound-design bed, compositing in Premiere, and exporting 16:9 and/or 9:16. The annotation 'openWorldHint: true' is somewhat unusual for a creation tool, but the description does not contradict it and provides sufficient behavioral context for an AI agent.

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 coherent paragraph, front-loading the key purpose and actions. It avoids unnecessary words but could be better structured with bullet points for readability. Still concise and clear.

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?

Given the tool's complexity (18 parameters, no output schema), the description covers major aspects like requirements and output formats but lacks details on error handling, expected output structure, or recovery from failed renders. It is adequate but not fully comprehensive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds minimal extra meaning beyond the schema, only hinting at 'neon Remotion visual' tying to accent colors and 'timed sound-design bed' linking to withSfx. No significant additional semantics provided for the 18 parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it produces a cinematic, broadcast-style brand intro fully automatically, using specific verb 'produce' and resource 'brand intro'. It distinguishes itself as 'THE flagship' tool among siblings, implying it's the premium option compared to perhaps simpler tools like 'premiere_create_intro'.

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 provides explicit requirements (Remotion project path without '!', bridge panel) and a condition for overwriting (confirm:true). However, it does not explicitly state when to use this tool versus alternatives such as 'premiere_create_intro' or other intro-related 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?

The description outlines the main actions (creates sequence, places logo, overlays title, adds music, optionally renders) and mentions the return of a build report. This is good disclosure for an openWorldHint tool, but it could explicitly state that it modifies the project by adding sequences and items.

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 two-sentence description is extremely concise, front-loads the primary action, and provides a best-practice tip without any wasted words. Every sentence adds value.

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?

Given the complexity (10 parameters, no output schema), the description covers the main workflow and a best-practice recommendation. However, it does not detail the build report's contents or mention potential side effects like sequence naming, leaving some 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?

With 100% schema coverage, the description adds context beyond the schema, e.g., logoPath defaults to the M.P logo and outputPath triggers rendering. It enhances understanding of defaults and overall workflow, justifying a score above the 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 clearly states the tool's purpose: 'Fully automatic cinematic logo/title intro.' It details the steps (creates a sequence, places logo, overlays title, adds music, optionally renders), making the function distinct from sibling tools like premiere_create_brand_intro.

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 provides a best-practice guideline: 'Best results come from a PRE-RENDERED animated logo with alpha/own background (Remotion/After Effects output).' It implies the tool is for automatic creation but does not explicitly exclude or compare to alternatives, though the automation context serves as implicit usage 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?

Discloses key behavioral traits: opens modal dialog requiring human confirmation, returns error if not confirmed, defaults to HD 1080p 25fps, and includes timeout parameter. No annotations present, so description carries full burden. Lacks mention of return value on success or other error conditions.

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?

Description is efficiently structured with a clear first sentence for purpose, followed by a note detailing the modal dialog behavior. Every sentence adds value, though the note is slightly long.

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?

Covers the dialog interaction and preset selection, but fails to specify the return value on successful creation. Given the complexity and lack of output schema, some information about the returned sequence object or success indicator is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with parameter descriptions, but description adds value by explaining defaults (HD 1080p 25fps, useDefaultPreset true, timeout 60) and the purpose of presetPath in the dialog. This goes beyond the schema alone.

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?

Clearly states it creates a new sequence and mentions default preset and modal dialog behavior. However, it does not differentiate from the sibling tool 'premiere_new_sequence', which appears to serve a similar purpose.

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?

Implies usage for sequence creation but provides no explicit guidance on when to use this tool versus alternatives like 'premiere_new_sequence'. Only directs to use 'premiere_list_sequence_presets' for preset selection.

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?

The description adds value beyond annotations by disclosing that the tool uses ffmpeg and supports any audio format. It also confirms the read-only nature, consistent with the readOnlyHint annotation. There is no contradiction with annotations.

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 extremely concise with only two sentences, each serving a distinct purpose: the first describes the action and output, the second provides usage guidance. No unnecessary words.

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?

Given the tool's simplicity (2 parameters, no output schema), the description fully covers what the tool does, its inputs, outputs, and usage context. It tells the agent exactly what to expect and how to use the results.

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?

With 100% schema description coverage, the description adds only minimal extra meaning: it explains the sensitivity range ('0=only strong hits, 1=many onsets (default 0.5)'), which is helpful but not critical beyond the schema's description. The baseline of 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 clearly states the tool analyzes audio files and returns beat times, strength, and BPM. It uses specific language ('Analyze', 'return') and distinguishes from sibling tools that create or modify, emphasizing its read-only nature and independence from Premiere.

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 explicitly states how the output should be used ('cut clips, place keyframes or markers on the beat / bass drops'), providing clear usage guidance. However, it does not mention when not to use this tool or provide alternatives, though sibling tools like premiere_add_beat_markers could be seen as complementary rather than 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?

The description discloses that the tool BLOCKS until render finishes and that overwriting an existing output requires confirm:true. It adds valuable behavioral context beyond the annotations (openWorldHint). It could mention return values or error handling, but it is transparent about key behaviors.

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 concise: two sentences, front-loaded with the main action, and no wasted words. Every sentence serves a purpose.

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?

Given the tool has 6 parameters and no output schema, the description covers usage, blocking behavior, overwrite handling, and references a related tool. It is complete enough for an agent to understand when and how to use the tool 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?

With 100% schema coverage, the baseline is 3. The description adds meaning by noting that outputPath must include an extension matching the preset, presetPath comes from premiere_list_export_presets, sequenceId defaults to active, range defaults to 'entire', and confirm is only needed when file exists. These details enhance schema 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?

The description clearly states 'Render/export a sequence to a media file' using Premiere's built-in direct exporter, and distinguishes itself from sibling tools by specifying the export method. It conveys the action and resource effectively.

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 provides clear guidance on when to use: provide an output path in an allowed root and a preset path from premiere_list_export_presets. It mentions blocking behavior and overwrite requirement. However, it does not explicitly state when not to use this tool versus alternatives like using Adobe Media Encoder, but given sibling context, this is sufficient.

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?

Annotations already declare readOnlyHint=true. The description adds valuable behavioral details: case-insensitive searching, substring matching, and the specific return fields (nodeId, type, tree path). No contradictions with annotations.

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 extremely concise: two sentences that front-load the action and include all key information. Every word 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 simple tool with one parameter, no output schema, and no nested objects, the description fully covers input behavior (query, case-insensitive) and expected output (nodeId, type, tree path). No 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 coverage is 100% with a single parameter 'query' described as 'Substring to search for in item names.' The tool description adds the critical detail that the search is case-insensitive, which is not in the schema parameter description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it finds project items by name substring, case-insensitive, and specifies returned fields. However, it does not explicitly distinguish from the similar sibling tool 'premiere_list_project_items', which likely lists all items without filtering.

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 guidance is provided on when to use this tool versus alternatives like 'premiere_list_project_items' or other search tools. The description only states what it does, not when it is appropriate.

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?

The description is minimal and does not elaborate on side effects (e.g., window restoration from minimized state) or error conditions. The 'openWorldHint' annotation hints at unseen effects, but the description adds no clarification.

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, concise sentence that conveys the essential purpose with no superfluous words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is adequate for a simple tool with no parameters, but it lacks details about expected return values or failure modes. Given the simplicity, it is not comprehensive but 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?

There are no parameters, so the schema coverage is 100%. The description adds no parameter information, but with zero parameters, no additional meaning is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly specifies the action ('bring') and the target ('Premiere's main window'). It is distinct from sibling tools, none of which focus windows.

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 use when the agent wants to bring Premiere to the foreground, but it does not provide guidance on prerequisites (e.g., Premiere must be running) or when not to use it (e.g., if the window is already focused). No alternatives or exclusions are mentioned.

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?

Annotations already declare readOnlyHint=true, and the description reinforces 'read-only report'. Beyond annotations, it details the report contents (app info, project metadata, sequences, tracks, sample items), providing useful behavioral context without contradiction.

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 two sentences long, front-loading the core purpose and contents, followed by a usage recommendation. There is no redundant information, and every sentence serves a clear purpose.

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?

Given the tool's moderate complexity (consolidated report with two optional parameters) and the presence of good annotations and schema coverage, the description adequately covers purpose and contents. It could mention output format or performance implications, but is sufficient for an agent to understand and invoke the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% for both parameters, with clear descriptions for includeTracks and itemSample. The tool description adds minimal extra meaning, mentioning tracks and sample project items, but does not elaborate on parameter usage 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?

The description clearly states 'Produce a single consolidated, read-only report of the current state' and enumerates specific contents (app info, project metadata, sequences, tracks, sample items), distinguishing it from sibling tools that focus on individual aspects. The phrase 'Great as a first overview' further clarifies its role.

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 explicitly positions the tool as 'Great as a first overview', giving a clear use case for initial broad information gathering. Although it does not explicitly list alternatives or when not to use it, the context of sibling tools and the description's intent provide adequate 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?

The annotation already declares readOnlyHint=true. The description additionally states 'Read-only' and clarifies the null case, which adds value beyond the annotation. No contradictions.

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 sentence that is front-loaded and contains no extraneous words. Every word 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 read-only, zero-parameter tool, the description adequately communicates the return value (sequence details or null). The lack of an output schema is mitigated by the simple nature of the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0 parameters, and schema coverage is 100%. The description does not need to add parameter info. Baseline of 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 clearly states the tool returns details of the currently active sequence or null, with a specific verb and resource. It is easily distinguished from siblings like 'premiere_list_sequences' (lists all sequences) and 'premiere_set_active_sequence' (sets active sequence).

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 context of 'active sequence' implies when to use this tool. It does not explicitly provide when-not or alternatives, but the purpose is clear enough for an AI agent to decide. No exclusions are needed.

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?

Annotations declare readOnlyHint=true. The description adds valuable behavioral context by detailing exactly what information is returned, which goes beyond the annotation.

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, well-structured sentence that packs all necessary information without any fluff. Every word 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 exists, but the description comprehensively lists the returned information. It covers version/build, open projects, existence checks, and preference paths.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has no parameters, and the description adds meaning by explaining the return values. Schema coverage is 100% (empty schema), so baseline is 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns specific app info (version/build, open projects, project/sequence existence, preference paths) and is read-only. It distinguishes itself from sibling tools which are action-oriented.

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 does not explicitly state when to use this tool versus alternatives, but its purpose is clear as a general app info retrieval tool. No guidance on when not to use it.

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?

Annotations already declare readOnlyHint=true. Description adds that the tool reports app version and project/sequence state, and is read-only, which provides additional behavioral context beyond the annotation.

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 verb, no wasted words. Every sentence adds value.

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 zero parameters, readOnlyHint annotation, and no output schema, the description fully covers what the tool does and when to use it. No 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?

No parameters, so the baseline is 4. The description does not need to add parameter info, and it does not.

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?

Clearly states the tool queries the in-app host for exposed functions and reports app version, project/sequence state. The verb 'Ask' and specific outputs distinguish it clearly from all sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly suggests using it for verifying the bridge end-to-end, which provides a clear use context. Does not mention when not to use or alternatives, but for such a simple tool the guidance is adequate.

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?

Annotations provide readOnlyHint=true. The description adds behavioral details: returns tails of multiple files or full content of one file if 'file' is given. No side effects are disclosed, but none are expected for a read-only 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 core purpose, no filler. Every word adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description explains what the tool returns (tail vs full file), which is sufficient given the simple parameter set and read-only nature. No output schema exists, so the description compensates reasonably.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds context about the 'file' parameter overriding the default tail behavior, but the schema already describes both parameters adequately.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly specifies the tool reads Premiere's log/diagnostic files, lists example filenames, and distinguishes behavior (tail vs full file). As the only log-reading sibling, it is well-differentiated.

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 'Read-only', indicating a safe operation. While it doesn't explicitly contrast with sibling tools, no sibling overlaps in function, so it is clear enough for an agent to decide when to invoke.

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?

The description states 'Read-only,' which aligns with the annotation readOnlyHint=true. It adds specific context about the locations (APPDATA + Documents) and that it lists files, going beyond the annotation.

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 sentence with no wasted words, clearly conveying the purpose and behavior.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is complete for a read-only list tool with no parameters. It could mention the purpose (e.g., debugging), but given the simplicity, it is adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the description doesn't need to add semantic info. Baseline for 0 params is 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'List Premiere's on-disk preference/profile folders (APPDATA + Documents) and their files. Read-only.' It uses a specific verb ('List') and resource ('preference folders/files'), and distinguishes from sibling tools like 'premiere_get_preferences' by specifying it's about on-disk files.

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 provides no guidance on when to use this tool vs alternatives, such as 'premiere_get_preferences'. No when-not-to-use or context is given.

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?

Annotations already declare readOnlyHint=true. Description adds that it accesses live data via the bridge, but does not detail further behaviors like latency or data format. Still adequate.

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 concise sentences without redundancy. Each sentence adds essential information: what the tool does and when to use the alternative.

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 no-parameter read tool, description covers purpose and differentiation. Could mention return format, but not critical given 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?

No parameters; schema coverage is 100%. Description adds context about what the tool returns (preference/scratch paths), meeting the baseline for zero-parameter tools.

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?

Description clearly states it returns live preference/scratch paths from the running app via the bridge. Verb 'Return' and resource are specific. Distinguished from sibling tool for raw on-disk files.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly advises using premiere_get_preference_files for raw on-disk preference files, providing clear when-to-use guidance and an 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?

Annotations already provide readOnlyHint=true. The description adds context by enumerating the returned metadata fields, confirming the read-only nature and providing specific behavioral details beyond annotations.

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 with front-loaded purpose. Every word is informative and efficient.

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?

Given no parameters and no output schema, the description provides sufficient detail about the returned project metadata. It is complete enough for an agent to understand what to expect, though the structure of the response is not specified.

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 input schema has zero parameters with 100% coverage, so no parameter explanation is needed. The description appropriately omits parameter info.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns metadata about the currently open project, listing specific fields (name, file path, document ID, etc.). It distinguishes well from sibling tools like 'premiere_get_active_sequence' and 'premiere_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 mentions the tool is read-only, implying safe usage, but lacks explicit guidance on when to use this tool versus alternatives. No 'when to use' or 'when not to use' statements.

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?

Annotations already declare readOnlyHint=true, and the description reinforces 'Read-only' and adds useful behavioral details like included fields (names, times) and the optimization option for includeClips. No contradictions.

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 two concise sentences with no wasted words. The main purpose is front-loaded, and the parameter guidance is efficiently integrated.

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?

Given that this is a simple read-only query with two optional parameters and no output schema, the description sufficiently covers the return content (tracks with clip details) and usage tips. It could be slightly more explicit about track structure but is generally 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?

With 100% schema coverage, baseline is 3. The description adds semantic value by explaining the effect of setting includeClips to false (‘lighter summary’) and implying default behavior for sequenceId (active sequence), which goes beyond the schema 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?

The description clearly states it returns video and audio tracks of a sequence, with specific details like per-clip names and timing. It distinguishes from siblings like premiere_get_active_sequence or premiere_list_sequences by focusing on track and clip specifics.

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 provides clear context for using the tool: it is read-only and can be used to get track data. It also gives a tip for a lighter summary via the includeClips parameter, but does not explicitly mention when not to use it or list alternative tools for related tasks.

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?

The description reveals that warning dialogs are suppressed by default, a behavioral trait beyond the openWorldHint annotation. It also states required preconditions (paths must exist) but does not detail error handling or return behavior, which is a minor gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise (two sentences, 28 words) and front-loads the primary purpose in the first sentence. Every clause contributes value with no redundancy or 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 simple import tool with three parameters and no output schema, the description covers the main action, media types, optional bin, path existence precondition, and a behavioral quirk (warning suppression). It lacks explicit return value info but is otherwise fairly 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?

The input schema already provides full descriptions for all three parameters (100% coverage). The description adds context about 'optionally into a named bin' and 'All paths must exist' but does not significantly enhance the parameter meaning 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?

The description clearly states the tool imports one or more media files into the open project, optionally into a named bin. It specifies media types (video/audio/image) and distinguishes from sibling tools like premiere_add_audio or premiere_add_effect, which are not import operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is used for importing media files but does not explicitly provide when-to-use or when-not-to-use guidance. It mentions preconditions (paths must exist) but no alternatives, making it adequate but not exemplary.

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?

Annotations already provide readOnlyHint=true, and the description reinforces 'Read-only'. It adds details about decompression and reported fields, which are valuable beyond annotations.

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 with no wasted words. The key point ('WITHOUT opening Premiere') is front-loaded, and every sentence adds value.

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, but the description sufficiently explains what the tool returns. Given the low complexity (2 params, 1 required) and the clear read-only context, the description is 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 baseline is 3. The description adds context about the tool's output (file size, decompressed size, etc.), which helps infer parameter purpose beyond the schema 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?

The description explicitly states 'Inspect a .prproj WITHOUT opening Premiere' and lists specific reports (file size, decompressed size, metadata, counts). It clearly distinguishes from sibling tools that open or modify projects.

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 indicates read-only inspection without launching Premiere, implying when to use it. While it doesn't name alternatives, the context of sibling tools makes it 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?

The description discloses key behavioral traits: 'no admin', enables unsigned CEP extensions, copies panel to Adobe CEP folder. With only openWorldHint annotation, the description carries the burden and provides specific, actionable details.

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 two sentences long, front-loaded with the action, and uses no unnecessary words. Every sentence adds value.

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?

Given no parameters or output schema, the description covers the purpose, the action taken, and a critical post-step. It does not explain the bridge panel's role, but the sibling tools provide context.

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?

No parameters in the schema, so the description does not need to add parameter info. Baseline for zero parameters is 4.

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 ('Install') and resource ('CEP bridge panel into Premiere'), clearly distinguishing it from sibling tools that perform editing or other operations.

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 provides explicit post-install steps ('RESTART Premiere and open Window > Extensions > Premiere MCP Bridge'), giving context for use. However, it does not explicitly state when not to use or compare with alternatives like 'premiere_bridge_panel_status'.

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?

Disclosures 'VERIFIED scriptable' and notes speed ramps are not reliably scriptable. Annotation already marks destructiveHint=true, but description adds meaningful context about reliability and limitations.

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 purpose. Second sentence packs many details but remains readable. Could be slightly more structured, but efficient overall.

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?

Covers all four parameters, required fields, key structure, interpolation options, and usage example. No output schema, but description compensates with complete parameter guidance.

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?

100% schema coverage so baseline 3. Description adds value by explaining each property, the key value format, interpolation types, and giving a concrete example (push-in with scale).

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?

Clearly states 'Animate a clip with keyframes' and lists the exact properties (scale, opacity, rotation, position). Distinguishes from siblings by focusing on keyframing versus adding effects or transitions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly warns against using for speed ramps (not reliable) and directs to 'bake into the Remotion render' as alternative. Provides both when-to-use and when-not-to-use 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?

The description discloses the launch behavior, optional project opening, and waiting mechanism, which adds detail beyond the openWorldHint annotation. It does not contradict annotations. Some information about return behavior or idempotency (if app already running) is missing.

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 concise, front-loaded sentences. The first states the primary action, the second covers optional behaviors and a prerequisite. No redundant 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 simple launch tool, the description covers main actions and constraints. It does not specify return values (no output schema) or behavior when app is already running, but these gaps are 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?

Schema coverage is 100%, but the description enriches parameter meaning: 'absolute .prproj path' clarifies projectPath, and 'Poll the bridge for up to N seconds' explains waitForBridgeSeconds behavior. This adds value beyond the schema 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?

The description clearly states the tool's primary action ('Start Adobe Premiere Pro') and specifies optional behaviors (open project, wait for bridge). It distinguishes from siblings like premiere_open_project (which targets already-running instances) and premiere_quit.

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 provides context for when to use optional parameters (projectPath, waitForBridgeSeconds) and a prerequisite for waiting (bridge panel auto-open). However, it does not explicitly state when to use this tool vs alternatives like premiere_open_project, leaving some inference to the agent.

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?

The description adds value beyond annotations by specifying the exact folder name ('Adobe Premiere Pro Auto-Save') and the recovery context. The readOnlyHint annotation is complemented by the explicit 'Read-only' note.

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 concise sentences: first for action and resource, second for use case and read-only note. No redundant 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 zero-parameter, no-output-schema tool, the description fully covers what the tool does, what it returns (list of auto-save projects), and why it's useful (recovery). Nothing missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With zero parameters and 100% schema coverage, the baseline is 4. The description correctly omits parameter details since none exist.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'List' and the specific resource 'Premiere's automatic backup projects', including the exact folder name. It distinguishes from sibling tools like list_project_items or list_sequences by focusing on auto-saves.

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 mentions 'Useful for recovery', implying a recovery scenario, but does not explicitly state when to use this tool versus alternatives (e.g., list_project_items) or provide any when-not-to-use 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?

The description declares the tool is 'Read-only', aligning with the readOnlyHint annotation. It adds context about finding presets on disk and listing available formats, which goes beyond the annotation to inform the agent about side effects and behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with two sentences. The first sentence delivers the core purpose and filtering capability, while the second provides a usage hint and safety note. No redundant words.

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?

Given the simple tool (2 optional params, no output schema), the description adequately covers purpose, filtering, and output usage. However, it does not specify the output format (e.g., list of objects with 'path'), which could be helpful. Still, it's sufficient for an agent to use 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 mentions 'optionally filtered by a name query', which adds no new information beyond the schema's parameter descriptions for 'query' and 'limit'.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists .epr export presets from disk, specifying codec types (H.264/HEVC/ProRes/AAC) and optional filtering. It distinguishes from sibling 'premiere_list_sequence_presets' by focusing on export presets.

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 explicitly tells the agent to pass the returned 'path' value to 'premiere_export_sequence', providing a clear usage context. It does not explicitly state when to avoid this tool, but the purpose is narrow enough that no exclusion is needed.

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?

Annotations already declare readOnlyHint=true. The description adds 'Read-only' and clarifies the default behavior for missing sequenceId, providing useful context beyond the annotation.

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 extremely concise with two sentences, no filler, and front-loads the key action. Every sentence is valuable.

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 simple read-only tool with one optional parameter and no output schema, the description covers purpose, scope, and safety completely.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the parameter description already notes the default. The tool description does not add new information about the parameter beyond matching 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?

The description clearly states the verb 'list' and resource 'markers of a sequence', specifying scope (all markers, with default to active sequence). It distinguishes from sibling 'premiere_add_marker' by mentioning read-only nature.

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 implies use when you need to view markers, and the read-only hint plus sibling names (e.g., add_marker) provide context. However, no explicit when-not-to-use or alternatives 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?

The description adds context beyond the readOnlyHint annotation, specifying the return is flattened with paths and supports paging. No contradiction.

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 purpose, no wasted words.

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?

Lacks output schema but adequately describes return (flattened list with paths) and mentions paging. Sufficient for a list tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with clear descriptions; the description summarizes parameters but does not add new meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists bins and clips from the Project panel tree, flattened with paths, distinguishing it from siblings like find_project_item or 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 implies use when you need a flat list of project items, but does not explicitly contrast with siblings like find_project_item or list_sequences.

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?

Annotations declare readOnlyHint=true. The description adds that it works offline and details the sources of project info, providing useful context beyond the annotation.

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, well-structured sentence that front-loads the main purpose and includes all necessary information without 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?

For a simple tool with one optional parameter and no output schema, the description covers purpose, behavior, and constraints (read-only, offline) completely.

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 well-described optional parameter; the description does not add further meaning, which is acceptable given 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 clearly states the action ('List'), the resource ('recently used / nearby Premiere projects'), and the method (registry and scanning), differentiating it from siblings like 'premiere_open_project' and 'premiere_list_autosaves'.

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 tool works without Premiere running, implying its use case, but does not explicitly contrast with alternatives or provide when-not-to-use 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?

Annotations already declare readOnlyHint=true, so the description's 'Read-only' is redundant. The description adds no additional behavioral details (e.g., what is returned, pagination, side effects). With annotations present, the bar is lower, but further context beyond safety would improve the score.

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 with no wasted words. The purpose, filtering, and cross-reference to premiere_create_sequence are front-loaded and clear.

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 simple read-only listing tool with 100% schema coverage and no output schema, the description is complete. It explains what presets are listed, optional filtering, and how the output path is used by another tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema fully documents both parameters (query and limit). The description adds no extra meaning beyond 'optionally filtered', so the baseline score of 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 explicitly states the tool lists .sqpreset sequence presets on disk, giving examples like HD 1080p, UHD, and Broadcast. This clearly distinguishes it from sibling tools like premiere_list_export_presets (for export presets) and premiere_create_sequence (which uses the path).

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 mentions optional filtering and advises passing the path to premiere_create_sequence for non-interactive setup, providing good context. However, it does not explicitly state when not to use this tool or offer exclusions, which would merit a 5.

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?

Annotations already provide readOnlyHint=true. The description reinforces 'Read-only' and adds specific output details (IDs, track counts, frame size, active), which goes beyond the annotation to inform the agent of what the tool returns.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences: first states the action and output, second confirms safety. No wasted words, fully front-loaded.

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 simple list tool with no parameters and no output schema, the description fully covers the purpose, output fields, and safety. The only prerequisite ('open project') is mentioned. 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?

With zero parameters and 100% schema coverage trivially, the baseline is 4. The description does not need to add param information, and it correctly implies no parameters are required.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it lists all sequences in the open project with specific returned fields (IDs, track counts, frame size, active). This distinguishes it from sibling tools like premiere_get_active_sequence (which returns only the active sequence) and premiere_list_project_items (which lists 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?

The description specifies the context 'in the open project,' indicating a prerequisite. It does not explicitly state when not to use it or name alternatives, but the context is clear enough for agent selection.

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?

Annotations already provide destructiveHint=false and openWorldHint=true. The description adds value by explaining the confirm and backup behavior on existing files, and the path constraint. This goes beyond what annotations convey, though it could mention post-creation 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?

Two sentences, each providing essential information: the core action and conditions. No redundant or verbose phrasing. The information is front-loaded and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers key aspects (creation, confirm, backup, path) but lacks details on post-creation behavior (e.g., whether project opens automatically) and error handling (e.g., what happens if path is not allowed). With no output schema, this gap somewhat hinders complete understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and both parameters are described. The description adds extra context: path must be inside an allowed working root and extension is added if missing. This augments the schema without contradicting it.

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 explicitly states the action: 'Create a new empty .prproj project at the given absolute path.' The verb 'create' and the resource '.prproj project' are specific, distinguishing it from siblings like 'premiere_open_project' (opens existing) and 'premiere_save_project' (saves current).

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 provides context for when to use (creating a new project) and conditions (path constraints, confirm on overwrite, backup). However, it does not explicitly compare to siblings or state when not to use it, leaving some ambiguity.

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 provided. Description discloses key behavior (no dialog, uses newSequence method, defaults). Does not cover error handling, permission needs, or side effects like overwriting existing sequence names. Adequate but not thorough.

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 purpose, no fluff. Every sentence adds essential information (silence, method, default, alternative use).

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?

Given tool simplicity (2 params, no output schema), description covers creation method, default, and parameter source. Lacks error/result info, but complete enough for straightforward usage.

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 covers 100% of parameters. Description adds value beyond schema: explains presetPath default (HD 1080p 25fps) and source (from sibling tool). Parameter semantics are clear and enriched.

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?

Description clearly states 'Create a new sequence WITHOUT any dialog, using a .sqpreset'—a specific verb and resource. It distinguishes from sibling tools like 'premiere_create_sequence' by emphasizing silence and automatic creation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says when to use: for silent, reliable sequence creation. Mentions default format and how to override with presetPath from 'premiere_list_sequence_presets'. Lacks explicit when-not-to-use or alternatives but provides clear usage context.

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?

Annotations provide openWorldHint=true, but description adds value by noting dialogs are suppressed and file must exist. For a simple open tool, this is sufficient behavioral insight beyond the annotation.

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 concise sentences convey all necessary information without waste. Every word 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?

Given the simplicity of the tool (single parameter, no output schema) and the presence of a clear annotation, the description fully covers what an agent needs to know: purpose, precondition, and behavioral quirk.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the schema description already fully defines the path parameter. The tool description does not add additional meaning beyond what the schema provides, so a baseline score of 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?

Description clearly states the action (open), resource (.prproj project), and tool (Premiere). It includes key details like dialog suppression and file existence requirement, distinguishing it from siblings like new_project or close_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?

The description provides preconditions (file must exist) and behavioral notes (dialogs suppressed), giving clear context for usage. While it doesn't explicitly list when not to use or alternatives, the purpose is straightforward and well-defined.

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 full burden. It discloses key behaviors: automatic file import, optional trimming, mode effects (overwrite vs ripple), and automatic audio routing. It omits error conditions, undo behavior, or prerequisites like project/sequence 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?

The description is two sentences, front-loaded with the core action, and free of fluff. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers purpose, parameters, and modes, but lacks information on return values (e.g., success/failure), error handling, or prerequisites (e.g., active project/sequence). For a 6-parameter tool with no output schema and no annotations, this is a noticeable 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 coverage is 100%, but the description adds value beyond the schema by explaining importing behavior for mediaPath, clarifying trim parameters with 'source in/out-point', and detailing mode effects. This adds meaningful 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 clearly states the action ('Place a media clip on a video track at a given time') using a specific verb and resource. It adds details about importing, trimming, and modes, distinguishing it from sibling tools like premiere_import_files.

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 the two modes (overwrite vs insert) and their effects, providing context for when to choose each. However, it does not explicitly state when not to use this tool or mention alternatives (e.g., using add_title for different clip types).

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?

Describes the graceful close mechanism (sending close signal, Premiere shows its own save prompt). Warns about data loss with force:true. Adds context beyond the destructiveHint annotation.

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 conveying purpose, behavior, and usage. No wasted words. Front-loaded with core action.

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?

Given no output schema and only two parameters, description fully covers what the tool does, its safety profile, and parameter requirements.

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?

Adds meaning to parameters beyond the schema: confirm must be true, force causes data loss. Schema already has 100% coverage, but description reinforces usage.

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?

Title and description clearly state the tool quits Premiere gracefully, distinguishing it from force quitting. The verb 'close' and resource 'Premiere' are specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use confirm:true and when to use force:true, including warnings about data loss. Differentiates from sibling tools like premiere_restart.

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?

Annotations already signal destructiveness, but the description adds the explicit 'Irreversible' qualifier and the confirm requirement, providing additional behavioral context beyond the annotation.

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 concise sentences, front-loaded with primary action, and no extraneous information. Every sentence provides necessary guidance.

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 simple destructive tool with two parameters, the description covers purpose, usage, requirements, limitations, and data source. No gaps given the annotations and input schema.

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%. The description repeats the schema definitions for nodeId and confirm without adding new meaning, so it meets but does not exceed 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 uses a specific verb ('Delete') and resource ('BIN'), and clarifies it cannot delete individual clips, distinguishing it from any hypothetical sibling remove/delete tools and setting correct expectations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states the tool is irreversible and requires confirm:true, directs users to premiere_list_project_items for nodeId, and warns that individual clips cannot be deleted via the stable DOM, guiding users away from misuse.

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?

Beyond the destructiveHint annotation, the description reveals graceful closing, a wait period, and the possibility of a save prompt during close. This additional behavioral context helps the agent anticipate user interaction.

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 that immediately convey the action and key requirements. No unnecessary words or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (no output schema, few parameters), the description covers the restart process, required confirm flag, optional project reopening, and potential save prompt. It is sufficient for an agent to understand and use the tool 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 50% (only projectPath described). The description adds that confirm must be true, partially compensating for the undocumented confirm parameter, but doesn't elaborate further on parameter values or constraints.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool restarts Premiere, specifying the sequence (close, wait, start again) and the optional project reopening. This is distinct from sibling tools like premiere_launch, premiere_quit, and premiere_open_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?

The description explicitly requires confirm:true, and notes the optional projectPath parameter. While it doesn't contrast with alternatives, the tool's specific restart function and the stated requirement provide clear guidance for correct invocation.

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?

The description goes beyond the destructiveHint annotation by explaining the dryRun feature and the necessity of confirm flag. It adds context about power and destructiveness. No contradiction with annotations.

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, front-loaded with the most critical information (escape hatch, power, return value). Every sentence earns its place; no wasted words.

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?

Even without an output schema, the description states the return format ('return its value as JSON'). Covers safety, execution control, and distinction from siblings. Fully adequate for a well-documented 4-param 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?

Input schema has 100% coverage with descriptions. The description reinforces the safety parameters (confirm, dryRun) by explaining their roles in execution. This adds value beyond the schema definitions.

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?

Clearly states it runs an arbitrary ExtendScript snippet and returns JSON. Distinguishes from dedicated tools by labeling itself an 'ESCAPE HATCH'. The verb 'run' and resource 'ExtendScript' are specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says to use when no dedicated tool exists ('Prefer the dedicated tools when one exists'). Requires confirm:true to execute and recommends dryRun:true for preview. Provides clear when-to-use and safety instructions.

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?

Description explains experimental, unsupported nature and instability/crash risk, going beyond the destructiveHint annotation to inform agent 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?

Three short sentences, front-loaded with 'EXPERIMENTAL', each sentence adding essential info without waste.

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?

Covers purpose, risks, and usage guidance; lacks return value description but acceptable for experimental tool with no output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline 3. Description restates 'requires confirm:true' but adds no new parameter meaning beyond schema 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?

Description clearly states it executes a Premiere menu command by numeric ID via the QE DOM, distinguishing from sibling tools by noting dedicated tools exist for common actions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly advises using dedicated tools when available, and requires confirm:true to proceed, providing clear when-to-use and when-not-to-use 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?

Annotations provide idempotentHint: true, and the description confirms in-place save. It adds minimal context beyond annotations, but no contradictions.

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 short sentence front-loading the key action and scope; every word is necessary.

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?

Tool is simple with no output schema or parameters. Description is complete and sufficient for agent 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?

No parameters exist, so schema description coverage is 100%. Baseline 4 applies; description adds no param info but is not needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Save', the resource 'currently open project', and the scope 'to its existing file (in place)'. It distinguishes from the sibling 'premiere_save_project_as' by specifying 'in place' vs. 'save as'.

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?

While no explicit when-not or alternatives are mentioned, the description implies usage for in-place saves, contrasting with 'save_project_as'. Given the simplicity, this is adequate.

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?

Annotations indicate non-destructive (destructiveHint: false). Description adds that existing targets are backed up and gated behind confirm, providing extra safety context. No mention of potential side effects like closing current project, but adequate for the 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 efficient sentences: first states purpose, second details conditions. No redundant words, all information earn 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?

With 2 parameters, no output schema, and annotations present, description covers key behaviors (backup, confirm gate, path constraint). Lacks explicit mention of return value, but sufficient for 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?

Input schema already covers both parameters with clear descriptions (path: absolute with .prproj append; confirm: required only if target exists). Description adds no further semantic detail beyond schema, earning baseline score.

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?

Description clearly states 'Save the open project to a new path,' specifying the verb (save), resource (project), and unique behavior (new path). Distinguished from siblings like 'premiere_save_project' which saves to current path, and 'premiere_backup_project' which is a different operation.

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?

Provides context on when confirm is needed and path constraints (inside allowed root). Does not explicitly contrast with alternative save tools or state when not to use this tool, though the sibling list implies differentiation.

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?

Annotations already indicate read-only and open-world. Description adds return format (inline image + file path) and scoping (window vs full screen), without contradiction.

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 efficient sentences capture purpose, usage scenario, and return value with zero waste.

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 simple screenshot tool with 2 params and no output schema, the description covers purpose, parameters (via schema), and return format adequately.

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 has 100% coverage with clear descriptions for both parameters. Description adds no extra meaning beyond 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?

Clearly states it captures a PNG screenshot of Premiere's main window or full screen, distinct from sibling tools that modify or analyze projects.

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?

Provides context: use when a tool reports unexpected results or a dialog may be open. though no explicit when-not-to-use or alternatives, it's effective for a unique tool.

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?

Discloses that it focuses Premiere (potentially disruptive) and uses Windows SendKeys syntax. The 'ADVANCED FALLBACK' label implies unreliability. The openWorldHint annotation aligns with possible side effects. Minor gap: no mention of synchronous/asynchronous behavior or delays.

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 'ADVANCED FALLBACK', include prerequisite, syntax, and guidance. Every sentence adds essential information without waste.

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 simple fallback tool with one parameter and no output schema, the description provides adequate context: when to use, prerequisites, syntax. Lacks error behavior or what happens if Premiere is not focused, but these are minor for a fallback.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds concrete syntax examples ('^s', '%{F4}', '{ESC}') that go beyond the generic schema description, helping the agent format the key string correctly.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool focuses Premiere and sends keystrokes, with specific syntax examples ('^s' for Ctrl+S). It distinguishes itself from siblings by labeling as 'ADVANCED FALLBACK' and advising use only when no dedicated tool exists.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states 'Use only when no dedicated tool exists' and includes prerequisite 'Premiere must be running.' This provides clear context for when to use this tool versus alternatives.

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

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

No annotations provided, so description carries full burden. Indicates it changes active sequence, but doesn't disclose failure modes (e.g., invalid ID, external sequence) or confirm if operation is reversible. Adequate for basic understanding but lacks depth.

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?

Single clear sentence with front-loaded purpose. No extraneous words; efficient and scannable.

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?

Adequate for a simple setter with one parameter. Does not detail return value or error handling, but with no output schema, this is acceptable. Could optionally list prerequisites (e.g., sequence must exist in project).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.