MCP Adobe Premiere Pro
Server Quality Checklist
Latest release: v1.2.0
- Disambiguation1/5
Numerous tools have overlapping or indistinguishable purposes: selection operations (select_all_clips, select_clips_in_range, select_disabled_clips, select_clips_by_color, select_clips_by_name, set_clip_selection), effect removal (remove_effect, remove_effect_by_name, remove_all_effects), sequence creation (create_sequence, create_sequence_from_preset, create_sequence_from_clips, duplicate_sequence, create_subsequence), and many get/list/query tools (get_sequence_settings, get_sequence_structure, get_full_sequence_info, get_timeline_summary, get_premiere_state, get_full_project_overview). This makes it very difficult for an agent to correctly pick the intended tool.
Naming Consistency2/5Naming is mostly snake_case but follows inconsistent conventions. Verbs vary between get/list/fetch, some tools are phrases without clear verbs (ripple_delete, match_frame, scene_edit_detection), others use idiosyncratic suffixes (set_clip_speed_qe, get_qe_clip_info), and there are both list_ and get_ prefixes for similar query actions (list_sequences vs get_sequence_count, list_project_items vs get_project_item_info). This creates an uneven and confusing pattern.
Tool Count1/5With 283 tools, the server is drastically over-scoped. Even for a complex application like Premiere Pro, this number indicates poor curation and redundancy, far exceeding the recommended range and the 50+ threshold for extreme mismatch. Many tools are overly granular or duplicated.
Completeness3/5The tool set covers a broad range of Premiere Pro operations including project, timeline, effects, markers, captions, export, and audio. However, there are notable gaps and explicit limitations: read_sequence_captions states it cannot actually read captions, and import_edl is unavailable. Some operations are detection-only (detect_silence, detect_scene_edits), requiring additional manual steps. While the surface is extensive, these dead ends prevent a fully complete workflow.
Average 2.8/5 across 283 of 283 tools scored. Lowest: 1.1/5.
See the Tool Scores section below for per-tool breakdowns.
- 31 of 31 community issues answered or closed in the last 6 months
- 48 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
This server has been verified by its author.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and no behavioral disclosure, the description provides zero insight into side effects, required permissions, or consequences. It simply names the operation without explaining its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but not genuinely concise; it includes filler ('Premiere Pro expanded operation') and omits essential information. It is under-specified rather than efficiently written.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, annotations, and parameter details, this description is completely inadequate. It provides no operational context and leaves the agent guessing about the tool's purpose and usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is essentially empty (no defined properties), and the description does not explain what parameters or arguments are expected. It adds no semantic meaning beyond the tool's name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Premiere Pro expanded operation: set source in out.' merely restates the tool name without defining what 'source in out' means or what the operation does. It fails to distinguish this from related siblings such as set_item_in_out or set_sequence_in_out_points.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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. The description does not mention any context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does not mention side effects, required permissions, reversibility, or what happens when the operation is invoked. The phrase 'expanded operation' is ambiguous and does not clarify whether this is a read or mutation action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than conciseness. It does not front-load essential information; it merely restates the tool name with a vague qualifier. A concise description should still convey key details, which this entirely lacks.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool likely requires domain-specific knowledge about custom properties in Premiere Pro, but the description provides none. There is no output schema or annotation to fill the gap. The description is inadequate for an agent to invoke this tool correctly or understand its role among 200+ sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema allows arbitrary properties but defines none, so schema description coverage is vacuous. Despite a baseline of 3 for high schema coverage, the description adds no meaning to the input parameters. It does not indicate what fields are expected (e.g., clip ID, property name/value), leaving the agent without guidance for constructing valid arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description merely restates the tool name ('attach custom property') without explaining what the operation does. It adds only the boilerplate phrase 'Premiere Pro expanded operation', which provides no concrete verb or resource distinction from the many sibling tools. It fails to establish a clear purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 versus alternatives. The description lacks any context about typical use cases, prerequisites, or exclusions. It offers no support for an agent to decide between attach_custom_property and similar tools like add_custom_metadata_field.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should explain side effects (e.g., does it copy/move files, modify the project, require a destination?). The phrase 'expanded operation' is jargon and provides no behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but is a near-tautology, offering no useful information. It is under-specified rather than concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's likely complexity (Premiere project management), the lack of annotations, output schema, and parameter guidance makes this description completely inadequate. An agent cannot determine how to use it safely or correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0 defined parameters but allows additionalProperties. The description does not clarify what arguments can be passed (e.g., destination path, transfer options). This open schema makes parameter usage ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Premiere Pro expanded operation: consolidate and transfer' merely restates the tool name without explaining what the operation does. It lacks a specific verb+resource structure and does not distinguish this from related tools like consolidate_duplicates or export_as_project.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as consolidate_duplicates or export_as_project. No use cases, prerequisites, 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.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. However, it reveals nothing about what the tool returns, side effects, or operational constraints, leaving the agent completely in the dark.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is structurally simple, but it is under-specified rather than concise. It lacks the essential information that a useful description must contain, so the brevity is a deficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, no helpful input schema, and a vague one-line description, the tool is completely inadequate for an agent to select or invoke correctly. It provides no context about return values, required inputs, or typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines no parameters (0 params), but the tool name implies a 'time' argument, and the schema oddly allows additional properties with no definitions. The description adds no clarification about whether arguments are needed or what they mean, failing to compensate for the ambiguous schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Premiere Pro expanded operation: get value at time' is a tautology, restating the tool name without explaining what value is retrieved, from what resource, or how time is specified. It does not distinguish this from dozens of sibling get_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, no prerequisites, and no context for when it is appropriate. The description is entirely missing usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full responsibility for behavioral disclosure. It offers zero information about whether the tool is a query or mutation, what 'has proxy' checks, which object is inspected, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but it is under-specified rather than concise. It contains no useful information beyond echoing the tool name, so the brevity is not a virtue.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and no parameters, the description should at least explain what object is checked and what the return value indicates. It is completely inadequate for an agent to select or invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0 parameters, which normally sets a baseline of 4. However, the description fails to even hint at the implicit input (e.g., currently selected clip or project item), adding no semantic context beyond an empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Premiere Pro expanded operation: has proxy.' merely restates the tool name without specifying a verb, resource, or outcome. It does not distinguish this tool from siblings like manage_proxies or detach_proxy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool, what it operates on, or how it differs from alternative proxy-related tools. There are no exclusions, prerequisites, or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description gives no behavioral information such as what the operation does beyond the title, side effects, required selection state, or impact on the item. It is effectively a restatement of the tool name, offering no transparency about the underlying action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is structurally concise, but it is so vague that the brevity is a liability. It fails to provide any useful details, so the sentence does not 'earn its place' as a meaningful explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a Premiere Pro operation with no annotations, no output schema, and an open-ended input schema, the description is severely incomplete. The agent has no information about required arguments, expected behavior, or how it differs from the dozens of sibling tools, making correct invocation nearly impossible.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is a generic object with no specific properties, and with zero named parameters the description must explain what input is expected. It does not mention any parameter names, types, or meanings (e.g., item ID, in/out times), leaving the agent with no information on how to invoke the operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'set item in out' which implies setting in/out points, but it fails to specify what 'item' refers to (e.g., project item, clip, source monitor). It does not distinguish from sibling tools like 'set_source_in_out' or 'clear_item_in_out', leaving the operation's exact purpose ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not mention prerequisites, typical use cases, or any exclusion criteria. The description alone offers no help in selecting this tool over related ones.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
This description carries the full burden of behavioral disclosure since no annotations are provided, but it discloses nothing about side effects, mutations, prerequisites, or whether it operates on the current selection. The phrase 'expanded operation' is vague and adds no concrete behavioral information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but it is under-specified rather than concise. It does not earn its place because it adds no information beyond the tool name. The result is a non-informative fragment.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a Premiere Pro operation with no annotations, no output schema, and a nominal parameter count of 0, this description is completely inadequate. It omits essential context about the operation's purpose, prerequisites, and effects, leaving the agent unable to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema has zero parameters, the description hints at 'scale width height' but fails to explain how these values are supplied (e.g., via UI selection, default values, or missing parameters). With 0 params, the description should confirm the tool is self-contained or clarify that it acts on existing state, but it does neither.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description "Premiere Pro expanded operation: set scale width height" is a tautology that merely restates the tool name without explaining what the tool actually does. It does not clarify whether it sets scale properties on a clip, sequence, or something else, nor does it distinguish this from sibling tools like set_clip_scale or set_scale_to_frame_size.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool or which alternatives exist. No mention of required selection or context, and no comparison to related tools such as set_uniform_scale. The agent is left without any basis to decide when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description must disclose behavioral traits like side effects, permissions, or return values. It offers nothing beyond the literal action, so the agent cannot anticipate consequences or requirements of executing an arbitrary ExtendScript.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief, but this is under-specification rather than efficient conciseness. It uses a single sentence that adds no substantive information beyond the name, failing to earn its place by conveying useful context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is an open-ended execution command with no annotations, no output schema, and an opaque parameter schema. The description provides none of the necessary context about what ExtendScript is, what it can do in Premiere Pro, or how the agent should invoke it, making it wholly inadequate for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is an open object with no defined properties, and the description does not explain what the object should contain. While the schema technically has 100% coverage (zero parameters), the tool clearly requires some input, and the description fails to clarify the expected structure or semantics of that input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Premiere Pro expanded operation: execute extendscript' is largely a restatement of the tool name. It identifies the domain (Premiere Pro) and the action (execute extendscript) but does not clarify what executing an ExtendScript script accomplishes or how it differs from the many specialized sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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. The description does not mention prerequisites, scenarios, or any exclusion criteria, leaving the agent without direction for selecting this tool among dozens of siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only says 'Premiere Pro expanded operation: inspect dom object.' It does not mention whether the operation is read-only, what side effects it might have, what it returns, or error behavior. This is a significant gap for a tool that likely manipulates internal state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, which is efficient, but it is under-specified rather than concise in a helpful way. The phrase 'Premiere Pro expanded operation' is boilerplate and the rest is too terse to earn its place; a single vague sentence is not sufficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotation, no output schema, and an ambiguous input schema, the description is entirely inadequate. It does not explain the concept of 'dom object', expected input/output, or how it fits into the broader Premiere Pro workflow. This leaves an AI agent without essential information to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is unusual: it declares an object with additionalProperties allowed and propertyNames constrained to strings, effectively accepting arbitrary key-value pairs. The description provides no explanation of what parameters are expected or how to structure them, so it does not compensate for the schema's lack of named properties or descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'inspect dom object', which gives a verb and resource but is vague: it doesn't clarify what 'dom object' refers to in Premiere Pro, what inspecting entails, or what the output is. It fails to distinguish from many sibling query tools like get_premiere_state or get_sequence_structure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 vs alternatives. There is no indication of prerequisites, typical scenarios, or exclusions. The description offers zero context for an agent to decide to call this over any other inspection tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention that the operation modifies a clip property, any side effects, permissions, or state requirements. It gives no indication of the operation's nature beyond the word 'set,' which is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but under-specified. It starts with a generic prefix ('Premiere Pro expanded operation') that adds no value, followed by a restatement of the tool name. It lacks the structural content needed to be useful, making it barely more than a placeholder.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations, output schema, and explicit parameters, the description needs to provide comprehensive usage context. It fails to explain what 'pan' means, what the operation does, what inputs are required, or how it fits with existing clip property setters, making it severely incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is permissive (allows any properties) and defines no explicit parameters, while the context signal reports 0 parameters. The description does not mention the needed 'pan' value, its type, range, or unit. Thus, an agent cannot infer what arguments to pass when invoking this tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is 'Premiere Pro expanded operation: set clip pan.' This essentially restates the tool name without clarifying what 'pan' refers to (audio pan, spatial pan, etc.). It does not distinguish from sibling tools like set_clip_position or set_clip_volume, so it fails to clearly define the tool's unique purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 versus alternatives. It omits context such as prerequisites (e.g., selected clip), alternatives, or scenarios where this operation is appropriate, leaving the agent without any basis for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavior. It does not state whether this operation is mutating, what side effects it has, or any required permissions. 'Expanded operation' is meaningless fluff and adds no transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, but the phrase 'Premiere Pro expanded operation' is filler that does not earn its place. True conciseness should pack useful information into few words; this under-specifies the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the empty schema, missing annotations, and no output schema, the description must compensate with rich context. It fails to explain the purpose, parameters, or effect, leaving the tool functionally unusable for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines no explicit parameters (only permissive additionalProperties), and the description adds no parameter information. An agent cannot determine what arguments to pass, such as a workspace name, making the tool nearly impossible to invoke correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'set workspace' essentially restates the tool name without adding scope or detail. While it specifies a verb and resource, it does not clarify what setting a workspace entails or how it differs from related tools like get_workspaces.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description does not mention prerequisites, typical scenarios, or exclusions, leaving the agent to guess.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of disclosing behavior. It does not mention effects, side effects, permissions, or expected outcomes. The phrase 'expanded operation' is generic and uninformative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
While extremely short, this is under-specification rather than concise utility. The single phrase 'Premiere Pro expanded operation: capture frame' restates the tool name and does not earn its place by adding information. Concise is not the same as sparse to the point of uselessness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, no annotations, and the description does not describe the tool's purpose, behavior, or selection criteria. Given the large number of sibling tools performing similar actions, this description is inadequate for an agent to understand or invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the input schema is empty, so per the rubric the baseline is 4. The description adds no parameter details, but since there are none to document, this score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Premiere Pro expanded operation: capture frame' is essentially a tautology—it restates the tool name without specifying what capturing a frame entails or how it differs from sibling tools like export_frame, freeze_frame, or set_poster_frame. No verb+resource clarity is provided beyond the name itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description offers no context, prerequisites, or exclusions, leaving the agent to guess the appropriate selection scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It fails to mention side effects, return values, permissions, or any operational details, leaving the agent entirely in the dark.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence, but it is under-specified rather than concise. It merely rephrases the tool name and provides no informative content, so it does not earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool lacks an output schema and annotations, and the description is a single tautological phrase. For a tool that likely handles arbitrary expressions, there is no information about inputs, outputs, or behavior, making it completely inadequate for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines 0 parameters, and the description adds no parameter detail, but the baseline for 0 params is 4. However, the schema allows arbitrary properties (propertyNames/additionalProperties), and the description does not clarify whether any arguments are expected or how to pass an expression, which is a slight gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Premiere Pro expanded operation: evaluate expression' is essentially a tautology, restating the tool name without explaining what the expression evaluation does, what types of expressions are supported, or the outcome. It does not distinguish this tool from similar siblings like execute_extendscript or inspect_dom_object.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 or when to prefer an alternative. There is no mention of context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It states nothing about what 'qe' means, whether the operation is read-only, what information is returned, or any side effects. The description offers no behavioral context whatsoever.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but this is under-specification rather than conciseness. The single sentence merely repeats the tool name and does not earn its place by adding any useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and many sibling tools with similar names, this description is severely incomplete. An agent would be unable to determine what a 'qe clip' is, what info is returned, or how this differs from other clip-info tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The schema defines no actual properties, and the description does not need to explain parameter meanings. The absence of parameters makes this dimension irrelevant.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is a tautology, restating the tool name 'get qe clip info' without adding a specific verb or clarifying what a 'qe clip' is. It does not distinguish this tool from numerous siblings like get_clip_info, get_full_clip_info, get_item_info, or get_clip_properties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 versus alternatives. The phrase 'expanded operation' is vague and provides no context for choosing this tool over similar clip-info retrieval tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it offers none. It does not state whether the tool modifies the timeline, whether it is a safe read-only operation, or what the outcome of invoking 'redo' would be. The description is completely uninformative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than efficient conciseness. A single sentence that merely restates the tool name does not earn its place; it omits essential information. It is not appropriately sized because it fails to convey any usable meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the absence of annotations, output schema, and parameters, the description still fails to be complete. It does not clarify the tool's purpose, its relationship to undo, or any behavioral details. The description is as minimal as possible but entirely inadequate for an agent to understand or invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the schema is permissive with additionalProperties allowed. Since there are no defined parameters, the description's lack of parameter details is not a significant gap. The baseline for 0 parameters is 4, and neither the description nor schema introduces ambiguity that would lower it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Premiere Pro expanded operation: redo' is a tautology—it merely restates the tool name 'redo' without explaining what the operation does. There is no specification of the action, resource, or effect beyond the name itself, making it impossible to distinguish from a generic concept.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no context for when to use this tool. It does not mention 'undo' or 'multiple_undo' as alternatives, nor does it explain that 'redo' typically reverses a previous undo. There is no guidance on appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it discloses nothing: no mention of what happens when scene edits are detected (e.g., markers created, information returned), whether it requires an active sequence, or any side effects. The phrase 'expanded operation' is meaningless without elaboration, making the tool's behavior opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but its brevity stems from under-specification rather than concise, informative writing. It reads as a fragment that fails to explain the operation, similar to the 'Process' calibration example. The word 'expanded' adds noise without substance, so it does not earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex operation like scene edit detection, the description is severely inadequate. There is no output schema, no annotations, and no details on what the tool returns, how it integrates with other tools, or how it relates to the sibling 'detect_scene_edits.' The description leaves out essential behavioral context, making it nearly impossible 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.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so per rubric the baseline is 4. The description adds no parameter information, and none is needed since the schema is empty. However, it could have clarified what the operation implicitly targets (e.g., active sequence), but this omission is not significant enough to drop below the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description merely restates the tool name with the phrase 'scene edit detection' and adds the vague qualifier 'expanded operation,' providing no specific verb or resource. It also fails to distinguish itself from the similarly named sibling tool 'detect_scene_edits,' leaving ambiguity about whether these are the same or different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives such as 'detect_scene_edits' or 'detect_silence.' No context, prerequisites, or exclusion conditions are provided, leaving the agent completely in the dark about appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description discloses no behavioral traits. It does not state whether the operation is destructive, what it affects, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief, but this brevity is due to under-specification rather than conciseness. It lacks any explanatory structure or details that would help an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and no parameter documentation, the description is insufficient for a tool that clearly needs to set some property of a clip. It does not explain what 'start time' refers to or what context the tool operates in.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema has no property definitions. Per the rubric, a baseline of 4 is appropriate since there are no parameters that need explanation in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Premiere Pro expanded operation: set clip start time' is essentially a restatement of the tool name. It does not clarify what 'clip start time' means or how it differs from similar tools like set_start_time or set_clip_position.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not mention any prerequisite conditions, selection requirements, or contextual scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior, but it reveals nothing: no target object, no potential side effects, no scope, and no dependencies. 'Set color value' is a vague mutation with no context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but not appropriately informative; the phrase 'expanded operation' is filler and the sentence restates the name. It is under-specification, not effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a generic name, this description is completely inadequate. An agent cannot determine what 'color value' refers to, what inputs are expected, or what the tool returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines no properties and there are no required parameters, so there are no parameters to document. Per the rubric, a baseline of 4 applies for zero parameters. The description adds no parameter information, but there is no schema gap to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description simply repeats the tool name ('set color value') and adds the generic prefix 'Premiere Pro expanded operation,' which provides no specific information about what resource is affected or what action is taken. It does not distinguish this tool from siblings like set_color_label, color_correct, or set_effect_property.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool vs alternatives such as color_correct, apply_lut, or set_effect_property. It does not state any context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description carries the full burden of behavioral disclosure. It does not state what resources are affected, whether the operation is destructive or reversible, or any side effects. The phrase 'expanded operation' is undefined and unhelpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only one sentence, but it contains zero informative content. It is short for the sake of being short, not concise in a meaningful way. A concise description should pack information efficiently; this one simply wastes the one sentence it uses.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and an empty parameter schema, the description is the only source of context. It fails to explain the operation's effect, prerequisites, or relationship to sibling tools. This is completely inadequate for an agent to select and invoke the tool with confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines zero parameters, so the baseline for this dimension is 4. The description adds no parameter information, but since there are no schema parameters to clarify, the score remains at baseline. It would have been useful to mention implicit inputs like the current clip selection, but that is more of a purpose/usage concern.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Premiere Pro expanded operation: set frame blend' is a pure tautology that restates the tool name with a generic prefix. It does not explain what frame blending is, what it does to the clip, or how it differs from sibling tools like set_time_interpolation or set_blend_mode.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no usage guidance whatsoever. The description does not indicate when to use this tool, what conditions are required, or which alternatives might be preferred. With many similar sibling tools, this absence of direction makes the tool very difficult to use correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It provides zero information about what the operation changes, whether it modifies clips, selection requirements, or side effects. The description is effectively empty of behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but under-specified. It is a single sentence, but it does not earn its place because it provides no meaningful information. This is not concise writing; it is a placeholder.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the lack of annotations, output schema, and meaningful description, the entire context is missing. The agent cannot infer what slide_edit does, what inputs it expects, or what effects it has on the timeline.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so the baseline is 4. There is no parameter information needed, and the description does not need to explain parameters beyond what the schema already indicates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Premiere Pro expanded operation: slide edit' merely restates the tool name without defining what a slide edit does. It provides no verb or resource beyond the name itself, and fails to distinguish from sibling tools like roll_edit or slip_edit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 or how it differs from alternatives. With many similar timeline editing tools (roll_edit, slip_edit, ripple_delete), the description offers no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states only 'encode file' with no mention of side effects, duration, output handling, or whether the operation is read-only or destructive. This is a significant transparency gap for what is likely a heavy operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence but is severely under-specified. 'Premiere Pro expanded operation' is filler, and 'encode file' repeats the tool name. It does not earn its place since it provides no useful information, embodying under-specification rather than concise clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's likely complexity (encoding involves input source, encoding settings, output destination, and potential for long execution), the description is wholly inadequate. With no annotations, no output schema, and an open input schema, the agent has no basis for understanding what this tool does or how to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although there are 0 defined parameters and schema coverage is trivially 100%, the schema allows additionalProperties (any property), implying an undocumented parameter space. The description gives no hint about what properties are accepted (e.g., file path, codec settings) or whether the tool relies on context (like selected items). The baseline of 4 for 0 params is not met because the open schema creates ambiguity that the description fails to resolve.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Premiere Pro expanded operation: encode file' essentially restates the tool name without explaining what the expanded operation does or how it differs from sibling tools like start_batch_encode or encode_project_item. It is a tautology with a vague qualifier, providing no specific verb-resource clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use encode_file versus other encoding/exporting tools in the sibling list. The description offers no context, prerequisites, or exclusions, leaving the agent without any usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description gives no behavioral details. It does not state whether the operation is read-only, what it returns, how it handles missing effect properties, or any side effects. The vague claim of being an 'expanded operation' is unsubstantiated and offers no actional transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
Although the description is short, its brevity is not a positive because it adds no value beyond the tool name. The sentence is a tautology wrapped in 'Premiere Pro expanded operation'. It is under-specified, not concise in a meaningful way.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations, output schema, and meaningful parameter definitions, the tool needs a thorough description to be usable. One vague sentence is wholly insufficient for an agent to select, invoke, and interpret the results of this tool. The description is inadequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero explicit parameters but allows arbitrary additional properties, which is unusual. The description does not clarify what properties are expected (e.g., effect name, clip path, time) or how the tool identifies the target effect. Even with zero formal params, the agent needs guidance on how to specify the operation context, which is entirely absent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Premiere Pro expanded operation: get effect properties' essentially restates the tool name without adding a clear verb or resource. It does not explain what the tool does with effect properties (e.g., retrieves values, lists available properties, etc.) nor how it relates to siblings like list_clip_effects or get_value_at_time. The phrase 'expanded operation' is vague and provides no functional clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as set_effect_property or list_clip_effects. The description does not specify a context, prerequisites, or typical workflow. It fails to distinguish the intended use case, leaving the agent without decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits, but it does not. It fails to mention whether the operation modifies the timeline, requires a selection, is destructive, or how it interacts with adjacent clips. The description is completely opaque about the tool's effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but it contains no substantive information. It is under-specified rather than concise; every word essentially repeats the tool name. A minimal description should still convey the operation's purpose, and this one does not.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and no parameter context, the description carries the full burden of explaining the tool. It completely fails to describe what 'roll edit' does, how it behaves, or what the user should expect. This is inadequate for even a zero-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so the baseline score is 4 per the rubric. The schema already indicates no inputs, and the description does not need to describe parameters. The vague 'expanded operation' does not contribute meaningful parameter semantics, but this is not a gap given the absence of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Premiere Pro expanded operation: roll edit' is essentially a restatement of the tool name. It does not explain what a roll edit does (e.g., adjusting an edit point between two clips while preserving total duration), nor does it use a specific verb+resource structure. It also fails to distinguish itself from sibling tools like slide_edit or slip_edit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 versus alternatives. There is no mention of prerequisites, selection requirements, or scenarios where a roll edit is appropriate. Sibling tools with similar operations (e.g., slide_edit, slip_edit) are not referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It fails to mention whether the operation mutates clip state, what side effects occur, or any constraints. It is purely a name repetition.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but under-specified. It is not concisely informative; it omits essential details, making it closer to a placeholder than a concise summary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the ambiguity of 'clip position' and the lack of schema or annotation support, this description is completely inadequate for an agent to understand what the tool does or how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines no actual parameters, and the description adds no parameter information. The tool name implies a position value is needed, but neither schema nor description clarifies expected properties (e.g., x, y, time).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'set clip position' essentially restates the tool name without specifying what 'position' means (timeline time vs. spatial x/y). It does not differentiate from siblings like set_clip_start_time or move_clip.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as move_clip or set_clip_start_time. The description does not mention any prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing side effects or requirements. It does nothing beyond stating the operation, offering no insight into how it modifies the sequence, whether the sequence must be active, or if the operation is destructive or reversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is under-specified rather than concise. It is a single sentence that merely repeats the tool name and provides no informative content, failing to use the available space to add value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and zero parameters, the description must explain the tool's effect and prerequisites. It is completely inadequate, consisting only of the tool's name in sentence form, and leaves the agent with no understanding of the operation's context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines no named parameters and the parameter count is zero. The description adds no clarification about what value is set or how the target sequence is identified, leaving the agent without essential semantics despite the baseline 4 for zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a restatement of the tool name: 'set sequence pixel aspect ratio.' It adds the prefix 'Premiere Pro expanded operation' but does not explain what pixel aspect ratio affects or distinguish this from the sibling tool 'set_override_pixel_aspect_ratio.' This is a tautology that only clarifies the domain, not the specific behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool, prerequisites, or alternatives. It is a bare command with no context for when it should be invoked, and it does not mention any required state such as an active sequence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavioral traits. It fails to mention any side effects, requirements, or operational details such as what adding tracks entails or what happens to existing tracks.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but the brevity is under-specification rather than conciseness. The phrase 'expanded operation' is filler, and the core statement merely echoes the tool name without informing the user.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of a sibling tool 'add_track', the description is completely insufficient to distinguish 'add_tracks' or explain its functionality. No output schema exists, and the description provides no operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters in the schema, so there are no parameter details to describe. The baseline of 4 applies because the description does not need to compensate for missing parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description restates the tool name ('add tracks') without adding specificity. It does not explain what type of tracks are added, how it differs from the sibling 'add_track', or what 'expanded operation' means. This is essentially a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 'add_track'. There are no usage scenarios, prerequisites, or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral burden. It fails to disclose that this operation writes a project file, any side effects, output location, or cancellation behavior. The word 'export' only implies a write operation without specifics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but under-specified. It is a near-verbatim restatement of the tool name and the phrase 'expanded operation' adds no meaningful information, so it fails as concise specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex export operation with no annotations and no output schema, yet the description explains nothing about the result, input requirements, or relationship to sibling export tools. It is completely inadequate for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero defined parameters and the schema coverage is high, so there is little for the description to add. The baseline of 4 applies because no parameter explanation is necessary, though 'expanded operation' hints at potential hidden options without documenting them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'export as project' merely restates the tool name and adds the vague phrase 'expanded operation.' It does not specify the export format, scope, or how it differs from sibling tools like export_as_fcp_xml, export_omf, or export_sequence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description provides no context, prerequisites, or exclusionary criteria, leaving the agent without direction for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not state side effects (e.g., ripple edit, deletion, irreversibility), safety requirements, or behavior beyond the name. The phrase 'extract selection' is ambiguous.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, but it is under-specified rather than concise. It provides no meaningful information beyond the tool name, so it does not earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of schema details, annotations, and output schema, the description is severely incomplete. It does not explain what the operation does, how it interacts with the timeline, or its relationship to similar tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines zero parameters, and the description adds nothing about parameters. Since there are no parameters to explain, the baseline of 4 is appropriate per the rubric.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Premiere Pro expanded operation: extract selection' essentially restates the tool name without explaining what 'extract' does mechanically (e.g., removing selected clips and rippling the gap). It fails to distinguish this from similar sibling tools like lift_selection or remove_selected_clips.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description does not mention typical use cases, prerequisites, or contrasts with related selection/removal operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it says nothing about side effects, whether it mutates the timeline, creates clips, or requires a specific playhead position. The operation is entirely opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than conciseness. It spends words on 'Premiere Pro expanded operation' which adds no value, and the core phrase is a tautology of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and any meaningful parameter schema, the description is the sole source of context. It provides almost none, making the tool impossible to use correctly without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero defined parameters, so the description is not required to compensate for schema gaps. The baseline for 0 params is 4, and the description does not contradict this, though it adds no parameter-level insight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Premiere Pro expanded operation: freeze frame' merely restates the tool name with generic context. It fails to explain what freezing a frame involves or what the operation does, and does not distinguish it from similar tools like capture_frame or set_poster_frame.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, what prerequisites exist, or how it differs from alternatives. The description offers no contextual cues for an agent to decide when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior, but it is completely silent on what the tool returns, whether it performs any side effects, which clips it operates on, or any errors that may occur. 'Get full clip info' gives no behavioral detail beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence but is under-specified and tautological. It conveys no actionable information, so it fails to earn its place as a useful description despite being short.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool likely returns complex clip data, yet there is no output schema, no annotations, and no description of return values or behavior. The description is fundamentally inadequate for an agent to understand what information is returned or how to interpret it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter list to describe. The schema is open and uninformative, but since no parameters are expected, the description does not need to elaborate. The baseline for 0 params is 4, and no deduction is made.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description essentially restates the tool name: 'get full clip info' adds no new specificity beyond the name itself. The phrase 'Premiere Pro expanded operation' does not clarify what qualifies as 'expanded' or what differentiates this from sibling tools like get_clip_properties or get_item_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. There is no mention of prerequisites, selection requirements, or scenarios where this tool is preferred, making it impossible for an agent to decide when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose whether this is a read-only operation, what the return value is, or any side effects. The phrase 'expanded operation' is meaningless and adds no behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification, not conciseness. The single sentence provides no value beyond restating the tool name, so it does not earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a getter tool with no output schema and no annotations, the description should at least hint at the return type or purpose. It is completely inadequate, leaving the agent to guess what 'insertion bin' means and what data will be returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema has nothing to explain. Per the rubric, a baseline of 4 is appropriate since there is no missing parameter information. The description adds nothing about parameters, but no parameters exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description repeats the tool name ('get insertion bin') with the generic qualifier 'expanded operation,' providing no additional context about what an insertion bin is or what the tool returns. It fails to distinguish itself from sibling tools like get_source_monitor_info or get_bin_contents. The intended resource is ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is zero guidance on when to use this tool versus alternatives. No mention of prerequisites, context, or exclusions. Given the large sibling list, this absence is critical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden of disclosing behavioral traits. It says nothing about return format, side effects, prerequisites, or any operational details. 'Get item info' is a tautology and provides zero transparency beyond what the name already implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but it is under-specification rather than conciseness. The single phrase 'Premiere Pro expanded operation: get item info' is redundant with the tool name and does not earn its place by adding useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's generic name and the absence of output schema, annotations, and any substantive description, the information is completely inadequate for an agent to determine what this tool does, when to use it, or what it returns. The sibling list is large, and no distinguishing details are provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, and the context confirms zero parameters. With 0 parameters, a baseline of 4 is appropriate because there is no parameter information to explain. The description does not add anything, but there is no gap to fill.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a restatement of the tool name: 'Premiere Pro expanded operation: get item info.' It gives no specific verb or resource definition beyond the name itself, and it fails to distinguish this tool from numerous sibling tools like get_project_item_info, get_track_info, or get_qe_clip_info. The meaning of 'item' is left entirely unspecified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. With over 150 sibling tools, especially many other 'get_*' operations, the lack of any context, exclusions, or alternative references leaves the agent without a basis for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden of explaining behavior. It does not disclose what 'expanded' means, whether it is a read operation with side effects, or what the return structure is.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but lacks substance. It is under-specified, offering only a rephrased tool name rather than informative content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, this description is grossly insufficient. It gives no context about the return value, use cases, or differentiation from sibling tools, making it inadequate for an AI agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no defined parameters (additionalProperties allows arbitrary keys). With 0 parameters, the baseline is 4, and the description does not need to explain parameter semantics. However, it also fails to clarify the accepted input shape if any.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description merely restates the tool name ('get linked items') with the generic prefix 'Premiere Pro expanded operation,' adding no specific action scope or detail. It fails to clarify what 'linked items' refers to or distinguish it from similar tools like get_clip_links, making it essentially tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not indicate when to use this tool over alternatives such as get_clip_links or get_item_info, nor any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits. It does not state whether this is a read-only operation, what it returns, whether it requires a specific app state, or any side effects. 'get' implies a read, but that is not made explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence), but it is under-specified rather than concise. It offers no meaningful information, so the sentence does not earn its place. It is not as minimal as a single tautological word, but it is close to that.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and a lack of explanation about the operation's purpose, return value, or expected behavior, this description is completely inadequate for an agent to properly select and invoke the tool. The tool name suggests it retrieves a component of a motion graphics template, but nothing in the description confirms that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero defined parameters, so the description is not expected to explain any. Since there are 0 parameters, the baseline is 4 per the rubric. However, the schema's 'additionalProperties' allows arbitrary inputs, which is potentially confusing, but the description adds no misleading parameter information either.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Premiere Pro expanded operation: get mogrt component' essentially restates the tool name with a vague 'expanded operation' prefix. It does not define what a 'mogrt component' is or what the tool does with it, and it does not distinguish this from sibling tools like import_mogrt or get_project_item_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is absolutely no guidance about when to use this tool versus alternatives. It does not state prerequisites, typical use cases, or exclusions, leaving the agent without any context for selecting it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits. It does not state whether the operation is read-only, what it returns, whether it affects the state of Premiere Pro, or any side effects. This is a significant gap for any tool, and 'expanded operation' is purely opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification, not conciseness. The phrase 'Premiere Pro expanded operation' is filler that adds no information. A helpful description would be compact but still convey purpose, behavior, and usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool, a one-sentence description could suffice if it were informative. However, this description omits entirely what the returned position means, whether it is relative to the source monitor playhead, and how it relates to other source-monitor operations. Without an output schema or return-value documentation, the agent has no way to use the result correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to explain parameter syntax or semantics. The schema already confirms no required parameters. However, the description adds no value even here; the baseline of 4 is justified because there is nothing to compensate for, but the tool's parameter behavior is not explicitly clarified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Premiere Pro expanded operation: get source monitor position' is essentially a restatement of the tool name. It doesn't explain what 'position' refers to (e.g., playhead, cursor, window position) and fails to distinguish this tool from siblings like 'get_source_monitor_info'. The phrase 'expanded operation' is vague and adds no clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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. There is no mention of prerequisites, typical use cases, or when to prefer other source-monitor tools. The description gives the agent no context for selecting this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description gives no behavioral detail beyond the operation name. It does not disclose what data is returned, whether it is read-only, or any side effects. With no annotations available, this leaves the agent entirely without transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but this is under-specification rather than effective conciseness. It simply restates the tool name with no additional context, failing to earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a getter with no parameters, but the description still fails to explain what target tracks are or what the return value represents. Given the rich context of sibling tools, this description is completely inadequate for an agent to understand the tool's role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is fully descriptive for that, so the description is not required to add parameter details. The baseline of 4 for 0 parameters applies, even though the description itself adds no parameter-related meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Premiere Pro expanded operation: get target tracks' is essentially a restatement of the tool name. It lacks a specific verb and resource that clarifies the operation's function, and does not distinguish it from sibling tools like set_target_track or get_track_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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. There is no mention of prerequisites, typical scenarios, or distinctions from similar sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses nothing: no side effects, return format, safety profile, or edge cases. Even for a read-only operation, the agent has no idea what a 'gap' means or what data will be returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification, not effective conciseness. It wastes its single sentence by restating the name rather than providing substance. A good description should front-load meaning; this one offers none.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, annotations, and any meaningful description, the tool is completely under-specified. The agent cannot infer what data is returned, what conditions define timeline gaps, or how this tool relates to siblings like get_timeline_summary. This is a severe completeness gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 formal parameters, and the schema allows arbitrary additional properties but defines none. Per the rubric, a baseline of 4 applies when there are no parameters, since the description does not need to explain parameter details. No additional parameter semantics are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Premiere Pro expanded operation: get timeline gaps' merely restates the tool's name with an unhelpful 'expanded operation' prefix. It does not define what timeline gaps are, what the tool returns, or how it differs from numerous other 'get' tools like get_timeline_summary or get_sequence_structure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 versus alternatives. There is no mention of prerequisites, expected context, or scenarios where timeline gaps are relevant. It is a complete absence of usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does not describe return value, whether the operation is read-only, side effects, or what 'report' contains. The phrase 'expanded operation' is meaningless filler.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but the content is largely a restatement of the tool name, with 'expanded operation' adding no value. This is under-specification rather than effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a large set of sibling tools, the description is woefully incomplete. It does not explain the report's contents, purpose, or how it differs from related media-reporting tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description is not required to explain parameter behavior. The baseline of 4 applies because no parameter semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'get used media report' essentially restates the tool name with the vague prefix 'Premiere Pro expanded operation'. It identifies the action and resource but provides no scope or differentiation from siblings like get_unused_media and get_duplicate_media.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool, what problem it solves, or how it relates to alternatives. The description is purely nominal and offers no context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it reveals nothing about side effects, prerequisites, or what 'match frame' does in Premiere Pro. There is no mention of timeline effects, selection requirements, or output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. The single sentence 'Premiere Pro expanded operation: match frame' contains no substantive content and fails to provide useful information that would earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and no parameter details, the description must explain the tool's purpose and behavior. It does not. It is completely inadequate even for a simple operation, leaving the agent with only the name 'match_frame' to infer meaning.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is essentially empty. Per the rubric, a baseline of 4 applies since there is no parameter information to compensate for. The description does not conflict with the schema, and no additional parameter semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Premiere Pro expanded operation: match frame' names the operation but does not explain what it does. 'Expanded operation' is vague, and there's no specific verb or resource that distinguishes it from sibling tools like capture_frame or set_poster_frame. It borders on tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 or when to prefer alternatives. It merely states the name and a generic phrase, offering no context for selection among the many timeline and frame-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior, but it fails to state what nesting actually does—such as creating a new sequence, replacing clips with a nested sequence, or affecting the timeline. This is a mutating operation with no stated side effects, prerequisites, or reversibility information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but not concisely informative—it is under-specified. A single sentence that merely restates the tool name provides no real value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Nesting clips is a complex Premiere Pro operation with meaningful effects on the timeline and sequence structure, yet the description provides no context about its function, prerequisites, or consequences. There is no output schema, and the tool name alone is insufficient for an agent to understand when or how to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema confirms this with no defined properties. Since no parameters exist, the description need not explain parameter semantics, and the baseline score of 4 applies per the rubric.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Premiere Pro expanded operation: nest clips' is essentially a tautology of the tool name, providing no elaboration on what nesting involves. It does not distinguish this operation from related sibling tools like unnest_sequence or create_sequence_from_clips, making it unclear for an AI agent to know when this specific operation is appropriate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is zero guidance on when to use this tool versus alternatives, no prerequisites (e.g., clips must be selected), and no mention of how it differs from similar sequence-creation tools. The description offers no contextual usage information whatsoever.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits, but it says nothing about safety, side effects, return values, or any operational characteristics. The tool's actual behavior is completely opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. It consists of a single vague phrase that fails to inform, so it does not earn high marks for structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is completely inadequate for even a simple tool. There are no annotations, no output schema, and the description provides no explanation of the tool's purpose, behavior, or expected results, making the tool unusable without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description does not need to explain parameter meaning, and no parameter details are required for this tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Premiere Pro expanded operation: ping' restates the tool name with a vague prefix. It does not specify what the tool does (e.g., checks connectivity) nor distinguish it from similar siblings like verify_premiere_connection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use ping versus alternatives. The description offers no context, prerequisites, or exclusions, leaving the agent without any clue about the appropriate invocation scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must fully disclose behavioral traits. It does not mention that this is a destructive operation, that it works on selected clips, or that it closes gaps. The phrase 'expanded operation' reveals nothing about side effects, prerequisites, or reversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but under-specified. It contains only filler ('Premiere Pro expanded operation') that adds no meaningful information, and the rest simply repeats the tool name. It does not earn its place because it fails to convey any actual operational detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero annotations, no output schema, and a sparse description, the tool is completely underdescribed. It fails to explain what ripple delete does, how it interacts with the current selection, or what the expected result is. This is a serious gap for a destructive editing operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to elaborate on parameter semantics. The schema is permissive but context confirms no required parameters. A score of 4 reflects the baseline for no-parameter tools, though the description could still note that no arguments are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Premiere Pro expanded operation: ripple delete' is essentially a tautology that restates the tool name without explaining what the operation does or what resource it acts on. It does not specify that it deletes selected clips and closes the gap, nor does it distinguish from sibling tools like lift_selection or extract_selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use ripple_delete versus alternatives. With many closely related sibling tools (remove_selected_clips, lift_selection, extract_selection), the absence of any usage context makes it impossible to know when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it reveals nothing about side effects, selection semantics, or dependencies. The phrase 'select item' adds no transparency beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is under-specified rather than concisely informative. It is a fragment that does not form a complete sentence and provides minimal useful content, failing the purpose of a description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and an extremely vague description, this tool is critically underdocumented. The presence of many selection-related sibling tools makes a clear explanation of selection behavior essential, and its absence is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are 0 parameters, and the schema coverage is effectively 100% because none exist. The description adds no parameter meaning, but with no parameters to document, the baseline of 4 is appropriate. However, it could have clarified what the selection operates on, which it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Premiere Pro expanded operation: select item.' merely restates the tool name without specifying what kind of item, in what context, or how selection works. It is a tautology that does not distinguish from sibling selection tools like select_all_clips or set_clip_selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It lacks any context about selection scenarios, prerequisites, or exclusions, so an agent has no basis for choosing it over related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that the tool sets clip rotation, without revealing side effects, required permissions, units, coordinate systems, or whether it affects selected clips.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise in length but the only sentence is boilerplate ('Premiere Pro expanded operation') followed by a tautology. It does not earn its place and is not front-loaded with useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is highly inadequate for a tool with no annotations, no output schema, and only a generic empty input schema. It fails to explain what 'rotation' means, how the value is determined, or what happens when invoked, making it impossible for an agent to use correctly without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema declares zero parameters (schema coverage 100% vacuously), so there are no parameter details to document. Per rubric, a tool with 0 parameters gets a baseline of 4, though the description adds no additional context about how rotation is specified (e.g., via selection or default angle).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Premiere Pro expanded operation: set clip rotation' is essentially a restatement of the tool name with spaces. It identifies the verb and resource but provides no additional scope or differentiation from sibling tools like set_clip_scale or set_clip_position.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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. The description does not mention any prerequisites, selection requirements, or exclusions, and does not reference sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states only that something is 'set offline' without explaining side effects, reversibility, whether it acts on selected items, or any other behavioral implications. This is severely under-disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is short, it is under-specified rather than concise. The single sentence adds no operational or contextual value, and it does not earn its place in the description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no defined parameters and no output schema, the description must at least clarify the target of the operation (e.g., selected clips, project items). It fails to do so, leaving the tool's behavior entirely ambiguous and contextually incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines no properties (parameter count 0), so the description is not responsible for documenting parameters. According to the baseline for zero-parameter tools, this dimension is adequately handled by the schema itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Premiere Pro expanded operation: set offline' largely restates the tool name and does not specify what object is being set offline (clips, project items, media) or the resulting behavior. It fails to distinguish the tool from related siblings like check_offline_media or get_offline_media.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives, nor are prerequisites or the required context (e.g., selection state) mentioned. The phrase 'expanded operation' is unhelpful and does not clarify usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing side effects, state changes, or requirements. It only says 'set' without mentioning whether the operation is destructive, requires specific permissions, affects other settings, or returns any output. This is a severe lack of transparency for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, but it is under-specified rather than concise. 'Premiere Pro expanded operation' is filler, and the rest repeats the tool name. Every word fails to add value, so the structure does not earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a setting tool with no annotations, no output schema, and likely many possible audio settings, a one-line vague description is completely inadequate. The tool needs details on what settings can be changed, expected input structure, side effects, and validation. None are present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is an open object with additionalProperties and no defined properties, while context reports 0 parameters. Although the schema provides no specific parameter names, the description does not clarify what fields or values are expected. With no guidance, an agent cannot construct a valid request. The schema coverage is vacuously high, but the description adds no meaningful parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool sets sequence audio settings, which identifies the action and target resource. However, it is extremely vague, does not specify which audio settings, and is nearly a restatement of the tool name. The phrase 'expanded operation' adds no clarity and does not differentiate this tool from siblings like set_sequence_settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 versus alternatives, prerequisites, or any context for usage. There are no mentions of when to prefer this over other setting tools, making it impossible for an agent to decide between this and set_sequence_settings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It fails to explain what 'set start time' means operationally, whether it mutates project state, requires certain selections, or has side effects. The description adds no behavioral context beyond the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, but it is mostly boilerplate ('Premiere Pro expanded operation') and restates the tool's name. It is under-specified rather than concise, failing to provide valuable content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool is part of a large API with many sibling operations, but the description gives no context about the object or domain of the start time. There is no output schema or annotations to compensate, making the description critically incomplete for correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so according to the rubric, the baseline is 4. The description adds no parameter details, but the absence of parameters means little is needed. The schema is generic, yet the description does not confuse the matter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Premiere Pro expanded operation: set start time' provides a verb and a resource ('start time'), but the resource is undefined. It could refer to a clip, sequence, timeline, or effect, and there is no differentiation from sibling tools like set_clip_start_time, making the purpose unclear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 versus alternatives. There is no mention of limits, prerequisites, or context, leaving the agent without direction on selecting this tool over related ones.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavior. It only says 'set zero point' without explaining the mutation's scope, side effects, or reversibility, leaving agents completely in the dark.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than conciseness. The phrase 'Premiere Pro expanded operation' is filler, and the rest simply repeats the tool name without earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and an empty input schema, the description must explain the operation's purpose and behavior. It only restates the name, making it completely inadequate 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.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is trivially complete and there is no parameter semantics to clarify. The baseline score of 4 applies since no parameters need explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description essentially restates the tool name ('set zero point') with a boilerplate prefix. It does not define what 'zero point' means in Premiere Pro or distinguish it from similar tools like set_start_time or set_playhead_position.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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. There is no mention of timeline context, prerequisites, or scenarios where this operation is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It merely says 'Premiere Pro expanded operation: unnest sequence,' which reveals nothing about side effects, reversibility, required state, or what the operation does to the sequence.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, but it is under-specified rather than concise. It provides no meaningful content beyond the tool name, so the brevity is a deficiency, not a virtue.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description must explain the tool's purpose and outcome. It fails to describe what unnesting does, what the result is, or how it relates to other sequence operations, making it incomplete even for a parameterless tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is 100%, so the schema fully describes all inputs. With no parameters to document, the description does not need to add parameter-level semantics; the baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description essentially restates the tool name: 'unnest sequence' repeats the token 'unnest_sequence' with an article. It identifies a verb and resource but gives no functional detail about what unnesting a sequence entails, nor does it distinguish the tool from similar operations like nest_clips or create_subsequence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool, what prerequisites exist, or which alternatives to consider. The phrase 'expanded operation' is vague and does not explain appropriate usage context or exclude cases. Sibling tools are not referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It merely says 'close project' without explaining whether changes are saved, if a prompt appears, or whether unsaved work is lost. This is a serious gap for a potentially destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is under-specified, not concise. The single sentence adds no information beyond the tool name and includes boilerplate 'Premiere Pro expanded operation' that consumes space without earning its place. A one-line description can be sufficient, but this one lacks substance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a project-closing operation with potential loss of unsaved changes, the description is inadequate. It fails to mention save behavior, confirmation dialogs, or the effect on other open projects. The lack of annotations and output schema makes this omission more critical, as the agent has no other context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema confirms this with no defined properties. Since no parameters exist, the description need not explain them, and the baseline of 4 is appropriate. The odd schema with additionalProperties does not create a need for parameter explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Premiere Pro expanded operation: close project' is essentially a restatement of the tool name 'close_project' with no additional detail. It identifies the resource but fails to differentiate from similar operations like close_sequence or close_source_monitor, providing no unique value.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives such as save_project, open_project, or close_sequence. There is no mention of prerequisites, side effects, or recommended scenarios, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It only says 'detach proxy' without indicating whether it modifies clips, requires selected clips, or affects proxy files. No side effects or prerequisites are mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence but is under-specified rather than concise. It repeats the tool name and adds no value, so the short length is not a positive attribute.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is inadequate for a tool that likely performs a significant operation on proxy media. No output schema exists, and the description fails to explain the tool's effects, prerequisites, or reversibility.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The permissive schema adds no specific properties, and the description contains no parameter information, but none is needed given zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Premiere Pro expanded operation: detach proxy' essentially restates the tool name without explaining what 'detach proxy' performs. It lacks scope or impact, and while it differentiates from siblings like has_proxy/manage_proxies, it provides no functional detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool or how it relates to alternatives. The description contains no context for selecting it over other proxy-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations at all, the description carries the full burden of behavioral disclosure. It fails to state whether the operation is read-only, what data it returns, whether it requires an active sequence, or any potential side effects. The description merely names the action without explaining its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (six words), which is positive, but it lacks genuine structure or elaboration. The template 'Premiere Pro expanded operation:' feels generic and does not inform. It is brief yet under-specified, earning an average score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no parameter descriptions, the tool description must explain what 'track info' means and what the return value looks like. It does neither. An agent has no idea what to expect from the tool's output or how to interpret the result, making it severely incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is an empty object. Given the 0-parameter baseline of 4, the description is not required to explain parameter details. It adds no parameter information, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description, 'Premiere Pro expanded operation: get track info,' is essentially a restatement of the tool name with a product prefix. It does not specify what 'track info' includes (e.g., track type, name, visibility) or the scope (current sequence, all tracks). It also does not distinguish this from sibling tools like list_sequence_tracks or get_sequence_structure, which likely provide similar information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 versus alternatives. It does not mention any context, prerequisites, or exclusions. The phrase 'expanded operation' hints at a broader scope but offers no concrete direction, leaving the agent without any decision-making basis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description provides no behavioral information. It does not disclose whether it modifies clips in place, requires a selection, has side effects, or any other operational details, leaving the agent without critical safety or execution context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief, but this is under-specification rather than concise effectiveness. It lacks any useful structure or elaboration, making it a label rather than a helpful description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that likely needs to specify an effect and target clips, the description is completely inadequate. There is no explanation of the input object, expected behavior, or output, and the combination of an open schema and no annotations makes this tool impossible to invoke correctly based solely on the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is an open object with no defined properties (additionalProperties allowed), so the agent has no structured guidance. The description adds no parameter meaning, not even hinting at what fields like 'effect' or 'clip' might be expected. With a schema coverage of 100% but effectively zero documented parameters, the description fails to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool does 'batch apply effect', which clearly identifies the operation as batch-applying an effect. However, 'expanded operation' is vague and doesn't specify what effect, which clips, or any distinguishing details beyond the sibling 'apply_effect'. It gives a basic sense of purpose but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool, what selections or prerequisites are needed, or how it differs from similar tools like 'apply_effect' or 'batch_enable_disable'. No usage context, exclusions, or alternatives are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavior. It does not mention whether the operation mutates clip state, what it affects, or any side effects. The phrase 'batch enable disable' is just a label with no behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is under-specified rather than concise. The single phrase 'Premiere Pro expanded operation: batch enable disable' adds no information beyond the tool name and does not earn its place; it reads as a stub.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's batch operation nature, the absence of annotations, no output schema, and zero parameter detail, the description is completely inadequate. It doesn't tell the agent what the operation affects, what inputs it might accept, or what the expected outcome is.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines zero actual parameters (only propertyNames and additionalProperties, with no concrete properties), so there is nothing to explain. The description doesn't need to add parameter semantics beyond what the schema shows, and the empty schema leaves no ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a tautology: 'batch enable disable' restates the tool name without specifying what is enabled/disabled or the target scope. It adds only the generic context 'Premiere Pro expanded operation' and fails to distinguish from the sibling tool 'enable_disable_clip'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like 'enable_disable_clip' or 'select_disabled_clips'. The description omits any context about prerequisites, selection state, or whether it operates on all clips or only selected ones.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavior, but it only says 'close sequence' without explaining what happens: whether it closes the active sequence only, whether changes are saved, if there are side effects, or if confirmation is required. It offers no additional behavioral context beyond the semantic of the verb 'close'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief but not effectively concise; it repeats the tool name and adds a boilerplate prefix ('Premiere Pro expanded operation:') that carries no value. It is under-specified rather than concise, lacking any useful structural detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations, no output schema, and no parameters, so the description is the sole source of context. It only states 'close sequence' without explaining what sequence, in what context, or with what consequences. This is completely inadequate for an agent to understand the tool's role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4. The description adds nothing about parameters, but none exist to document. There is no conflict or missing parameter information; the absence of parameters is clear from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Premiere Pro expanded operation: close sequence' simply restates the tool's name (close_sequence) with a generic prefix. It identifies a verb and resource but adds no new information beyond the name itself, making it essentially tautological. It does not distinguish itself from sibling tools like close_source_monitor 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.
Usage Guidelines2/5Does 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 versus alternatives such as close_source_monitor, close_all_source_clips, or close_project. There is no context, precondition, or exclusion information. It fails to inform the agent about appropriate invocation scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full burden of behavioral disclosure. It fails to disclose what the tool does concretely, whether it is destructive, what inputs it expects, or what side effects it may have. It is just a restatement of the name with no additional behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, but its single sentence merely repeats the tool name. It does not earn its place because it contributes no useful information. It is under-specified rather than concise, similar to a placeholder.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's apparent complexity (copying effect values in Premiere Pro), the description is drastically incomplete. There are no annotations, no output schema, and no explanation of behavior, inputs, or relationship to sibling tools. An agent cannot correctly select or invoke this tool based on this description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero defined parameters according to the context signals, so the baseline is 4. While the input schema is permissive and the description provides no parameter details, there are no parameters to document. The description cannot add meaning beyond what the schema provides for this dimension.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description merely restates the tool name: 'copy effect values.' It adds 'Premiere Pro expanded operation,' which is vague and does not clarify what 'expanded' means or how this differs from sibling tools like 'copy_effects_between_clips.' It provides no information about the source, target, or scope of the copy operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives such as 'copy_effects_between_clips' or 'set_effect_property.' It does not mention any prerequisites, typical use cases, or exclusions, leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It only adds 'expanded operation,' which is vague and gives no details about return values, side effects, permissions, or whether the operation is read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is only one sentence, it is under-specified rather than concise. It provides no substantive information and functions as a mere label, missing the opportunity to convey useful details in a compact form.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is almost entirely uninformative. It lacks any details about the operation's behavior, inputs, outputs, or use cases, making it inadequate for an agent to select or invoke the tool correctly, especially given the large number of sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the description is not required to explain parameter semantics. The schema already indicates an empty object, and the baseline for 0 parameters is 4. However, the description adds no contextual meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Premiere Pro expanded operation: get clip links' merely restates the tool name with an unhelpful prefix. It does not explain what 'clip links' are or what the tool actually does, nor does it distinguish it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 or how it differs from alternatives. No usage context, prerequisites, or exclusions are mentioned, leaving the agent without direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior, but it says nothing about what the returned marker data includes, whether selection affects results, or if this is a read-only operation. The description adds no behavioral traits beyond the fact that it gets clip markers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, but it is under-specified rather than concise; it adds no information beyond the tool name. The phrase 'Premiere Pro expanded operation' is filler and does not earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations, no output schema, and a generic schema with no defined parameters. Given the existence of many marker-related sibling tools, the description is far too minimal. It does not clarify what 'clip markers' includes, how results are returned, or what the tool's scope is.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero defined parameters and no description; the context confirms 0 parameters. Since there are no parameters to clarify, the description does not need to add parameter semantics. Baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Premiere Pro expanded operation: get clip markers' merely restates the tool name with a generic prefix. It does not provide a specific verb-resource statement beyond the name, nor does it distinguish from sibling tools like get_sequence_markers_by_type or list_markers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. The phrase 'expanded operation' is vague and does not indicate context such as whether to use it for clip markers vs sequence markers or how it differs from list_markers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description must bear the full burden of behavioral disclosure, but it merely states 'get' without mentioning whether it returns a value, what that value represents, or any side effects. The description provides no meaningful behavioral information beyond the tool name, leaving the agent entirely in the dark.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief, but the phrase 'Premiere Pro expanded operation' is filler and the rest is a tautology. It is under-specified rather than concise, failing to earn its place because it adds no informative value beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a getter with no output schema, the description must explain what the tool returns. It does not describe the meaning, units, range, or format of 'white luminance,' leaving the agent without any understanding of the expected result. The description is inadequate even for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4 per the rubric. There are no parameter descriptions needed, and schema coverage is trivially 100%. The description does not need to add parameter meaning because there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description simply restates the tool name ('get graphics white luminance') with the generic prefix 'Premiere Pro expanded operation,' providing no explanation of what white luminance is or what the get operation does. It does not distinguish this tool from the sibling setter, making it a tautological statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool, what prerequisites exist, or why it might be preferred over alternatives like set_graphics_white_luminance. The description lacks any contextual hint about appropriate usage, so it offers no actionable direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It completely fails to describe any behavior: whether it scans the project, returns a list of items, requires any selection, or affects the state. The phrase 'expanded operation' adds no concrete information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but under-specified. It is not concise in a helpful way; it omits essential information while adding a vague 'expanded operation' prefix. Since the name already conveys the bare resource, this single sentence does not earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and a highly generic description, the tool is completely incomplete for an AI agent to know what it does or what it returns. The context from siblings (e.g., 'check_offline_media') hints at a related operation, but the description itself offers no context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero required parameters and the schema shows no defined properties, so the description does not need to explain parameter semantics. Baseline for 0 params is 4, and there is no missing param information to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Premiere Pro expanded operation: get offline media' is essentially a restatement of the tool name with a generic prefix. It fails to specify what 'get offline media' means — does it return a list, check status, or something else? It does not distinguish from siblings like 'check_offline_media' or 'get_unused_media'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 versus alternatives. There is no mention of conditions, use cases, or exclusions compared to sibling tools such as 'check_offline_media' or 'get_unused_media'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It merely restates the name and gives no information about read-only status, return value shape, possible errors, or side effects. The 'get' in the name implies a read operation, but the description itself adds no behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but under-specified. The phrase 'expanded operation' is vague filler, and the rest duplicates the tool name. It omits essential information rather than being concisely informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no explanation of what 'sequence structure' contains. Without annotations or return-value documentation, the description is completely inadequate for a tool that likely returns complex, nested Premiere Pro sequence data. The overlap with sibling tools further amplifies the need for detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema confirms no required or optional properties. Per rubric, 0 parameters warrants a baseline of 4; there are no parameter semantics for the description to clarify.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially the tool name with spaces: 'get sequence structure' directly restates 'get_sequence_structure'. The prefix 'Premiere Pro expanded operation' adds a vague category but no functional detail about what the structure includes or how it differs from sibling tools like get_full_sequence_info or list_sequence_tracks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. With many overlapping sequence-inspection siblings (get_full_sequence_info, get_sequence_settings, list_sequence_tracks, get_active_sequence), the description provides no criteria for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must disclose whether this is a read-only operation, what it returns, or any side effects. It does none of this; it merely names 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.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. The phrase 'expanded operation' adds no value, and the description does not earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and a non-existent description beyond the name, the tool is completely underspecified. An agent cannot know what the tool returns, when to call it, or what 'unused media' entails.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema is trivial. The description adds no parameter semantics, but the baseline for zero parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description simply restates the tool name ('get unused media') with a generic 'Premiere Pro expanded operation' prefix. It does not elaborate on what 'unused media' means or how it differs from similar tools like get_used_media_report or get_offline_media, making it a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as get_used_media_report or get_duplicate_media. The description is silent on prerequisites or comparison with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not state any effects, prerequisites, or side effects of the operation, offering only a label. The agent has no idea what happens when invoking this tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but brevity here is under-specification rather than conciseness. It lacks structure and substantive content, similar to a tautological one-liner that wastes the reader's time without delivering actionable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool appears to perform a meaningful editing action in Premiere Pro, yet the description provides zero context. There are no annotations, no output schema, and no parameter documentation. A complete and usable description would explain insert semantics, relationship to source monitor, and differences from overwrite_from_source.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero defined parameters, and the base score for zero-parameter tools is 4. The description adds no parameter details, but there is also nothing to clarify. The schema's permissive additionalProperties is not addressed, but this is not a critical gap given no formal parameters exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Premiere Pro expanded operation: insert from source' merely restates the tool name with the filler phrase 'expanded operation,' which adds no meaning. It fails to specify the verb scope or distinguish the tool from sibling tools like overwrite_from_source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. No context about insertion behavior, playhead requirements, or comparison to overwrite_from_source is provided, leaving the agent without any usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must disclose behavior. It only says 'Premiere Pro expanded operation,' which is vague and does not mention return values, side effects, prerequisites, or any other behavioral traits. The agent gets no information about what calling this tool does.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but under-specified rather than appropriately concise. The single sentence adds no value beyond the tool name and fails to communicate essential information, making it an inefficient use of the description space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no params), the description still fails to convey basic context such as what the tool returns (likely a boolean) or what 'enabled' means. With no output schema and no annotations, the description carries the full burden and falls far short of being complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing for the description to add. Per the rubric, a zero-parameter tool receives a baseline of 4, and the description does not need to explain parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a restatement of the tool's name: 'is work area enabled.' It does not clarify what the tool does beyond the obvious question implied by the name. No additional information distinguishes it from potential sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool, what scenarios it applies to, or how it relates to alternatives like `set_work_area` or `get_work_area`. The description lacks any contextual cues for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior, but it only says 'lift selection'. It does not explain whether the operation is destructive, whether it leaves a gap, how it interacts with tracks or selections, or any side effects. This is a serious transparency gap for a timeline-modifying tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one line but offers no substantive content. This is under-specification rather than conciseness; every word should earn its place, but 'Premiere Pro expanded operation' is filler and 'lift selection' only restates the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool operates as part of a large set of timeline editing tools, yet the description provides no context on what the operation does, when it is useful, or what effects it has. There are no annotations or output schema to compensate, making the description wholly inadequate for an agent to understand and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is empty and the description cannot add parameter-level meaning. Per the rubric, 0 parameters gives a baseline of 4. The description does not need to explain parameters that do not exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Premiere Pro expanded operation: lift selection' essentially restates the tool name and adds a vague 'expanded operation' qualifier. It does not define what 'lift' means (e.g., removing selected clips while leaving a gap) nor distinguish it from sibling 'extract_selection' which likely removes and closes gaps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like extract_selection, ripple_delete, or remove_selected_clips. No prerequisites or context (e.g., must have an active selection) are mentioned, leaving the agent without decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for disclosing behavior. It offers no information about side effects, what the operation changes, whether it requires a selection, or any safety implications. The phrase 'expanded operation' is vague and does not clarify the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, but it is under-specification rather than concise. It merely rephrases the tool name and adds no functional value. Every sentence should earn its place; this one does not.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations and no output schema, so the description must provide complete context. It fails to explain what linking a selection entails, what inputs are implicitly used (e.g., current selection), or what the result would be. This is inadequate for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and the schema coverage is 100% (vacuously). According to the rubric, 0 params earns a baseline of 4. The description adds no parameter semantics, but none are needed since there are no parameters to describe.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Premiere Pro expanded operation: link selection.' essentially restates the tool name without defining what 'link selection' means. It does not specify the verb action clearly (e.g., 'Links selected clips' or 'Creates a link between selected items') nor differentiates from siblings like 'unlink_selection' or 'link_audio_video'. This is a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 versus alternatives. There is no mention of prerequisites, typical scenarios, or relationships to sibling tools such as 'unlink_selection' or 'link_audio_video'. The user is left without any contextual cues for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It fails to indicate whether the operation is destructive, what source or selection it uses, whether it can be undone, or any side effects. 'Expanded operation' is meaningless without elaboration.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, but it is under-specified rather than concise. Phrases like 'Premiere Pro expanded operation' add no value and do not earn their place. The entire sentence could be replaced with useful details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, no output schema, and no parameter definitions, the description is grossly incomplete. It does not explain what overwriting a clip does, how it affects the timeline, what the expected input or context is, or any consequences of invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema declares no parameters and the description adds no parameter information. Since there are zero parameters, the schema already covers everything, making the baseline score of 4 appropriate. The description does not need to compensate for undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'overwrite clip' essentially restates the tool name, providing no additional context about what the operation actually entails. The prefix 'Premiere Pro expanded operation' is generic filler and does not distinguish this tool from similar siblings like overwrite_from_source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It does not mention prerequisites, selection requirements, or any exclusions, leaving the agent without direction for choosing this tool over related edit operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of disclosing behavior. It only states 'remove effect' without explaining whether it removes all effects from selected clips, requires an effect index or name, is destructive, or what the result is. This is a significant gap for a potentially destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but this is under-specification rather than concise efficiency. It lacks any structured information such as required input, scope, or side effects. A single vague sentence does not earn high marks for structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the absence of annotations and output schema, the description is entirely inadequate. It does not mention how the effect is identified, whether it applies to the selection, or how it relates to sibling tools like remove_effect_by_name. The 'expanded operation' phrasing suggests a non-obvious behavior that remains unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema declares zero parameters, so the baseline is 4 and the description need not explain parameter details. However, the schema allows arbitrary properties (additionalProperties: {}), which is ambiguous, but context confirms parameter count is 0. The description adds no semantic meaning beyond the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a restatement of the tool name: 'remove effect.' It does not specify what effect, from what clip or track, or how it differs from siblings like remove_effect_by_name or remove_all_effects. The phrase 'Premiere Pro expanded operation' is generic boilerplate that adds no clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as remove_effect_by_name, remove_all_effects, or copy_effects_between_clips. There is no mention of prerequisites like selecting a clip or whether it affects all effects or a specific one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It gives no information about side effects, whether it requires a selected clip, or whether it changes existing blend modes irreversibly. The sentence is completely uninformative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but not effectively concise; it wastes the only words on 'expanded operation' and adds no substantive content. It is an under-specified one-liner rather than a helpful, tightly-worded summary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations, no output schema, and an empty input schema. The description must therefore provide all context, but it gives almost nothing: no target object, no blend mode values, no prerequisite selection, no result or side effects. This is completely inadequate for an operation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero explicit parameters, and schema coverage is 100% because the schema is essentially empty. Per the rubric, 0 params receives a baseline of 4. The description does not contradict or mislead about parameters, although it also does not clarify what arguments might be accepted via additionalProperties.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description merely restates the tool name ('set blend mode') and adds the vague qualifier 'Premiere Pro expanded operation'. It does not specify the resource (clip, track, project) or the scope, so it is essentially a tautology with no more meaning than the name itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided for when to use this tool or how it relates to alternatives such as set_frame_blend, set_time_interpolation, or set_clip_opacity. There is no mention of prerequisites, selection requirements, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description discloses no behavioral traits beyond the operation name. It does not mention side effects, selection behavior (replace/add/toggle), whether it works on timeline clips or project items, or any required context. This is a minimal, non-informative description for a tool with zero annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. A single phrase restating the tool name does not provide structured or useful information, and the 'expanded operation' wording is unexplained.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a selection operation with no annotations, no output schema, and no parameter definitions, the description is severely incomplete. It fails to explain what 'expanded operation' means, how to specify the clip selection, what the operation returns, or how it relates to the many sibling selection tools. The agent cannot reliably invoke or interpret the result of this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema declares zero formal parameters and the context reports 100% schema description coverage, so there are no parameters to explain. Per the rubric, 0 parameters earns a baseline of 4. However, the 'additionalProperties' permission in the schema could imply arbitrary inputs, but since no concrete parameters are defined, the description's lack of param detail is not penalized.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'set clip selection' is essentially a restatement of the tool name, providing no detail about what specific operation is performed or how it differs from sibling tools like select_all_clips, select_clips_in_range, or deselect_all_clips. The prefix 'Premiere Pro expanded operation:' adds no clarifying information and is vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus other selection-related siblings. The description does not indicate whether it replaces the current selection, adds to it, or is intended for a specific workflow, leaving the agent without decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It fails to state what the tool actually does beyond a vague name repetition, whether it modifies clip speed, what side effects it might have, or any required context. This is a complete absence of behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but it is under-specified rather than appropriately concise. Every word is generic filler ('Premiere Pro expanded operation') that adds no value, while the core content is just a repeat of the name. It lacks the substance needed to be an effective description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (an operation in Premiere Pro with many sibling tools), no annotations, and no output schema, the description should explain what 'qe' means, what the operation does, when to use it, and any side effects. It provides none of this, making it profoundly incomplete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero defined parameters, and the schema covers everything (schema_description_coverage is 100%). With no parameters, the baseline is 4; the description does not need to explain parameters, and it does not introduce any confusion in this respect.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'set clip speed qe' is essentially a restatement of the tool name, with the generic prefix 'Premiere Pro expanded operation' adding no specificity. It provides a verb and resource but fails to explain what 'qe' means or how it differs from similar tools like speed_change. This is tautological in nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as speed_change or get_clip_speed. The description does not mention any context, prerequisites, or exclusions, leaving the agent without a basis for choosing it correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose side effects, required context, and outcomes, but it only restates the function name. It doesn't mention that this mutates the effect, what happens to the original value, potential errors, or return values. This is a significant transparency gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but under-specified. It is not effective conciseness; it reads as a title rather than an explanatory description. The phrase 'Premiere Pro expanded operation' is filler that doesn't convey value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that sets an effect property, this description is completely inadequate. It lacks any information about the expected parameters, how to target an effect, valid property names, value formats, or error conditions. With no output schema and no annotations, the agent has essentially no useful context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines no properties (parameter count 0), yet the tool name implies at least effect identity, property name, and value. The description provides zero parameter guidance, so the agent cannot determine how to invoke the tool. The combination of an empty schema and a vague description makes parameter semantics entirely unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'set effect property' provides a clear verb and resource, indicating the tool modifies a property on an effect. However, 'Premiere Pro expanded operation' adds no specificity, and it doesn't distinguish this from siblings like get_effect_properties or remove_effect beyond the verb. It's understandable but shallow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 instead of alternatives like apply_effect or set_clip_properties. The description lacks any context about prerequisites (e.g., needing a selected effect), workflow placement, or exclusions. The agent is left without direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It reveals nothing about side effects, required context, return values, or potential impacts on the project. This is a complete lack of transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but it is under-specified. It adds no information beyond the tool name, so the brevity is not effective conciseness—it is a lack of substance. A concise description should be informative, which this is not.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a specific Premiere Pro setting), no annotations, no output schema, and no parameter context, the description is severely incomplete. It fails to explain what 'graphics white luminance' means, what values it accepts, or what the expected outcome is.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Context signals indicate 0 parameters, and the schema coverage is 100%. With no parameters to describe, the description does not need to explain them. The provided schema is permissive but not requiring any properties, so the baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Premiere Pro expanded operation: set graphics white luminance,' which essentially restates the tool name with a generic 'expanded operation' prefix. It identifies the action (set) and resource (graphics white luminance) but provides no explanation of what this setting is, making it a tautology rather than a meaningful clarification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool or how it differs from alternatives. The sibling tool get_graphics_white_luminance is not mentioned, and no context is given about appropriate scenarios or prerequisites for setting graphics white luminance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description discloses nothing about side effects, required selections, mutability, or reversibility. The agent has zero insight into what invoking this tool will do.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is brief, it is under-specified rather than efficiently informative. It contains no substantive information beyond the tool name, making it a tautological placeholder.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is completely inadequate for an agent. It fails to explain what a poster frame is, how one is set, what the prerequisite context is (e.g., a selected clip), or what the effect will be. Without any output schema or additional annotations, the agent cannot safely invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema fully defines the input structure. With no parameters to explain, the description does not need to compensate, so the baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Premiere Pro expanded operation: set poster frame' simply restates the tool name with a generic prefix. It does not clarify what a poster frame is, which object it applies to, or how it differs from other 'set' tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool, what prerequisites exist, or how it relates to sibling tools like capture_frame or freeze_frame. The description provides no actionable usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only restates the tool's name. It does not disclose side effects, whether existing metadata is overwritten, error conditions, or the return value. 'Expanded operation' adds no behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, but 'Premiere Pro expanded operation' is filler that does not earn its place. It is under-specified rather than appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the vague schema and lack of annotations, the description is grossly inadequate. It fails to clarify the metadata format, required input structure, or any usage context, making it nearly impossible to use correctly without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines no explicit parameters, only additionalProperties, so the accepted metadata structure is undocumented. The description offers no examples or explanation of valid keys or values, leaving the agent without enough information to invoke the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('set project panel metadata') but adds little beyond the tool name. The qualifier 'Premiere Pro expanded operation' is vague and does not clarify what distinguishes this from sibling metadata tools like set_xmp_metadata or set_metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not mention prerequisites, typical use cases, or why one would choose this over get_project_panel_metadata or other set_* metadata functions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It says 'expanded operation' but doesn't explain what that means, what the side effects are, whether it mutates state, or what the expected input structure should be. The tool clearly performs a write operation, but no details are provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence, but under-specification is not conciseness. Every word should add value; 'Premiere Pro expanded operation' is filler, and 'set scratch disk path' simply restates the tool name. It is not properly structured to convey useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutating tool with no annotations, no output schema, and an empty parameter schema. The description provides no context about return values, failure modes, or relation to other scratch disk operations. It is completely inadequate for reliable agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines no parameters (only a generic object with arbitrary properties). The description does not compensate by explaining what properties to provide (e.g., the path key or value format). With 0 defined params and no description guidance, the agent is left completely in the dark about how to invoke this tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('set scratch disk path') but adds the vague qualifier 'expanded operation', which doesn't clarify how this differs from the sibling tool 'set_project_scratch_disk'. It's clear on the basic verb+resource but fails to distinguish from a likely overlapping tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus 'set_project_scratch_disk' or 'get_project_scratch_disks'. The description gives no context for appropriate usage, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only repeats the action. It doesn't state whether the frame rate is applied to the active sequence, whether any confirmation occurs, or what side effects may result. This is a complete absence of behavioral information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but not effectively so. It is merely a restatement of the tool name and does not earn its place by adding value. Under-specification is not conciseness; the sentence is wasteful because it provides no novel information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the large context of sibling tools and lack of annotations/output schema, the description is severely incomplete. It fails to mention which sequence is affected, how the target frame rate is communicated, or any prerequisites. There is no meaningful guidance for an agent to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the schema description coverage is 100%. With no parameters to document, the baseline is 4. The description could have explained how the frame rate is determined (e.g., from current project settings), but the absence of parameters reduces the burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description restates the tool name as 'set sequence frame rate' without adding any new information. It specifies the verb and resource but does not distinguish from sibling tools like set_sequence_settings or set_sequence_resolution. The phrase 'Premiere Pro expanded operation' is generic and does not clarify the tool's unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. For example, set_sequence_settings could set the frame rate along with other properties, but no exclusions or preferences are mentioned. The description provides no context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden of behavioral disclosure. It only repeats the tool's name and provides no information about side effects, timing, requirements (e.g., active sequence), or what 'expanded operation' means. This is a significant gap for a tool that likely mutates editing state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but this is under-specification rather than effective conciseness. The single sentence contributes no meaningful guidance beyond the tool name, so it does not earn its place as a useful description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is completely inadequate for an operation in Premiere Pro. It does not explain the concept of a target track, specify which tracks are affected, or indicate whether a sequence must be open. Given the lack of annotations and output schema, the description should provide more context but provides none.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description is not required to explain parameter behavior. The baseline of 4 applies; the description adds no parameter information, but none is needed since the schema and context indicate no parameters exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Premiere Pro expanded operation: set target track' essentially restates the tool name 'set_target_track' with no additional specifics. It lacks a clear explanation of what setting the target track entails or how it differs from sibling tools like 'set_all_tracks_targeted' or 'get_target_tracks'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. It does not mention prerequisites, intended scenarios, or filters/exclusions, leaving the agent without direction for choosing this tool among many related timeline and track operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits, but it is empty. It does not state side effects, permissions required, whether it mutates clips, or any other runtime implications. This is a complete lack of transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but filled with boilerplate ('Premiere Pro expanded operation'). It does not earn its place as it provides no useful information. This is under-specification rather than conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, no output schema, and a degenerate input schema, the description must compensate but does not. It fails to clarify the tool's purpose, operation, or expected impact. It is completely inadequate for an AI agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema reports zero parameters and 100% schema description coverage, so the description adds no parameter details. Per the rubric baseline for 0 parameters, this is acceptable. However, the description could have mentioned how time interpolation is applied or if any implicit targets (e.g., selected clips) are used, but this is not required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description merely restates the tool name ('set time interpolation') with a boilerplate prefix 'Premiere Pro expanded operation.' It does not clarify what time interpolation means in this context, how it affects clips, or what specific behavior is being set. It fails to distinguish from sibling tools like set_keyframe_interpolation or set_frame_blend.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage context is provided. There is no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusion criteria. The phrase 'expanded operation' gives no actionable information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses nothing about side effects, permissions, whether it modifies project settings, or what happens when invoked. The description is purely a restatement of the tool name with no behavioral content.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is a single short sentence, it is under-specified rather than concise. The phrase 'Premiere Pro expanded operation' is filler that adds no information. It does not earn its place and the sentence provides no useful substance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description provides almost no contextual information. It fails to explain the concept of 'transcode on ingest', what inputs it might accept, or what result the user can expect. This is inadequate even for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there are no parameter semantics to clarify. The schema is essentially an empty object with no properties; the description adds nothing, but no additional parameter explanation is needed. Baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description essentially restates the tool name ('set transcode on ingest') with the vague qualifier 'Premiere Pro expanded operation'. It does not explain what setting transcode on ingest actually does, what resources it affects, or how it differs from any of the many sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description gives no context about prerequisites, typical use cases, or situations where another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it provides none. It does not explain what 'expanded operation' entails, what state changes occur, or whether the operation is destructive or reversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The one-sentence description is brief but under-specified. It omits essential context, making it not concise but merely sparse. Important operational details are missing, so the brevity does not serve a useful purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and no parameter guidance, the description leaves the agent without any understanding of prerequisites, side effects, or return behavior. It fails to clarify what the operation does in the Premiere Pro context, especially in relation to sibling scaling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters per the input schema, so the description is not required to add parameter details. The baseline for 0 params is 4, and the description does not contradict or undermine this.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description essentially restates the tool name ('set uniform scale') with a vague prefix 'Premiere Pro expanded operation.' It fails to specify the target resource (e.g., a clip, all selected clips, or a sequence) and does not distinguish itself from sibling tools like set_clip_scale or set_scale_width_height.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. The description does not mention whether a specific selection is required, whether it applies to an active sequence, or how it differs from other scaling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavioral traits. It merely states the action without indicating whether it requires a sequence, whether it modifies existing layers, or what side effects occur. This is a significant gap for a mutation operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief but this is under-specification rather than concise clarity. It lacks structure and omits essential context, similar to the 'Process' example.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and no parameter reasoning, the description should provide more context about the effect and usage. The current text is nearly a tautology and does not adequately inform the agent about what the tool does or when to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is trivially 100%. Per rubric, 0 params sets baseline 4, and there is no parameter information to add.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'add adjustment layer' is a direct restatement of the tool name with no additional detail. The prefix 'Premiere Pro expanded operation' adds no functional meaning and does not specify where the layer is added or what the operation entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. There is no mention of prerequisites, target sequence, or situations where adjusting layers are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it provides none. It doesn't state whether the operation is read-only, what data is returned, or any side effects, leaving behavior completely opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but it merely restates the tool name. It's concise in length yet adds no value, so the sentence doesn't earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no output schema, and no annotations, the description should at least clarify what 'project panel metadata' includes and how it differs from other getters. It doesn't, making it incomplete for the many sibling tools present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so the schema leaves nothing to explain. Baseline for 0 params is 4; the description adds no meaningful parameter info, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Premiere Pro expanded operation: get project panel metadata' uses a verb and resource, but 'get project panel metadata' is almost identical to the tool name. It doesn't distinguish this from sibling tools like 'get_project_info' or 'get_metadata', leaving the exact purpose vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It doesn't mention scenarios, prerequisites, or contrast with related getters, so the agent has no help deciding when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the entire burden of behavioral disclosure. It fails to mention any side effects, return format, error conditions, or performance characteristics. It only repeats the tool's name, providing zero transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but not genuinely concise—it contains filler ('Premiere Pro expanded operation') and simply restates the tool name. It does not pack meaningful information into its small space, making it under-specified rather than well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, this description is insufficient. It does not clarify what count is returned (e.g., number of sequences in the project), whether an open project is required, or how the result is presented. The agent is left with no helpful context beyond the name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description is not required to explain parameter semantics. The baseline of 4 is appropriate because there are no parameter details to add.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description restates the tool name ('get sequence count') without adding any specific detail. It is a tautology—the description adds no new information beyond the name itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 versus alternatives. It does not mention any prerequisites, typical use cases, or exclusions, so the agent gets no help in deciding when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and no behavioral disclosure in the description, the agent is left completely blind about side effects, return value, or whether the operation is read-only. 'Expanded operation' hints at something non-standard but provides no concrete behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but brevity comes at the cost of substance. 'Premiere Pro expanded operation' is wasted words and the core descriptive content is just a restatement of the tool name. This is under-specification, not effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and the presence of many similar source-monitor tools, the description is insufficiently complete. It does not clarify what 'info' means, whether it returns the loaded clip, playhead position, or other data, leaving a significant gap in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so the schema covers all parameter information by default. The description adds nothing about parameters, but with none present, there is little to explain. The baseline of 4 is appropriate, though the odd schema allowing additionalProperties is not clarified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description essentially restates the tool name: 'get source monitor info' adds no clarifying detail beyond the name itself. The phrase 'Premiere Pro expanded operation' is vague filler and does not specify what aspect of the source monitor is being retrieved or how it differs from sibling tools like get_source_monitor_position.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as get_source_monitor_position, play_source_monitor, or open_in_source. There is no mention of context, prerequisites, or when it should be avoided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden for disclosing behavior. It mentions no return values, side effects, or operational details. The description is completely opaque about what the tool actually does or returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is extremely short, it is under-specified rather than concise. One sentence that merely repeats the tool name adds no value and fails to provide necessary context. True conciseness would include useful information in minimal words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description should explain what the function returns (e.g., a list of workspace names). It does not. The tool is simple, but the lack of any return-value or behavioral context leaves the agent guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description has no parameter semantics to add. The schema is empty, and there is nothing to explain. Per the baseline for 0 parameters, a score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Premiere Pro expanded operation: get workspaces' is essentially a restatement of the tool name. It does not explain what 'workspaces' are or what 'getting' them entails, beyond the literal meaning. This is a tautology rather than a descriptive purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. There is a sibling tool 'set_workspace', but no differentiation or context is given. No when-to-use or when-not-to-use information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of disclosing behavior. It only states 'get xmp metadata' with no indication of return value, potential errors, or side effects. Even the read-only nature is implied only by the word 'get' rather than explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but under-specified. It is not a well-crafted concise summary; it is a fragment that repeats the tool name. The phrase 'Premiere Pro expanded operation' is filler and provides no structural value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description should provide more context about what XMP metadata is and how it is used. It fails to explain the tool's purpose within the larger set of metadata-related operations, leaving the agent without enough information to select or invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and the schema shows 100% coverage with an empty object. According to the guidelines, a zero-parameter tool receives a baseline of 4, and the description does not need to add parameter-level detail because none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Premiere Pro expanded operation: get xmp metadata' essentially restates the tool name, adding only the vague phrase 'expanded operation.' It does not specify what entity the XMP metadata belongs to (e.g., a clip, sequence, or project item), making it difficult to distinguish from siblings like get_metadata or get_clip_properties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 (e.g., get_metadata or set_xmp_metadata). The description gives no context about the intended use case, prerequisites, or selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries full responsibility for behavioral disclosure. It reveals no details about the operation's behavior—such as direction of movement, whether it navigates to the next/previous edit point, or any side effects—offering only a tautological statement that adds no transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short ('Premiere Pro expanded operation: move playhead to edit.'), but this is under-specification rather than effective conciseness. It lacks structure and essential details, making the brevity counterproductive—there is no meaningful content to front-load.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (no parameters, no output schema), but the description is too vague to be complete. The ambiguity around 'edit' is a significant gap, and the lack of annotations or additional context leaves the agent without enough information to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty with 100% coverage. The baseline for no parameters is 4, and there is nothing for the description to add about parameter meaning. The description is neutral here, neither adding nor detracting from parameter clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description directly restates the tool name ('move playhead to edit') without adding any specificity. It fails to clarify what 'edit' refers to (e.g., next edit, previous edit, or a specific edit point), and does not distinguish it from related timeline navigation tools like get_next_edit_point or set_playhead_position.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description provides no context about intended scenarios, prerequisites, or exclusions, leaving the agent to guess when 'move playhead to edit' is appropriate among many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must explain what the tool does. It only says 'multiple undo' without clarifying how many steps are undone, whether it's a single command that undoes all changes, or if it requires any input. The destructive nature of undo is implied but not disclosed with specifics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single fragment under 10 words, but it is under-specified rather than concise. It fails to communicate function and could be mistaken for a label. It does not earn its place as a useful sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though this is a simple tool, the meaning of 'multiple undo' is ambiguous. Without annotations or an output schema, the description should specify the undo scope (e.g., number of steps, or to last save). The absence of this information makes the description incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters and the schema defines none. Per the baseline for 0 params, the description does not need to explain parameters. However, it also does not clarify whether 'multiple' implies any optional count, leaving minor ambiguity. Still, with no params, the schema is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Premiere Pro expanded operation: multiple undo' essentially restates the tool name, using the same phrase 'multiple undo'. It does not provide a proper verb+object definition, such as 'Undoes multiple previous actions in the sequence'. It offers only a vague label, failing to distinguish itself beyond the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 versus the sibling 'undo' or 'redo'. There is no mention of alternatives, prerequisites, or scenarios where multiple undo is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It merely repeats 'search project items' without stating whether this is a read-only query, what fields it searches, what it returns, or any side effects. It provides zero behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single vague sentence that does not earn its place. 'Expanded operation' is meaningless filler, and the rest is a tautology of the tool name. This is under-specification rather than concise useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and no parameter details, the description should clarify behavior and usage. It fails to explain what 'search' means, how it differs from the many similar sibling tools, or what value it provides to the agent, leaving the tool selection ambiguous.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters and an empty schema, so the baseline is 4. The description adds no parameter information, but there is nothing to document, and it does not mislead.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Premiere Pro expanded operation: search project items' is essentially a restatement of the tool name and provides no additional clarity. 'Expanded operation' is vague filler, and it does not distinguish this tool from siblings like 'list_project_items' or 'find_project_item_by_name'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description does not mention intended use cases, search criteria, or any conditions that would make this tool preferable to similar project-item query tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states that the tool sets XMP metadata, but discloses nothing about side effects, overwrite behavior, required permissions, reversibility, or what exactly is modified. This is a serious transparency gap for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but it is under-specified rather than concise. The phrase 'Premiere Pro expanded operation' is filler that does not earn its place, and the rest is a bare restatement of the tool name. It fails to convey meaningful information in a structured way.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters, the schema provides no help. The description is too vague to be complete: it does not state what entity the XMP metadata is set on, whether it applies to selected clips, the current project, or something else. In a large suite of similar tools, this omission is critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 100% schema description coverage, so the baseline is 4. The description adds no parameter information, but none is needed since the operation takes no explicit arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'set xmp metadata' is essentially a restatement of the tool name 'set_xmp_metadata', with the vague prefix 'Premiere Pro expanded operation' adding no specific semantic detail. It does not distinguish itself from sibling tools like get_xmp_metadata or set_project_panel_metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, no prerequisites, and no examples. The description gives no context about the target entity (e.g., selected clips, project items) or when this operation is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose all behavioral traits. It provides none: no effects of the operation, no requirements (like a selected clip), no whether it is destructive or reversible, and no return values. The user/agent is left completely in the dark about what happens when this tool is invoked.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than conciseness. It consists of a single phrase that adds little value beyond the tool name. It lacks structure and substance, failing to earn its place as a useful description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations, no output schema, and a sparse schema, the description is the sole source of context. It completely fails to explain the operation, its purpose, prerequisites, or effects. This is inadequate even for a low-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema provides no info to describe. The baseline for 0 params is 4, and the description does not contradict or mislead. However, it also does not clarify the implicit input (likely the currently selected clip), but per the rule, the baseline stands without a reason to lower.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the operation is a slip edit in Premiere Pro, which is a specific editing action. However, 'expanded operation' is vague, and it mostly restates the tool name without explaining what slip edit does. It distinguishes from siblings like roll_edit by naming the specific operation, but the clarity is limited.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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. There are sibling tools like roll_edit and slide_edit, but the description gives no context about which situation calls for a slip edit or any prerequisites (e.g., selected clip). This is a fundamental omission.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior, but it only says 'get premiere state.' The verb 'get' minimally implies a read operation, but there is no mention of return contents, side effects, connection requirements, or whether this is safe to call at any time.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The text is short, but it is under-specified rather than concisely informative. It provides no useful information beyond the tool name, so the brevity does not earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotations, so the description must explain what 'premiere state' is and what the tool returns. It fails to do either, making this severely incomplete for a potentially broad state-retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero explicit parameters, so the baseline is 4. The description adds no parameter-specific details, but no such details are needed since there are no parameters to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description simply restates the tool name as 'get premiere state' without specifying what data the state includes or what scope it covers. It does not distinguish this from sibling getter tools like get_sequence_settings or get_project_info, making it effectively a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool instead of the many other getter tools. No context, prerequisites, or exclusions are provided, leaving the agent to guess the appropriate use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not explain the effect of inverting selection, whether it applies to the timeline or project panel, or any side effects. This is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, but the phrase 'Premiere Pro expanded operation' is filler that wastes the opportunity to convey meaningful details. It is concise but under-specified, earning a middle score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description is the only source of context. It fails to define what 'invert selection' does in Premiere Pro, what selection context it applies to, or how it relates to sibling selection tools, making it insufficient 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.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to explain parameter meaning. The schema already indicates an object with no required fields, and the description adds no unnecessary parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description restates the tool name ('invert selection') and adds only the vague qualifier 'Premiere Pro expanded operation'. It does not specify the resource (clips, tracks, project items) or distinguish the tool from siblings like select_all_clips or deselect_all_clips.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use invert_selection versus other selection tools. There is no mention of prerequisites, selection context, or alternatives, leaving the agent without direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the operation name and does not mention side effects (e.g., whether items are removed from their original bin), required context (e.g., selected items, active bin), or any advanced behavior implied by 'expanded operation'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise, but it is under-specified rather than efficiently informative. It omits critical details and does not earn its place because it only restates the tool name in prose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a mutation operation with no annotations, no output schema, and an unhelpful schema. The description fails to explain what 'expanded operation' means, what inputs are needed, or the effect of the move. It is inadequate for an agent to select and invoke the tool correctly, especially given the large sibling tool list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema is nearly empty (additionalProperties: {}), so there are no explicit parameters. The description does not clarify how to specify which items or which target bin, nor does it mention using currently selected items. The 0-param context is thus not compensated by any textual explanation, leaving the invocation ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('move') and the resource ('items to bin'), which is more specific than a bare name. However, it does not distinguish this from the sibling 'move_item_to_bin' beyond the plural 'items', and the phrase 'expanded operation' adds little clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, such as when moving multiple items versus a single item. No context, prerequisites, or exclusions are provided. The plural in the name hints at multiple items, but the description does not explicitly state this.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of explaining behavioral effects. It only says 'open in source' and does not disclose what happens if no clip is selected, whether it replaces the current source monitor content, or any side effects. This is a significant gap for a tool that likely performs a state-changing operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (one sentence) but includes the filler phrase 'expanded operation' which adds no value. It is concise in length but not in meaning, lacking essential details while including unnecessary wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and zero parameters, the description is severely incomplete. It does not explain what 'open in source' means, the expected outcome, or any conditions or limitations. A tool with no params could still benefit from a clear statement like 'Opens the selected clip in the source monitor.'
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Parameter count is 0, so per rubric the baseline is 4. The schema has no properties, and the description does not need to explain parameters that do not exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('open in source') in the context of Premiere Pro, which likely refers to opening a clip in the source monitor. However, the phrase 'expanded operation' is vague filler and the description does not explicitly mention 'source monitor' or what exactly is opened, leaving room for ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 versus alternatives. Among siblings are close_source_monitor, get_source_monitor_info, and play_source_monitor, but the description does not differentiate or explain the intended use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It merely names the operation without explaining what 'item' refers to (e.g., a project item or source monitor clip), whether a selection is required, or any side effects. This is a slight improvement over a pure tautology but still lacks meaningful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise but under-specified. 'Premiere Pro expanded operation' is filler that adds no value, and the rest simply restates the name. Effective conciseness would still provide clear scope or usage hints, which are absent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description must clarify what 'item' means and how it differs from similar operations. The description is too vague to be complete, especially with siblings like clear_sequence_in_out and set_item_in_out. An agent would struggle to know when to invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. There is no parameter info to add, and the schema itself (with no properties) adequately represents this. The description does not need to compensate for parameter gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Premiere Pro expanded operation: clear item in out' is essentially a tautology, restating the tool name with a generic prefix. It does not provide a specific verb+resource beyond what the name already states, nor does it differentiate from sibling tools like clear_sequence_in_out or set_item_in_out.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. No mention of prerequisites, target item type, or contrast with related operations (e.g., set_item_in_out, clear_sequence_in_out). The agent is left without contextual selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It only vaguely says 'expanded operation' without explaining any side effects, permissions, or return behavior, leaving the agent with no insight into what the tool actually does.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is under-specified rather than concise. It provides no useful information beyond the tool name, so every word fails to earn its place and the description is effectively a tautology.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and a highly vague description, the tool is severely under-specified. The presence of many sibling bin-related tools makes the lack of context even more problematic, as the agent cannot distinguish this tool's purpose or expected outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to clarify parameter usage. The baseline score for zero parameters is 4, and the description adds no conflicting or misleading information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a restatement of the tool name, adding only 'Premiere Pro expanded operation' which is vague and unhelpful. It fails to explain what a smart bin is or how it differs from sibling tools like create_bin.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 create_bin or other bin-related tools. The description gives no context about appropriate scenarios or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for disclosing behavior. It only includes the verb 'get' (already in the name), implying a read operation, but does not disclose output format, side effects, or any limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but poorly structured. The phrase 'Premiere Pro expanded operation:' is filler that does not earn its place, and the rest simply restates the tool name. It reads as a label, not an informative description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description must explain what a timeline summary includes and what the return value looks like, but it does neither. Given the likely complexity of a timeline summary, this is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is 100%, so the schema fully documents the input. The description adds no parameter semantics, but with no parameters to describe, the baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a tautology, restating the tool name with a redundant 'Premiere Pro expanded operation:' prefix. It gives no specific details about what a timeline summary contains or how it differs from sibling tools like get_sequence_structure or get_full_sequence_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not mention use cases, prerequisites, or scenarios where another timeline/sequence inspection tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits, but it only says 'import sequences' with no disclosure of side effects, whether it mutates the project, requires permissions, or what the response format is. 'Premiere Pro expanded operation' is a meaningless phrase that adds no behavioral information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but is under-specified rather than concise. It merely restates the tool name ('import sequences') and adds a vague 'Premiere Pro expanded operation' prefix. No sentence adds real value that isn't already present in the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutation-style tool with no annotations and no output schema, yet the description provides no context about return values, side effects, or how it relates to sibling tools. It is completely inadequate for a tool that likely modifies the project state.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no defined parameters (parameter count 0) and schema coverage is 100% because there is nothing to cover. The baseline for 0 parameters is 4, and there is no missing parameter information for the description to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action 'import sequences' but is vague about scope. It uses 'expanded operation' which is generic and does not clarify what kind of sequencing import occurs or how it differs from the sibling tool 'import_sequences_from_project'. It lacks the specific verb+resource+scope detail needed for clear differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. There is no mention of context, prerequisites, or situations where this tool is preferred over similar tools like 'import_sequences_from_project' or 'import_media'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only restates the name. It does not mention that this overwrites the selected clip with source monitor content, side effects, undo behavior, or any other operational traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, so it is concise, but it is also under-specified, essentially serving as a label. It does not provide useful information beyond the tool name, making it minimally adequate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of Premiere Pro operations, this description is incomplete. It lacks context about the operation's effect, return values, or relationship to other timeline operations. The absence of annotations and output schema further increases the need for descriptive context, which is not met.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema fully covers parameter definitions. The baseline for 0 parameters is 4, and the description doesn't need to add parameter details since there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Premiere Pro expanded operation: overwrite from source' identifies the tool as an overwrite operation using source footage, but it does not explain what this entails in the Premiere Pro context. It fails to distinguish it from sibling tools like 'overwrite_clip' or 'insert_from_source', making it ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. No mention of prerequisites, common use cases, or comparison with sibling tools such as 'insert_from_source' or 'overwrite_clip'. The description provides zero usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of explaining behavior, but it only states the operation. It does not disclose what bin is targeted, what side effects occur, or what constitutes success, which is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is technically short, it is under-specified rather than concise. The single sentence merely repeats the tool name without adding value, so it fails to earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters, no output schema, and no annotations, the description should at least clarify that it operates on the currently selected bin or how the bin is identified. The description provides no such context, making it incomplete for the agent to use reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero parameters, so the baseline is 4. The description adds no parameter-specific information, but there are no parameters to explain. The lack of detail about how the target bin is identified is a behavioral concern, not a parameter semantics issue.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Premiere Pro expanded operation: rename bin' simply restates the tool name with no additional detail. It is essentially a tautology, and it does not distinguish this tool from siblings like rename_track or rename_clip.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. There is no mention of prerequisites, selection requirements, or exclusions, leaving the agent to infer the intended context from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states 'Updates sequence settings' and provides no information about side effects, whether settings are merged or replaced, permissions required, reversibility, or any other behavioral traits. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and to the point, with no wasted words. However, it is under-specified to the point of providing minimal value. It does not take advantage of space to convey important context, so while concise, it is not optimally structured for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a nested settings object, no output schema, and no annotations, yet the description gives no context about its purpose relative to the many sequence-related sibling tools. An agent lacks sufficient information to determine when this tool is appropriate or what impacts it has on the sequence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond what the schema already provides for the sequenceId and settings object. The schema itself defines the fields, so the description's lack of parameter detail is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool updates sequence settings, which is a clear verb+resource. However, 'settings' is vague and doesn't specify which settings or differentiate from the many sibling tools like set_sequence_frame_rate or set_sequence_resolution. It lacks the specificity needed for an agent to understand its exact scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not indicate when to use this tool versus the more specific set_sequence_* alternatives, nor does it mention that it can update multiple settings at once. An agent gets no help in choosing between this and sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose any behavioral traits such as whether the operation is asynchronous, what side effects occur, whether it blocks, or what output to expect. It only restates the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but the prefix 'Premier Pro expanded operation:' is filler and does not earn its place. The core 'start batch encode' is concise, but the additional phrase does not improve clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of encode operations, the tool has no output schema, no annotations, and no parameter definitions, leaving the agent completely in the dark about what inputs are accepted, what action is performed, and what is returned. This is entirely inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero defined parameters, so the schema provides no meaningful information. Per the rubric, a baseline of 4 is appropriate for zero-param tools; the description does not need to explain parameter syntax, though it could mention that no parameters are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'start batch encode,' which gives a clear verb and resource, but it does not specify what 'batch' refers to or how it differs from sibling encode tools. The phrase 'Premier Pro expanded operation' is vague and adds no real meaning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 versus alternatives like encode_project_item, encode_file, or add_to_render_queue. There are no examples, no context, and no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior, but it only restates the tool name and adds an opaque 'expanded operation' label. It fails to mention whether it renames selected clips, what naming pattern is used, whether it is undoable, or the specific side effects on project items versus timeline clips.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but wastes words on the jargon 'Premiere Pro expanded operation' and essentially repeats the tool's name without elaboration. It is under-specified rather than efficiently concise, as it neither front-loads useful details nor earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations, output schema, and parameter documentation, this one-line description is severely inadequate. The agent cannot determine how to invoke the tool, what input to provide, or how it differs operationally from rename_clip, making the description nearly useless for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema declares zero formal parameters yet allows additional properties, so the expected input structure is undefined. The description provides no explanation of the argument object, leaving the agent without guidance on how to specify the rename mapping. Baseline 4 for 0 params is lowered because the schema's additionalProperties suggests hidden parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('batch rename') and resource ('clips'), which clearly differentiates it from the single-item sibling 'rename_clip'. However, the phrase 'expanded operation' is vague and adds little clarity about what the batching actually entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool instead of rename_clip or how to prepare for it (e.g., selecting clips first). No alternatives or exclusions are mentioned, leaving the agent to infer usage context from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full responsibility for behavioral disclosure. It only says 'encode project item' without explaining side effects, duration, output, or whether it is destructive. It adds no meaningful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
While the text is extremely short, the phrase 'Premiere Pro expanded operation' is unnecessary filler. The description is under-specified rather than concise, leaving out essential details about the tool's behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and zero parameters, the description is the sole source of guidance. It fails to explain what 'encode project item' means, how the encoding is performed, or what the expected result is. This is inadequate for a tool with apparently complex functionality.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is an empty object with 100% coverage. The baseline for 0 parameters is 4, and the description does not need to explain parameters. No further parameter information is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('encode project item'), but the phrase 'expanded operation' is vague filler. It does not distinguish this tool from sibling tools like 'encode_file' or 'start_batch_encode', making the exact purpose unclear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as 'encode_file', 'start_batch_encode', or 'export_sequence'. No context, prerequisites, or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it says nothing about side effects, prerequisites, return values, or operational details. It merely labels the operation without explaining what happens when invoked.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief and front-loaded, but it under-specifies the tool's functionality. It reads as a placeholder rather than a useful guide, sacrificing substance for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description must provide context but fails to explain what exporting OMF entails, what the output format is, or any required setup. It is incomplete for a meaningful export operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is complete by definition. The description adds no parameter-specific context, but none is needed; the baseline for zero-parameter tools is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool exports OMF, which is a specific verb+resource, but it adds almost nothing beyond the name. It does not distinguish this tool from sibling export tools like export_aaf or export_as_fcp_xml, so the purpose is clear but undifferentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. It does not mention any exclusions, prerequisites, or when not to use it, leaving the agent to infer usage context from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states only 'expanded operation' and does not mention whether the operation is read-only, what data it returns, or any side effects, leaving the agent completely uninformed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but the opening 'Premiere Pro expanded operation:' is filler that does not add value. It is concise in word count but not in meaningful content, making it minimally acceptable rather than well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema or annotations, the description needs to explain what information is returned and how this 'expanded' version compares to get_item_info. It does neither, leaving the tool under-specified for reliable agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero defined parameters and 100% schema coverage, so the schema already accounts for the input structure. With no parameters to explain, the description is not required to add parameter-level semantics, and the baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool gets project item info, matching the name, but the phrase 'expanded operation' is vague and doesn't clarify what 'expanded' means or how this tool differs from the sibling get_item_info. It names a verb and resource but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like get_item_info, list_project_items, or get_item_info. There is no context, prerequisite, or exclusion information, so an agent cannot determine when this tool is the appropriate choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing side effects or behavioral traits. It only says 'replace clip media' without indicating whether this is destructive, what exactly is modified, or what happens to the original media. No operational details are provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and contains no wasted words, but it is also under-specified and not structured as a complete sentence. It reads as a label rather than an informative summary, so it earns a middle score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool appears in a large list of sibling tools, including 'replace_clip', but the description does not provide any distinguishing context. With no output schema and minimal description, the agent cannot infer what the tool does beyond a vague replacement action. The 'expanded operation' hint is unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters in the schema, and schema description coverage is 100%, so there is nothing for the description to explain. The description does not add parameter semantics, but none are required. The permissive schema (additionalProperties) is not referenced, but the tool has no documented parameters to clarify.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description "Premiere Pro expanded operation: replace clip media" is essentially a restatement of the tool name. The phrase 'expanded operation' is vague and does not clarify what makes this different from the sibling tool 'replace_clip'. It lacks a specific verb or resource description beyond the name itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, exclusions, or context where this tool is preferred. The presence of the sibling 'replace_clip' makes this gap more significant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior, but it only restates the action. It does not explain whether the selection replaces or augments the current selection, how the range is defined, or any side effects. The description is behaviorally opaque beyond the literal verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and to the point, containing no verbose wording. However, the prefix 'Premiere Pro expanded operation:' is unnecessary filler that does not earn its place. The core action is conveyed in a minimal phrase.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and an output schema, and the presence of many sibling selection tools, the description is severely incomplete. It does not define what 'in range' means, how the range is set, or how the selection interacts with existing selections. Critical context is missing for safe and correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema declares zero explicit parameters but allows arbitrary additional properties, and the description does not clarify how the range should be specified. An agent cannot determine whether to pass arguments (e.g., start/end times) or rely on existing state (e.g., in/out points). The description adds no meaning to the permissive schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('select clips'), and 'in range' suggests a defined scope, but the type of range (time, track, etc.) is never specified. It vaguely distinguishes from siblings like select_all_clips or select_disabled_clips, but the ambiguity of 'range' and the filler 'Premiere Pro expanded operation' prevent it from being fully clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the numerous alternative selection tools (select_all_clips, select_disabled_clips, select_clips_by_color, etc.). No prerequisites or contextual triggers are mentioned, leaving the agent without any basis for choosing this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavior. It merely restates the tool name and gives no information about side effects, reversibility, permissions, or what 'override' implies. This is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise but includes the filler phrase 'Premiere Pro expanded operation' which adds no value. The remaining text essentially duplicates the tool name, making it minimally informative rather than genuinely concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter tool with no annotations or output schema, the description still fails to explain what object the aspect ratio override applies to, how it interacts with sequence settings, or any behavioral nuance. It is too terse to be complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter count is 0, so the description does not need to explain parameters. However, the input schema is permissive (allows arbitrary properties), which is ambiguous, but the description does not need to compensate when no parameters are declared.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('set override pixel aspect ratio') but does not specify the target object (clip vs. sequence) and fails to differentiate from similar siblings like set_sequence_pixel_aspect_ratio. It is clear enough to identify the general purpose but vague about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool or how it differs from alternatives. It provides no context about prerequisites, target selection, or reasons to choose this over sibling setter tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the action, omitting critical details such as whether the deletion is permanent, requires user confirmation, removes from disk or just the project panel, or what happens if the item is in use. No safety or side-effect information is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief, but it suffers from under-specification rather than conciseness. It omits essential details about selection context and behavior, making it too sparse to be considered well-structured. A complete description would include these details while remaining compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no annotations and no output schema, the description is incomplete. It does not explain return values, success/failure conditions, prerequisite states, or the operational scope. It is not sufficient for an agent to confidently invoke the tool in a real workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty. A baseline of 4 might apply, but the description fails to clarify how the target project item is identified (e.g., current selection). Without this, the agent cannot reliably know which item will be deleted, making the description insufficiently informative.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'delete project item.' It clearly states the core action, and the singular 'item' implies it operates on one item, distinguishing it from the sibling 'delete_multiple_project_items.' However, it does not explicitly define the item scope (e.g., selected item), so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like delete_multiple_project_items, remove_selected_clips, or delete_bin. The description does not mention prerequisites or context, leaving the agent without decision-support information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden of behavioral disclosure. It does not mention that this is a read operation, whether it requires an active sequence, how large the response might be, or any side effects, leaving the agent completely uninformed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but under-specified. The phrase 'expanded operation' is filler and the sentence merely repeats the tool's name without earning its place, making it an example of under-specification rather than genuine conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's name implies a comprehensive response and there is no output schema or annotations, the description should explain what 'full sequence info' includes, the return format, or any operational context. It does none of this, making it inadequate for a potentially complex operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds no parameter information, but none is needed since the schema already defines an empty object.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'get full sequence info', which is a clear verb+resource combination indicating the tool retrieves complete sequence information. However, it does not distinguish this from sibling tools like get_sequence_settings or get_sequence_structure, and 'expanded operation' adds no clarifying detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. The description only restates the tool's name and offers no context about prerequisites, active sequence requirements, or scenarios where this is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It fails to state what the operation does beyond 'import', with no information on side effects, required context, or return behavior. This is essentially a restatement of the tool name with no added transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one sentence), but it is under-specification rather than effective conciseness. It repeats the tool name and adds no valuable information. The sentence does not earn its place because it provides no unique value over the tool name itself.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and no parameters, the description needs to explain the operation's purpose, context, and effects. It fails to do so, providing only a tautological phrase. The tool is completely underequipped to guide an agent on how to invoke or interpret the operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema provides no parameter details. According to the rubric, 0 parameters sets a baseline of 4. The description adds no parameter-specific information, but none is needed. However, it does not explain how the image sequence is specified (e.g., through a file path or selection), which slightly detracts from clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly indicates the tool imports an image sequence, using a specific verb and resource. It distinguishes from sibling tools like import_sequences by specifying 'image sequence' rather than generic sequences. However, the phrase 'expanded operation' is unclear and adds no substantive meaning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. The description does not mention any prerequisites, context, or exclusions. The user is left to infer that it is for importing image sequences without any comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It merely restates the tool name and provides no additional detail about what 'get next edit point' does—whether it returns a time, moves the playhead, or has side effects. This is essentially a tautology and gives the agent no behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but includes filler like 'Premiere Pro expanded operation,' which adds no value and is redundant given the API context. It is under-specified rather than concisely complete, so it fails the standard of every sentence earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should explain what the tool returns or accomplishes. It only says 'get next edit point,' which is ambiguous—does it return a timecode? Move the playhead? Select the edit? Without this context, the description is incomplete for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The empty schema fully covers the parameter situation, and the description doesn't need to add anything. No parameter documentation deficit exists.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'get next edit point' is a specific verb+resource. However, it does not distinguish this from sibling tools like move_playhead_to_edit or get_clip_at_playhead, so it misses the differentiation required for a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description simply states what it does without any context, prerequisites, or exclusions, leaving the agent to guess when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden, but it merely restates the operation without disclosing side effects, how the target track is chosen, or what happens when moving a clip. It adds no behavioral context beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but 'expanded operation' is vague filler and no additional structure or clarification is provided. It is not bloated, yet is under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations, no output schema, and an empty input schema, so the description is the only source of context. It fails to explain how the clip or track is identified, whether it operates on the current selection, or how it relates to siblings like 'move_clip'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The context indicates zero parameters and 100% schema description coverage, so there are no parameter semantics to document. The description doesn't mislead, and the baseline for 0-param tools is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the primary action ('move clip to track') with a clear verb and resource, making it understandable. However, 'expanded operation' is vague and there is no distinction from similar sibling tools like 'move_clip' or 'add_to_timeline'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives, nor any preconditions or exclusions. The description does not mention selection requirements, target track specification, or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only restates the tool's basic function and gives no information about scope, effects on references, undoability, or whether it operates on selections or requires an explicit clip ID.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (one sentence) but includes the filler 'Premiere Pro expanded operation' which does not earn its place. It is not wordy, but it is under-specified rather than efficiently concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and an uninformative schema, the description is far from complete. It does not address return values, side effects, selection context, or how the rename is applied, making it insufficient for reliable tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is an open object with no defined properties (0 parameters), so the description should clarify expected inputs, such as clip ID and new name. It does not, leaving the schema uninterpretable and the agent without essential invocation details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('rename') and resource ('clip'), which distinguishes it from track/bin renaming tools. However, the phrase 'expanded operation' is vague and adds little clarity, and it does not differentiate from closely related operations like batch_rename_clips or rename_project_item.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as batch_rename_clips or rename_project_item. No prerequisites, contexts, or exclusions are mentioned, leaving the agent to guess the appropriate scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description offers no behavioral details. It does not disclose whether the scale applies to a selected clip, if the operation is undoable, or any side effects. The unannotated description carries full responsibility and fails to disclose anything.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase with no redundant words, making it highly concise. It is appropriately sized for the minimal information it contains, though the lack of structure is a minor issue.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the minimal schema, no annotations, no output schema, and several similarly named sibling tools, the description is far from complete. It does not clarify the operation's scope, parameterization, or how to choose it over set_uniform_scale or set_scale_width_height, leaving an agent inadequately informed for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters defined in the schema, there are no parameter semantics to explain. According to the rubric, a tool with 0 parameters receives a baseline of 4. However, the tool name implies a scale value is needed, which is a latent ambiguity not addressed by the description or schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'set' and resource 'clip scale', clearly indicating an action. However, it does not distinguish this tool from closely named siblings like set_uniform_scale or set_scale_width_height, so it lacks explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description provides no context about prerequisites, selection requirements, or situations where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It only restates the tool name without explaining what 'unlink' does, whether it requires a selection, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but it merely repeats the tool name without adding informative content. It does not earn its place by contributing value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (no params, no output schema), the description should at least clarify what 'unlink' means in Premiere Pro. It fails to provide useful context, leaving the agent to guess the operation's effect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds no parameter info, but none is needed as the schema is empty.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and object: 'unlink selection' in Premiere Pro. It is distinct from siblings like 'link_selection' but is somewhat tautological, relying on the tool name for meaning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as 'link_selection' or other selection tools. There is no context about prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It merely restates the tool's name without explaining side effects, such as whether a new sequence is created in the current project, if it becomes active, or if any existing state is modified. This is insufficient for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and front-loaded, but the phrase 'Premiere Pro expanded operation' is filler that adds no operational value. The core 'create sequence from preset' is concise but under-specified, lacking any detail that would earn the sentence's place beyond repeating the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With zero parameters and no output schema, the description should still cover the tool's purpose and behavior. It only states the obvious action, leaving the agent without understanding what a 'preset' refers to, whether there are prerequisites, or what the outcome will be. The description is too minimal for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter count is 0, and the input schema defines no specific parameters, so the baseline is 4. The description does not need to explain parameters, but it also doesn't clarify the confusingly permissive schema (additionalProperties allowed). Since there are no actual parameters, the description adds no parameter semantics, but this is acceptable given the zero-parameter context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action clearly: 'create sequence from preset.' This is a specific verb+resource combination that distinguishes it from siblings like create_sequence and create_sequence_from_clips, though it doesn't elaborate on what a 'preset' entails. The name itself already carries most of the differentiation, so the description is somewhat redundant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like create_sequence, create_sequence_from_clips, or import_sequences. The description does not mention prerequisites, exclusions, or any context suggesting the appropriate scenario. With numerous sibling tools, this lack of usage guidance is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It only says 'get bin contents' and does not disclose whether the operation is read-only, what constitutes 'bin', whether it requires a currently selected bin, or what the return payload looks like. Minimal behavioral disclosure beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but it includes filler text 'Premiere Pro expanded operation' that adds no value. The core phrase 'get bin contents' is clear, but the overall structure is under-specified rather than efficiently concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no annotations and no output schema, the description should at least indicate what 'bin' refers to, whether it operates on the selected bin or all bins, and what kind of information is returned. This lacks that context, making it insufficient for confident tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so the schema is trivially covered and the baseline is 4. The description adds no parameter information, but that is acceptable given there are none to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'get bin contents' which identifies a verb and resource, but it is vaguely phrased as 'Premiere Pro expanded operation' without explaining what 'expanded' means or specifying which bin/scope is involved. It does not clearly distinguish from similarly named tools like get_item_info or list_project_items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. There is no mention of prerequisites, context, or when another tool might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only says 'get version info' without indicating whether the operation is read-only, requires a running Premiere Pro instance, or what the response format looks like. This is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise but includes a boilerplate prefix 'Premiere Pro expanded operation:' that adds no value. The core phrase 'get version info' is minimal and efficient, but the prefix could be removed without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and a vague description, the tool lacks context. It doesn't clarify what version information is returned, whether the tool depends on a connection, or how it relates to other tools like 'verify_premiere_connection'. For a simple tool, the description is still incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter description needed. The description adds no parameter semantics, but for a parameterless tool this is acceptable. The empty schema with propertyNames is odd, but it doesn't affect parameter clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('get') and the resource ('version info'), making the purpose clear at a basic level. However, it doesn't elaborate on what kind of version info (app, project, etc.) or distinguish itself from similar tools, though no sibling tool overlaps directly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 versus alternatives. It doesn't mention typical use cases, prerequisites, or context in which the tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior, but it only restates the operation name. It does not mention whether the action modifies the active sequence, requires user confirmation, or what the return value is; this is a significant transparency gap for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but it is essentially a restatement of the tool name ('rename track'), providing no new information. This under-specification is not effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations, no output schema, and an empty input schema, yet the description does not explain expected inputs, return values, or side effects. An agent would have no way to invoke this tool correctly, making the description completely inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines no parameters (0 required), so the baseline is 4. The description adds no additional meaning about how the target track is identified, but this is not required by the rule given zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation as 'rename track,' providing a specific verb and resource. However, it doesn't differentiate from sibling tools like rename_clip, rename_bin, or batch_rename_clips, and the phrase 'Premiere Pro expanded operation' adds no distinguishing value.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use rename_track versus alternative renaming operations, nor any prerequisites such as having an active sequence or selected track.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It offers essentially nothing beyond the tool name—no mention of which clips are affected, whether a selection is required, whether changes are keyframable, or any side effects. The phrase 'expanded operation' is vague and unexplained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
It is a single concise sentence with no wasted words, but the prefix 'Premiere Pro expanded operation:' adds little value and could be omitted. Overall, it is efficient but not optimally structured for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is far too thin. It omits critical context such as how the clip is identified, the expected value range, and whether the operation is reversible. It barely meets the minimum for understanding the tool's function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema declares zero parameters, so the baseline is 4, but the description fails to clarify how the opacity value or target clip is passed, especially since the schema permits arbitrary properties. The description adds no parameter information to compensate for this ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: set clip opacity in Premiere Pro. The verb-resource pairing is specific, and the property name distinguishes it from sibling clip property setters, though it doesn't elaborate on scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 other clip property setters, nor any context about prerequisites, target selection, or alternatives. The description simply restates the function without positioning it among the many sibling set_* tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must disclose behavior. It merely restates the tool's name and adds the generic label 'expanded operation', offering no information about side effects, prerequisites, or how the override interacts with other settings. This is essentially a tautology.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded, but the phrase 'Premiere Pro expanded operation' adds no meaningful information and could be omitted. It is concise but under-specified, veering into vagueness rather than efficient clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and zero parameters, the description is the only source of context. It fails to explain what 'override' means, the effect on the sequence or clip, or any constraints. The tool is left entirely unclear despite being a simple setter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema shows no required or optional inputs. With 0 parameters, the baseline is 4, and there is nothing for the description to add beyond what the schema already indicates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as setting an override frame rate, using a specific verb+resource construction. It distinguishes from siblings like set_sequence_frame_rate by including 'override', but it does not explicitly compare to any sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 rather than alternatives such as set_sequence_frame_rate or set_override_pixel_aspect_ratio. The phrase 'expanded operation' is vague and does not convey any usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It simply restates the function without explaining side effects (e.g., changes to project settings), reversibility, permissions, or what happens when invoked. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but the phrase 'Premiere Pro expanded operation' is unnecessary filler. It does not provide substantive information beyond the tool's name, making it under-specified rather than genuinely concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of parameters and output schema, the description could be sufficient, but it fails to clarify the operation's scope or its relationship to set_scratch_disk_path. The tool is a mutation with no annotation coverage, leaving key questions unanswered, so the description is minimally adequate at best.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema has no properties, so the description does not need to explain parameter semantics. Per the baseline for 0-parameter tools, a score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (set) and the resource (project scratch disk), making the purpose understandable. However, it does not differentiate itself from the sibling tool set_scratch_disk_path, and the phrase 'expanded operation' adds vagueness rather than specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not indicate when to use this tool versus alternatives like set_scratch_disk_path, nor does it mention any prerequisites or contexts. There is no mention of exclusions or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It provides no information about return format, whether the operation is read-only, error conditions, or search semantics, adding nothing beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at one sentence, but the phrase 'Premiere Pro expanded operation' is filler and the overall terseness borders on under-specification rather than efficient communication.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too sparse given the lack of annotations, output schema, and defined parameters. It does not explain return values, limitations, or relationship to sibling tools, leaving the agent without enough context for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is an empty object with 0 params, so the description's mention of 'media path' is the only hint of an implicit parameter. It adds some meaning beyond the schema but does not specify the parameter's type, requiredness, or format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
States clearly that the tool finds items by media path, giving a specific verb and resource. However, it lacks differentiation from sibling tools like find_project_item_by_name or search_project_items, and the phrase 'Premiere Pro expanded operation' adds no substantive meaning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. The description simply states what it does without mentioning context, exclusions, or comparisons to similar find/search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of transparency. It merely restates the tool name with a generic prefix, offering no information about return values, error behavior, or prerequisites like an active sequence or playhead position.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and to the point, with no filler. However, the prefix 'Premiere Pro expanded operation' is redundant with the tool's context and adds little structural value, preventing a top score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and an output schema, the description is too sparse. It does not specify what is returned (e.g., clip metadata), what happens when no clip is at the playhead, or which sequence/track context is referenced, leaving significant gaps for such a simple getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema provides no parameter documentation. The baseline of 4 applies, and the description correctly avoids inventing parameter details that do not exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the clip at the playhead, using a specific verb and resource. It does not, however, elaborate on the scope (e.g., current sequence, selected track) or distinguish it from similar siblings like get_clip_at_position, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as get_clip_at_position or get_selected_clips. The phrase 'expanded operation' hints at a low-level context but does not explain when it should be invoked.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it provides no behavioral details. It does not disclose what is returned (e.g., speed as a float, units), whether it operates on the selected clip, or any side effects or requirements. Minimal behavioral transparency is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence but essentially restates the tool name ('get clip speed') and adds the vague prefix 'Premiere Pro expanded operation'. This under-specification does not earn its place; it is too terse to be helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a getter with no annotations or output schema, the description leaves critical context unexplained. It does not specify what input it uses (e.g., current selection), what it returns, or how it behaves, making it incomplete even for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is essentially empty. The baseline for zero parameters is 4, and while the description doesn't add param-related meaning, there are no parameters to describe.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly uses 'get' + 'clip speed' as the verb and resource, making the tool's purpose obvious. However, it does not explicitly distinguish it from sibling tools like 'set_clip_speed_qe' or 'speed_change', though the name is fairly unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, nor any mention of prerequisites (e.g., a selected clip). The description simply states what it does without contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It does not state whether the operation is read-only, what it returns, whether it scans the entire project, or if it requires any selection. The name implies a getter, but that is not explicitly declared, and no additional behavioral context is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, but 'Premiere Pro expanded operation' is filler that does not contribute meaning. The core phrase 'get duplicate media' is essentially the name repeated. It is concise but not optimally structured or informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and a vague description, the tool lacks context about its return value, scope, or how it relates to similar tools. This is inadequate for an agent to understand the tool's full behavior or when to invoke it among numerous siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no defined parameters and appears to accept arbitrary properties, but context indicates zero expected parameters. Schema coverage is 100%, so no parameter documentation is required. The description adds no information about optional arguments, but with no real parameters, this is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a verb ('get') and resource ('duplicate media'), making the tool's basic purpose understandable. However, it does not differentiate from sibling tools like 'consolidate_duplicates' or 'get_unused_media', and the phrase 'expanded operation' is vague and adds little clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. No mention of prerequisites, context, or exclusions. The description simply states the action without any usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only says 'remove effect by name.' It does not explain whether the name must be exact, whether it affects selected clips or the whole sequence, what happens if multiple effects share the name, or any destructive side effects beyond removal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but 'Premiere Pro expanded operation' is unnecessary boilerplate that adds no operational value. The meaningful content—'remove effect by name'—is concise, but the filler prevents a higher score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutation tool with no annotations and no output schema, so the description should provide more context about scope, matching rules, and side effects. It does not, and the presence of sibling tools like remove_effect and remove_all_effects makes the lack of differentiation a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema declares zero formal parameters, so the baseline is 4, but the description's 'by name' implies an undocumented parameter for the effect name. The agent cannot determine how to specify that name (e.g., property key, value format), so the description only partially compensates for the schema's silence.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action: 'remove effect by name,' which distinguishes it from broad siblings like remove_all_effects and generic remove_effect. However, 'Premiere Pro expanded operation' is vague filler, and the target clip/sequence context is unstated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to prefer this tool over remove_effect or remove_all_effects, nor any prerequisites such as having a clip selected or an active sequence. The description only says what it does, not when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description discloses zero behavioral traits. It does not state what 'anti alias quality' affects, whether it applies to a clip, sequence, or global setting, what side effects occur, or what the expected return value is. The verb 'set' implies mutation, but that is not sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and front-loaded, wasting no words. However, the qualifier 'expanded operation' is unhelpful filler and could be removed without loss, making it slightly less concise than necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and no parameter documentation, the description is inadequate. It fails to explain the scope of the operation (clip, sequence, project), the range of quality values, or any side effects, leaving a significant gap for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline of 4 applies. The description adds no parameter-specific detail, but with no parameters needed, the schema coverage is complete and the lack of parameter information is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('set') and the target ('anti alias quality') within Premiere Pro. However, the phrase 'expanded operation' is vague and adds little distinction from other set_* sibling tools, though the resource name is specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. The description is purely declarative with no mention of context, prerequisites, or exclusions, leaving the agent without decision-making information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavior. It does not mention that this is a mutating operation, whether it requires an active sequence, what happens to existing settings, or how resolution is specified. The description is too vague to inform the agent about side effects or constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but it is under-specified rather than appropriately concise. It essentially restates the tool name and adds the vague 'expanded operation' phrase. The single sentence does not earn its place because it contributes no additional clarity or structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the mutation nature and lack of output schema or annotations, the description is incomplete. It does not explain the effect of the operation, how the resolution is determined, or any side effects. The agent would have to guess about the tool's behavior and relationship to other sequence-setting tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 100% coverage, so the baseline is 4. The description does not add parameter information, but none is needed since the tool takes no formal parameters. It maintains the baseline without adding confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'set sequence resolution'. It uses a specific verb+resource pattern, though it doesn't differentiate from sibling tools like set_sequence_settings or set_sequence_pixel_aspect_ratio. The phrase 'Premiere Pro expanded operation' adds no meaningful distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. The description lacks any context about prerequisites, active sequence requirements, or interaction with other sequence settings. It merely states what it does without indicating appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only states the basic action and gives an example, but does not disclose behavior such as whether clips are modified, what happens if clips are not adjacent, whether existing transitions are replaced, or any side effects. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the verb and key information. No wasted words; it earns its place as a concise summary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a timeline mutation with no output schema and no annotations. The description is too minimal to cover important contextual details like adjacency validation, error cases, or interaction with existing transitions. It is adequate for a simple case but not complete for reliable agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all 4 parameters (100% coverage), so the description adds minimal value. The example 'cross dissolve' for transitionName is helpful but does not meaningfully extend the schema explanations. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (adds a transition) and the target resource (between two adjacent clips on the timeline). It is specific and distinguishes from generic 'add' tools, though it does not explicitly differentiate from the similar sibling 'add_transition_to_clip'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 add_transition_to_clip or batch_add_transitions. It implies the requirement of adjacent clips but does not state prerequisites, when not to use, or fallback options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavior, but it only states the basic action. It omits whether effects are replaced or stacked, whether changes are undoable, or what happens if the effect name is invalid. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that is front-loaded and easy to scan. It contains no filler, though it is terse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three parameters including a nested object, no annotations, and no output schema, the description is too sparse. It lacks information about the effect's placement in the signal chain, parameter format, or return behavior, leaving the agent with incomplete guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all parameters with descriptions (100% coverage), so the baseline is 3. The description adds no additional parameter semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action and target ('Applies an audio effect to a clip') with a specific verb and resource. It distinguishes from the general 'apply_effect' sibling but does not explicitly mention that it operates on a single clip, which could be confused with 'apply_audio_effect_to_all_clips'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 instead of alternatives like 'apply_effect' or 'apply_audio_effect_to_all_clips'. There is no mention of prerequisites, effect selection, or workflow context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavioral traits. It only says 'applies basic color correction adjustments' without clarifying whether the operation is destructive, reversible, additive, or if it affects the original clip. No return behavior or side effects are mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that immediately states the tool's function. It is concise and front-loaded with no extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 9 parameters and no output schema, this description is incomplete. It does not explain whether adjustments are cumulative, whether all parameters are optional, what happens to existing adjustments, or how the tool reports success/failure. The minimal text leaves significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each parameter has a clear definition. The description adds no extra meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's action ('Applies') and object ('color correction adjustments to a video clip'), making its core purpose clear. However, it does not distinguish it from sibling tools like apply_lut or set_color_value, so it lacks differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. There is no mention of prerequisites, compatibility, or typical use cases, leaving the agent to infer context from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It simply states 'delete bin' without indicating whether the operation is reversible, whether it fails if the bin is non-empty, or what happens to contained items. This is insufficient for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, but the phrase 'Premiere Pro expanded operation' is boilerplate that adds little value. It is concise but lacks substantive content beyond restating the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive action like deleting a bin, the description should clarify consequences and preconditions. It is a single minimal sentence with no mention of empty-bin requirements, undo behavior, or effects on child items, making it incomplete even for a simple zero-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is effectively empty. The description does not need to explain parameter semantics, and no gap exists.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('delete') and resource ('bin'), distinguishing it from sibling tools like create_bin and rename_bin. The phrase 'expanded operation' is somewhat vague but does not obscure the core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, nor are any prerequisites or side effects mentioned. The description offers no context for when deletion is appropriate or safe.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It implies a read operation via 'get' but does not disclose return format, error behavior, or whether any side effects occur. The 'expanded operation' phrase is ambiguous.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is short and front-loaded, but the prefix 'Premiere Pro expanded operation' adds noise without value. It could be improved by removing prefix and adding a more descriptive phrase.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a simple getter with no output schema or annotations, the description should at least specify which color space (sequence, clip, project) and what the return value represents. Current description is vague, making it incomplete for an agent to invoke safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has zero parameters, and schema is empty; the description adds nothing necessary. Baseline 4 applies because no parameter documentation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a getter for color space, which distinguishes it from siblings like get_color_label and set_color_value, though it omits what exactly 'color space' refers to in Premiere Pro.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives; it only states what it does without context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It merely says 'expanded operation' without disclosing whether the operation is read-only, what the return value looks like, or any side effects. This is insufficient for a tool that appears to be a getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, but the phrase 'Premiere Pro expanded operation' is redundant filler that repeats the tool name without adding information. The essential content is just 'get export file extension,' so it's concise but not particularly informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even for a simple getter, the tool lacks an output schema, so the description should explain what the returned file extension represents and any contextual prerequisites. The phrase 'expanded operation' hints at complexity but provides no concrete details, leaving the agent without enough context to confidently invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 explain parameter semantics. Per the baseline for 0 params, a score of 4 is appropriate. However, the schema allows additional properties, and the description doesn't clarify that no arguments are expected.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'get export file extension,' which is a specific verb+resource. However, the prefix 'Premiere Pro expanded operation' is vague and doesn't clarify what 'expanded' entails, nor does it explicitly distinguish this from sibling getters like 'get_encoder_presets.' The core purpose is clear from the name, but not enhanced.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool, what scenarios it applies to, or how it differs from alternatives. No prerequisites, exclusions, or contextual cues are provided. The description offers zero usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavioral traits. It does not state whether the operation is read-only, what data it returns, whether it is expensive, or any side effects. 'Premiere Pro expanded operation' adds no meaningful behavioral information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded, but the phrase 'Premiere Pro expanded operation' is filler that does not earn its place. It is under-specified rather than genuinely concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should explain what 'full project overview' includes or returns. It does not enumerate contents, clarify overlap with get_project_info, or provide any operational context, making it incomplete for a tool of this scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema already covers all possible inputs. The description adds no parameter details, but none are needed, so this is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('get') and resource ('full project overview'), making the tool's purpose identifiable. However, it does not distinguish this from sibling tools such as get_project_info or get_timeline_summary, and the phrase 'expanded operation' is vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It does not mention any context, prerequisites, or exclusions, leaving the agent to infer usage solely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it does not. It fails to mention what the tool returns (e.g., paths), whether it requires an open project, or any side effects. The name implies a read-only operation, but the description adds no behavioral context beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately short, but the 'Premiere Pro expanded operation:' prefix is unnecessary boilerplate that adds no information. The core content is just the tool name, making it concise but not informative beyond the name itself.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain what the tool returns, but it does not. It also gives no context about the project state or how the returned scratch disk information is structured. The tool is simple, but the description fails to provide essential context for an agent to know what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema covers them vacuously. The description does not need to explain parameters, and the baseline of 4 applies because there are no parameters to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets project scratch disks, distinguishing it from the sibling 'set_project_scratch_disk' via the get/set contrast and plural 'disks'. However, it essentially restates the tool name with the boilerplate prefix 'Premiere Pro expanded operation:', adding minimal explanatory value.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. There is no mention of context, prerequisites, or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavior. It implies a read operation but does not mention whether an active sequence is required, what marker types are supported, or what the return structure looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence and front-loads the core function. The 'Premiere Pro expanded operation:' prefix is somewhat redundant but not significantly harmful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and minimal description, the return format and operational context are left unspecified. It does not explain marker types, active sequence requirements, or how this differs from sibling marker tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema declares zero parameters, so the baseline is high, but the description's 'by type' suggests a type argument or behavior not captured in the schema. This ambiguity makes correct invocation unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation is to get sequence markers by type, which is specific and somewhat distinguishes it from clip-marker tools. However, it does not clarify whether 'by type' means filtering by a type argument or grouping markers by type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool instead of alternatives like get_clip_markers or list_markers. There are no explicit conditions, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits on its own. It only says 'get total clip count', providing no information about return type, potential errors, or whether it reads from the active sequence or the project. The 'expanded operation' phrase is uninformative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and front-loaded, but the phrase 'Premiere Pro expanded operation' is boilerplate filler that adds no value. It would be more concise if it simply said 'Get the total clip count.' The under-specification undermines efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no parameters, so the description must clarify what 'total clip count' refers to and what the result represents. The description leaves this ambiguous, making it incomplete for an agent trying to decide whether to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description is not required to explain parameter semantics. The input schema is minimal and the baseline of 4 applies because there are no parameters to clarify.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('get') and the object ('total clip count'), accurately reflecting the tool's function. However, it does not differentiate from similar sibling tools like get_sequence_count, and the phrase 'expanded operation' adds no specific scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, no prerequisites, and no mention of what context it applies to (e.g., project vs sequence). The description simply restates the tool name without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'imports sequences' without explaining side effects like whether the source project is modified, whether existing sequences are overwritten, or what happens to the current project state. This is a significant gap for a modification operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, front-loaded with the core purpose. It is appropriately concise for the scope of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal and lacks essential context for an import operation: no mention of return values, side effects, failure modes, or distinction from closely related sibling tools. Given no annotations and no output schema, the description is insufficient for an agent to safely invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes both parameters (projectPath and sequenceIds) with clear descriptions, achieving 100% schema coverage. The tool description adds no additional meaning beyond what the schema already provides, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool imports sequences from another Premiere Pro project file, using a specific verb and resource. It distinguishes from importing media or creating sequences, though it doesn't explicitly contrast with the sibling tool 'import_sequences'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 'import_sequences' or 'import_media'. The description only states the action without context on prerequisites or scenarios where this tool is the preferred choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It does not disclose whether the attach action modifies existing state, if it overwrites existing proxies, or whether check and get_path are read-only. It also omits any side effects or permission requirements despite describing a potentially mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the tool's purpose and lists the three actions clearly. There is no wasted wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should explain what the check and get_path actions return, and clarify the behavior of attach. It does neither, leaving the agent without critical information about return values and side effects for a multi-action tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage for all parameters, including the enum of actions and the note that proxyPath is required for attach. The description adds minor context by naming the three actions but does not go beyond the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific resource (project item) and three specific proxy operations: check, attach, and get path. However, it does not distinguish itself from sibling tools like has_proxy or detach_proxy, which may perform some of the same operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 versus alternatives such as has_proxy, detach_proxy, or attach_custom_property. It simply states what it does without clarifying the preferred context for this combined operation vs. the dedicated sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the action without revealing side effects (e.g., ripple behavior, overwriting clips), undoability, or prerequisites. No annotation contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant words. It front-loads the action and is appropriately sized for the minimal information it conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, and the presence of related sibling tools, the description is insufficiently complete. It doesn't explain the function's impact on the timeline or how it differs from other move/set position tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (all three parameters have descriptions). The tool description adds little beyond the schema, merely restating that a position change occurs. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Moves') and identifies the resource ('a clip') and target ('different position on the timeline'). It is unambiguous about the core action, though it doesn't directly differentiate from the sibling tool 'move_clip_to_track' or clarify whether 'position' includes track changes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like 'move_clip_to_track' or 'set_clip_position'. The description neither states preferred contexts nor exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only states the action without disclosing any behavioral details. It does not explain what 'expanded' means, whether playback toggles, or if an open source clip is required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded, but it omits important context. Being concise is good, but this is under-specified rather than efficiently complete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the simple nature of the tool, the ambiguity of 'expanded operation' and the lack of differentiation from sibling tools make the description incomplete. It does not explain what makes this operation expanded or when this specific playback tool should be used.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description does not need to explain parameter semantics since there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'play source monitor' which identifies the verb (play) and resource (source monitor) clearly. However, the phrase 'expanded operation' is ambiguous and does not clarify how this differs from other playback tools like play_timeline.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as play_timeline or open_in_source. There is no mention of prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses no behavioral traits: no mention of what 'all effects' applies to, whether it's destructive, if a selection is required, or if the operation is undoable. 'Premiere Pro expanded operation' is vague and uninformative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and quite short, but the prefix 'Premiere Pro expanded operation' adds no value and wastes words. It is concise but incomplete, omitting essential scope context. The core message is clear but could be more efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters, the description still needs to specify what 'all effects' applies to. It doesn't indicate whether it operates on selected clips, all clips in the timeline, or a specific item, nor does it mention prerequisites like having a selection. Given the many sibling tools, this lack of context makes the description inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and the schema is an empty object. The baseline for 0 parameters is 4. The description adds no parameter information, but none is needed given the absence of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action: remove all effects. It is specific about the scope ('all' vs individual effects), but it doesn't specify the target (e.g., selected clip, all clips) and doesn't explicitly differentiate from sibling tools like remove_effect and remove_effect_by_name beyond the 'all' qualifier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, what prerequisites exist (e.g., selection), or exclusions. The description only provides a bare action statement without any contextual usage hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only restates the action without explaining what constitutes a 'range,' whether it affects all properties or just the selected one, or any side effects such as deletion confirmation or undo behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and to the point, but the phrase 'Premiere Pro expanded operation' is filler that does not add substance. It could be simplified to just 'Remove keyframe range.'
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of sibling tools like 'remove_keyframe' and 'get_keyframes,' the description should clarify how a range is specified and whether this is a destructive or reversible operation. The current description leaves too much unspecified for a tool that mutates keyframe data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the description is not expected to explain parameter meanings. The baseline of 4 applies, and the description does not introduce any parameter-related confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'remove keyframe range,' which clearly indicates the action of removing keyframes over a range. The word 'range' distinguishes it from the sibling tool 'remove_keyframe,' though the phrase 'expanded operation' adds no clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 instead of 'remove_keyframe' or how the range is defined. The description does not mention prerequisites such as selecting a clip or setting a playhead range.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It states 'remove' but does not reveal whether the operation is destructive, ripple-deletes, removes from the timeline or project, or supports undo. The ambiguity is significant for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence and is front-loaded with the action, but the prefix 'Premiere Pro expanded operation' is boilerplate that adds no information. It is concise but contains a filler phrase that does not earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no output schema and no annotations, the description should clarify the scope of removal (e.g., timeline vs project, ripple vs non-ripple). It does not, and the presence of sibling tools with similar removal semantics makes this ambiguity problematic.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty. The baseline for 0 params is 4; the description adds no parameter details, but none are needed since no parameters exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb+resource construction ('remove selected clips') that states what the tool does. However, it does not distinguish this from sibling removal operations like lift_selection, extract_selection, or ripple_delete, and the phrase 'expanded operation' is generic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus other removal or selection tools. There is no mention of context, prerequisites, or alternative tools, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only states the basic action. It fails to disclose whether the operation is destructive, reversible, affects audio pitch by default, or what happens to existing clip properties. The existence of the maintainAudioPitch parameter is not mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It efficiently conveys the primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given two parameters and no output schema, the description should explain the effect on audio pitch and any prerequisites or side effects. It only states the base action, leaving the agent without enough context to confidently invoke the tool, especially regarding the optional maintainAudioPitch parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters, so the baseline is 3. The description adds no additional parameter context; the schema already documents clipId and maintainAudioPitch with their meanings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'reverses' with a clear resource 'the playback of a clip', making the core function obvious. However, it doesn't differentiate from related tools like speed_change or set_clip_speed_qe that also modify clip playback characteristics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 versus alternatives such as set_clip_speed_qe or speed_change. The intended context is only implied by the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only says 'select all clips' without disclosing whether the existing selection is replaced or extended, whether it applies to the active sequence, or how track targets are handled. This operation mutates selection state, so such details are important.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is terse but includes the wasteful prefix 'Premiere Pro expanded operation:' which adds no value. The action 'select all clips' is direct and would be clearer without this filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks essential context: it does not specify whether selection is cleared or additive, does not mention the active sequence, and does not indicate behavior regarding disabled clips or track targeting. Without annotations or an output schema, this minimal description is incomplete for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, making semantic ambiguity minimal. The schema is empty and fully covered, and the description need not elaborate on parameter syntax. A score of 4 reflects the baseline for no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'select all clips'. It is distinct from siblings like 'deselect_all_clips' by the affirmative action, though it does not explicitly differentiate from 'select_clips_in_range' or 'select_disabled_clips'. The 'Premiere Pro expanded operation' prefix adds little but does not confuse the core meaning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as 'select_clips_in_range' or 'select_disabled_clips'. There is no mention of prerequisites, intended context, or situations to avoid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure, but it only states the basic effect. It does not mention side effects (e.g., changing the active sequence), requirements (e.g., sequence must exist), error handling, or return values, leaving significant behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that states the tool's purpose without extraneous information. It is appropriately front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's simplicity, the description is very sparse. It lacks contextual information about when to use this tool relative to many sequence-related siblings, and there is no mention of behavioral implications. The schema covers the parameter, but the description does not compensate for the missing usage and transparency details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the single parameter sequenceId, explaining it as 'The ID of the sequence to activate'. The description adds no additional meaning beyond the schema, 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.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Sets') and the resource ('the active sequence in the project'), making the tool's purpose unambiguous. However, it does not differentiate from sibling tools like get_active_sequence or set_sequence_settings, so it lacks explicit sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 or when to prefer alternatives. There are no cues about prerequisites, such as needing an open sequence or valid sequenceId, nor any exclusions or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It only restates the action without revealing any side effects, requirements, reversibility, or how the operation behaves in different contexts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise but includes the filler phrase 'Premiere Pro expanded operation:' which does not earn its place. The essential content is a single phrase, so it is not maximally well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutation tool with no annotations, no output schema, and no parameter details. The description is too sparse to be complete; it does not explain what the anchor point is, how it is set, or any requirements for the clip/sequence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters declared, so the baseline is 4. The description does not need to cover parameter details, though the schema allows arbitrary additional properties, which is left unexplained but not contradictory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation: 'set clip anchor point.' This is a specific verb+resource that distinguishes it from other set_clip_* tools like set_clip_position or set_clip_scale. The prefix 'Premiere Pro expanded operation:' adds no value but does not detract from clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. The sibling list contains many set_clip_* operations, but the description gives no context for selecting this one, nor any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits but only says 'Sets Motion properties.' It does not explain whether unspecified properties are left unchanged or reset, whether the clip must be in a sequence, or what happens on failure. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the verb and resource, listing properties in parentheses. It is concise and free of filler, though it lacks structure like bullet points or examples. It earns its place but doesn't go beyond a minimal statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a nested object and multiple sibling setters, but the description offers no guidance on usage, precedence, or behavior when only some properties are provided. With no annotations or output schema, it leaves critical context unclear, especially for a mutation tool with no return value description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema comprehensively describes all parameters (clipId, properties, and sub-properties like position in pixels), giving 100% coverage. The description adds little beyond listing the property names already present in the schema, so it does not compensate beyond the schema baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Sets') and identifies the resource ('a clip') and the specific properties (opacity, scale, rotation, position). This clearly differentiates it from single-property sibling tools like set_clip_opacity or set_clip_scale, though it doesn't explicitly state that it sets multiple properties at once.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool instead of the individual setters (set_clip_position, set_clip_scale, etc.) or the batch variant (set_clip_properties_batch). The description lacks any context about prerequisites or scenarios, providing no help for tool selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only restates the action. It does not mention side effects, whether it reads or writes, required permissions, or return values. The behavior remains opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but the phrase 'Premiere Pro expanded operation' is filler that does not earn its place. The core 'set clip volume' is concise, but the added context is vague and unhelpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's apparent simplicity, the description omits essential details such as how volume is provided, whether it modifies the selected clip, and what happens on execution. The permissive schema with no properties further complicates understanding, making the description incomplete for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters defined in the schema, so the description does not need to compensate for missing parameter documentation. The baseline of 4 applies, though the description also does not clarify how volume is specified or whether the tool uses current selection.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the operation as setting clip volume with a specific verb ('set') and resource ('clip volume'). However, it does not distinguish this tool from closely related siblings like set_clip_opacity or adjust_audio_levels, and the phrase 'expanded operation' adds no clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. There is no mention of prerequisites, selection requirements, or context such as whether it applies to selected clips or requires explicit parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. 'Premiere Pro expanded operation' is uninformative and does not disclose any behavioral traits such as whether the operation is destructive, requires clip selection, or affects which keyframe. This is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is efficient. However, 'expanded operation' is filler that adds no meaning, and the sentence could be more precisely worded as just 'Set keyframe interpolation.'
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and an empty input schema, this description is inadequate. It does not explain what keyframe interpolation entails, how it relates to keyframes, or what the agent must provide. The context is too sparse for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% per context, but the schema defines no properties and permits arbitrary additional properties. The description adds no parameter semantics—it does not explain what values are needed (e.g., keyframe index, interpolation type). Baseline 3 applies given the schema coverage, but the description fails to compensate for the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb + resource: 'set keyframe interpolation.' It clearly indicates the operation's target, though 'expanded operation' is vague jargon. It does not distinguish from siblings like set_time_interpolation, but the core purpose is stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. There is no mention of prerequisites, typical scenarios, or exclusions, leaving the agent to infer usage from the name alone among many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations at all, the description carries the full burden of behavioral disclosure. It only states the action without mentioning potential side effects like overwriting existing values, key format requirements, or failure behavior. This is inadequate for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It is efficiently structured, though it sacrifices informative content for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, and the abundance of sibling metadata tools, the one-sentence description is insufficient. It fails to explain how this tool relates to other metadata setters or what 'project metadata' entails in practice.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage with descriptions for all three parameters (key, value, projectItemId), so the description adds no additional meaning. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets a project metadata value on a project item, which is a specific verb+resource combination. However, it does not distinguish itself from sibling tools like set_project_panel_metadata or set_xmp_metadata, so it's clear but lacks differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. There are no exclusions, prerequisites, or contextual hints, leaving the agent without direction on selecting this tool over similar metadata-related siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only repeats the title and provides no behavioral details. It does not disclose whether it operates on selected clips, how it interacts with aspect ratio or anchor points, or whether the change is reversible. With no annotations, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but includes the vague qualifier 'expanded operation' that adds little value. It is not inappropriately verbose, but it under-specifies behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description does not explain the scope (selected clips, all clips), the meaning of frame size, or the difference from related operations. Given the simplicity of the tool, some essential context is still missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool accepts zero parameters, and the schema is empty. Since there are no parameters to document, the description's lack of parameter information is acceptable. The baseline of 4 applies because no parameter semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'set scale to frame size' which clearly indicates the operation of scaling footage to match the frame dimensions. However, it fails to specify the target (e.g., selected clip) and does not distinguish itself from sibling tools like set_clip_scale or set_uniform_scale, earning a 4.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided; there is no mention of when to use this tool versus alternatives like set_clip_scale or set_scale_width_height, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose side effects, requirements, and return behavior. It only states that it sets field type, with no mention of whether it modifies the active sequence, needs a selection, or what values are valid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Short and direct, one sentence. The phrase 'expanded operation' is extraneous and could be removed, but it does not harm clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that alters sequence settings, the description is insufficiently complete. It lacks context about which sequence is affected, acceptable field types, impact on existing clips, and potential errors. No output schema or annotations compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no defined parameters, and the description does not indicate how to pass the field type. Although the rubric gives a baseline of 4 for zero parameters, the empty schema with additionalProperties is ambiguous; the agent cannot know what payload to send.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'set' and the resource 'sequence field type', identifying the operation. It is distinguishable from sibling tools like set_sequence_frame_rate, but the phrase 'expanded operation' is vague and 'field type' is not defined in context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool, prerequisites, or alternatives. The description does not compare to set_sequence_pixel_aspect_ratio or set_sequence_display_format, leaving the agent to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states the immediate outcome ('creating two separate clips') but does not disclose whether the original clip is destroyed, whether the operation is reversible, what happens to selections, or any other side effects. This is a significant gap for a tool that modifies media.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a single sentence that immediately states the action and outcome. Every word contributes to the purpose. There is no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is relatively sparse. It covers the basic function but misses important contextual details like whether the split affects the original clip, whether it works on a selection, and what the result is beyond 'two separate clips'. Given the tool's destructive potential, more context is needed for a complete picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are fully described in the input schema ('The ID of the clip to split' and 'The time in seconds where to split the clip'). The description adds no additional meaning beyond the schema, so the baseline score of 3 applies. There is no need for the description to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Splits a clip at a specific time point, creating two separate clips.' This is a specific verb+resource pairing. It doesn't explicitly differentiate from sibling tools like 'razor_timeline_at_time' or 'trim_clip', but the action of splitting a single clip at a specific time is distinct enough to serve as a clear functional statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 versus alternatives. It does not mention prerequisites, exclusions, or contrast with similar tools such as 'razor_timeline_at_time' or 'trim_clip'. The usage is only implied by the name and function, not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral details beyond the action itself. It does not say whether this is a mutating operation, what scope it applies to, or what the effects are on existing metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is appropriately concise. However, the 'Premiere Pro expanded operation:' prefix is redundant and does not earn its place, slightly reducing effectiveness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations. The description gives only a terse action with no context about when to use it, what happens after execution, or any side effects. This is insufficient for an AI agent to reliably select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema description coverage is 100% (vacuously, since no parameters exist). Per the rubric, baseline for 0 parameters is 4. The description does not add parameter-level nuance, but there are no parameters to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action: 'add custom metadata field.' This identifies the verb and resource, distinguishing it somewhat from siblings like set_xmp_metadata or get_metadata. However, it lacks specificity about the context or result, and the prefix 'Premiere Pro expanded operation' adds no unique meaning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as set_metadata or attach_custom_property. No conditions, prerequisites, 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.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states that a marker is added to a project item, but does not disclose side effects (e.g., whether it modifies marker list, requires selection, or overwrites existing markers), authorization requirements, or error behavior. For a mutation operation, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded, with the core action in the first clause. However, the opening phrase 'Premiere Pro expanded operation:' is unnecessary filler that adds no value. Still, it is appropriately concise for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's mutation nature and lack of annotations or output schema, the description is incomplete. It does not explain what a project item marker entails, how the target item is identified, or what data is required to add the marker. This is insufficient for an agent to invoke the tool correctly without additional assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero defined parameters in the schema, and schema coverage is 100%. With no parameters, the baseline is 4. The description does not need to explain parameter syntax because there are none, and the mention of 'project item' provides context for the operation's target.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'add marker to project item.' This is a specific verb+resource combination. However, it does not explicitly differentiate from the sibling tool 'add_marker', which could be confused for a similar operation. The phrase 'expanded operation' is vague filler.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 add_marker, update_marker, or list_markers. There is no mention of prerequisites, intended workflow, or which project items are valid targets. The description gives no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It simply states the action without explaining side effects, whether it affects the active sequence, or whether it is destructive. The phrase 'expanded operation' adds no clarity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and front-loaded, containing only one sentence. However, the phrase 'Premiere Pro expanded operation:' is redundant and does not add value, slightly reducing the structural quality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is incomplete for a tool that likely operates on the active sequence. It does not specify the scope (e.g., active sequence vs. a passed parameter), nor does it clarify what 'in out' refers to. Given the simplicity, more context is needed to avoid confusion with sibling tools like 'clear_item_in_out'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and the schema is empty with no descriptions needed. Per the rubric, a baseline of 4 is appropriate since there are no parameter semantics to describe.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'clear' and the resource 'sequence in out', which clearly indicates clearing the in/out points of a sequence. However, it does not explicitly mention 'in and out points' or distinguish from the sibling tool 'clear_item_in_out', making it slightly ambiguous in a broader context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not indicate when to use this tool versus alternatives like 'set_sequence_in_out_points' or 'clear_item_in_out', nor does it mention any prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the action 'close source monitor' without mentioning side effects, conditions (e.g., what happens if no source monitor is open), or any state changes beyond the obvious closure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded, but the phrase 'expanded operation' is filler that does not earn its place. It is concise but not optimally informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the operation, an empty schema, and lack of output schema, the description is minimally sufficient. However, it lacks context about the source monitor state and its relationship to sibling tools, leaving some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines zero parameters, so the description does not need to clarify parameter semantics. The baseline of 4 applies because there are no parameters and the description adds no misinformation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'close source monitor' with a clear verb and resource, making the core action understandable. However, the prefix 'expanded operation' is vague and adds no meaningful clarity, and it does not distinguish this from the sibling tool close_all_source_clips.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as open_in_source or close_all_source_clips. The description gives no context on use cases, prerequisites, or when a user should prefer this over sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure burden. It only labels the tool as an 'expanded operation' and states the basic action, without disclosing side effects, required context (e.g., selected clips), or whether it mutates the project. This is insufficient for a creation operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence and front-loaded with the key action. The phrase 'Premiere Pro expanded operation' adds little, but the structure is efficient. It loses a point for the vague modifier that doesn't earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and no parameters, the description needs to provide contextual grounding on when and how to use the tool. It fails to explain what 'sequence from clips' means operationally (e.g., selected clips, current sequence handling) and does not differentiate from similar sibling tools like create_sequence. This is inadequate for an AI agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is vacuously 100%. Per the rubric, the baseline is 4 for 0 params, and the description correctly does not attempt to describe nonexistent parameter details, so a score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'create sequence from clips'. It distinguishes from siblings like create_sequence_from_preset by referencing clips, but the phrase 'expanded operation' is vague and doesn't clarify what makes it distinct. Overall, the core purpose is understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as create_sequence or create_sequence_from_preset. There is no mention of prerequisites, selection requirements, or scenarios where this tool is preferred, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral disclosure burden. It only states that the tool deletes multiple project items, but does not explain permanence, undoability, selection mechanism, or any side effects. This is a significant gap for a deletion operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief and front-loaded with the core action. The phrase 'expanded operation' is unnecessary filler, but it does not significantly harm readability. Overall, it is concise and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The operation is a deletion tool with no annotations, no output schema, and an empty input schema. The description fails to clarify how the items to delete are identified (e.g., selected items, list of IDs), and how this differs from similar tools. This lack of context makes it hard for an agent to know how to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is an empty object with 0 parameters, so the baseline is 4. The description does not add parameter semantics, but there are no parameters to describe, so this is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('delete') and the resource ('multiple project items'), which distinguishes it from the sibling tool delete_project_item (singular). However, the phrase 'expanded operation' is vague and adds no meaningful content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 delete_project_item or remove_selected_clips. The description only implies it handles multiple items, but does not explicitly state scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that preview files are deleted, but does not mention whether the deletion is permanent, whether it affects files on disk, whether it can be undone, or what consequences occur. For a destructive operation, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and gets to the point, but the prefix 'Premiere Pro expanded operation' is filler that adds no meaningful information and could be removed. It is concise but not optimally structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and usage guidance, this one-line description is under-specified for a destructive command. It does not explain what preview files are, when deletion is appropriate, or what the operational outcome is beyond the action itself.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters and the schema is empty, so the baseline is 4. The description does not need to explain parameter semantics, and none are missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'delete preview files' clearly states the action and resource, and it is distinct from sibling deletion tools like delete_bin or delete_sequence. However, it does not elaborate on scope (e.g., current project, all projects) or explicitly differentiate itself from other file-deletion operations, so it falls just short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 versus alternatives. There is no mention of prerequisites, context, or situations where deletion might be appropriate or unsafe, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only restates the operation name without adding context about return format, side effects, performance, or error behavior. The term 'expanded operation' is uninformative. It does not describe what 'all project paths' means or whether it is a deep recursive listing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and the core information is front-loaded in the second half. However, the 'Premiere Pro expanded operation:' prefix is filler and could be omitted. It is concise but could be cleaner without the boilerplate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (no params, no output schema), but the description still leaves key context missing. It does not clarify what 'project paths' refers to, what the return value looks like, or how it relates to other project inspection tools. Given the ambiguity and lack of output schema, a more descriptive sentence would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The schema is empty and the description appropriately adds no parameter details since none exist. No further parameter explanation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('get all project paths') with a specific verb and resource, and it distinguishes itself from siblings like get_project_info and list_project_items. However, the phrase 'expanded operation' is vague and adds no meaningful scope, and 'project paths' could be interpreted ambiguously (e.g., media paths vs. bin hierarchy).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not explain when to use this tool versus alternatives such as get_project_info, list_project_items, or get_full_project_overview. There are no explicit when-to-use, when-not-to-use, or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of disclosure, but only 'get' implies a read operation. It does not specify what the operation returns, whether it targets the selected adjustment layer, or any side effects or errors. This is minimal transparency, equivalent to the 'Update shared drive settings' example.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, almost to a fault. The phrase 'Premiere Pro expanded operation' is filler that doesn't add value, but the core is concise. It is not verbose, but it under-delivers on substance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description should explain what 'get clip adjustment layer' returns and how it behaves. It does not, leaving the agent to guess about the return value, selection scope, or relationship to other clip operations. This is incomplete for a tool with no structured context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so the baseline is 4. The description does not need to explain parameter meanings, and the empty schema aligns with no required inputs. No improvement needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'get' and the resource 'clip adjustment layer', making the tool's purpose identifiable. It distinguishes from sibling tools like 'add_adjustment_layer' without confusion, though the prefix 'Premiere Pro expanded operation' adds little and is not a full sentence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. No mention of selection prerequisites, relationship to add_adjustment_layer, or typical scenarios. The description provides no context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only states the action but doesn't disclose whether it is read-only, the clip scope (selected clip vs all clips), or what information is returned (names, properties, etc.). 'Expanded operation' is unhelpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise, but the phrase 'Premiere Pro expanded operation' includes unnecessary filler that doesn't add value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is insufficient. It fails to explain what the list returns or how to specify which clip, leaving critical gaps for a list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is empty and the baseline is 4. There are no parameter semantics to add beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists clip effects in Premiere Pro, using a specific verb and resource. It is distinct from sibling tools like remove_effect or apply_effect. However, the phrase 'expanded operation' is vague and doesn't clarify what is being expanded.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as get_effect_properties or list_available_effects. There is no mention of context, scope, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It only states 'razor all tracks' without explaining the cut position (e.g., at the playhead), whether the operation is destructive, or any side effects. This leaves significant ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and is concise. The phrase 'expanded operation' adds little value, but it is not verbose. It is front-loaded with the key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-argument tool, the description is too sparse. It omits crucial context such as whether an active sequence is required, whether it cuts at the current playhead, and what the impact is on the timeline. This is insufficient for an agent to use the tool safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the description does not need to explain parameter details. The schema trivially covers all parameters, and the baseline for zero-parameter tools is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'razor' and the resource 'all tracks' to indicate a cut operation across all tracks, which is clear. However, it doesn't distinguish this from the sibling tool 'razor_timeline_at_time' which likely performs a similar cut but at a specific time.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 'razor_timeline_at_time' or 'split_clip'. There is no mention of prerequisites, such as requiring an active sequence, or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the full burden of behavioral disclosure. It only states the action, without revealing side effects, whether it overrides existing target states, or if it affects both audio and video tracks. The term 'expanded operation' is vague and adds no concrete behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, making it concise. However, it is so brief that it sacrifices useful context, which affects completeness rather than conciseness. It is appropriately front-loaded with the key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero annotations, no output schema, and simple parameters, the description is the sole source of context. It fails to clarify the scope (audio/video/all), the effect on existing targeting, or any prerequisites (e.g., an open sequence). The 'expanded operation' phrase is unexplained and adds confusion rather than completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds meaning by explaining the operation, even though no parameter details are needed. The schema is empty, so there is nothing to clarify beyond the action itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('set all tracks targeted') with a specific verb and resource. It distinguishes itself from sibling tools like set_target_track, which focuses on a single track. However, it doesn't specify whether 'all tracks' includes audio, video, or both, and the phrase 'expanded operation' adds ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. It does not mention set_target_track or other track-related tools, nor does it describe prerequisites or scenarios where this tool is appropriate. The agent is left to infer usage from the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the action without disclosing side effects, such as whether existing work area points are overwritten, or if the sequence must be open. 'Sets' implies a mutating operation but adds no further behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. It is front-loaded with the verb and resource, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is minimal. It does not explain how this differs from set_sequence_in_out_points, nor does it state any prerequisites or effects. While parameters are fully described, the broader context is lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with clear descriptions for inPoint, outPoint, and sequenceId. The tool description adds no parameter-level semantics beyond what the schema already provides, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Sets') with a clear resource ('work area in/out points') for a sequence. It clearly distinguishes from sibling tools like get_work_area and set_sequence_in_out_points by specifying 'work area'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 instead of alternatives. There is no mention of prerequisites, exclusions, or related tools such as set_sequence_in_out_points.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the basic operation, without mentioning prerequisites (e.g., component/parameter must exist), overwrite behavior if a keyframe already exists at the same time, or potential side effects. This is similar to the 'update drive' example which scored 2.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, and it front-loads the action and object. It is concise and appropriately structured for the simplicity of the tool, though it lacks nuance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 required parameters, no annotations, no output schema, and a sparse description, the tool context is incomplete. It does not explain how parameters work together, whether the operation is idempotent, or what conditions must be met (e.g., the clip must have the specified component and parameter). An agent would need to infer significant details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with each parameter described, so the baseline is 3. The description does not add meaningful detail beyond the schema; it restates that time is in seconds, which the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('adds') and identifies the exact resource ('keyframe to a clip component parameter at a specific time'). It clearly distinguishes from sibling tools like remove_keyframe, get_keyframes, and set_keyframe_interpolation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention that this is for animating parameters over time, nor does it contrast with direct setters like set_clip_opacity or set_clip_volume. No exclusions or alternative references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It does not state important details such as whether existing tracks are affected, whether the track is inserted immediately, or whether any permissions or sequence state requirements exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that states the core action. No unnecessary words or filler, and it is front-loaded with the key verb.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple, and the schema covers parameters. However, the lack of output schema and minimal behavioral context make it incomplete for an agent to understand the effect or result. The ambiguity with 'add_tracks' is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides complete descriptions for all parameters (100% coverage), so the description adds little beyond what the schema already states. The enum values for 'position' and 'trackType' are self-explanatory in the schema, making the description's mention of 'video or audio track' redundant.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('adds') and resource ('video or audio track') with the target ('sequence'). However, it does not distinguish this tool from the sibling 'add_tracks', which likely handles multiple tracks, creating ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as 'add_tracks' or when a track should be added above vs below. The description does not mention exclusions or specific scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full responsibility for behavioral disclosure. It states only that a LUT is applied, without mentioning whether it replaces existing LUTs, stacking behavior, default intensity when omitted, reversibility, or whether the operation is destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that clearly communicates the tool's core action. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a three-parameter tool with full schema coverage, the description is minimally adequate. However, it omits behavior around intensity defaults, interaction with existing color corrections, and any observable outcome, which are relevant for an operation that modifies visual output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each parameter already has a clear description. The tool description adds little beyond 'for color grading,' which doesn't materially enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Applies') and resource ('Look-Up Table (LUT) to a clip'), with a purpose ('for color grading'). It is specific enough to distinguish from generic apply_effect, but doesn't explicitly differentiate from color_correct or set_color_value.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 alternative color grading or effect tools. Usage context is only implied by the term 'LUT,' not stated in terms of prerequisites, exclusions, or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It says 'consolidates' but does not clarify whether this deletes duplicates, is reversible, requires user confirmation, or has any side effects. The term 'consolidate' is ambiguous and could imply destructive actions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler. It is front-loaded and every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and no parameter details, the description leaves critical questions unanswered: What does consolidation do exactly? Does it delete or relink media? Is it destructive? The description is too minimal for an AI agent to understand the tool's full impact.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the empty schema is fully descriptive. The baseline for zero parameters is 4, and the description adds no unnecessary parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('consolidates') with a specific resource ('duplicate media items') and scope ('in the project'). It is unambiguous but does not explicitly distinguish from the sibling tool 'consolidate_and_transfer'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, nor any prerequisites or expected context. The description merely states what the tool does without any situational advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only states 'copy effects between clips' without explaining side effects, whether it modifies source/target clips, or whether it requires specific selection states. The term 'expanded operation' hints at additional behavior but is not elaborated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant wording. It is appropriately sized for a simple operation, though 'expanded operation' is filler, it does not detract from clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks essential context for a copy operation: it does not mention source/target selection, whether all effects are copied, or what the result is. There is no output schema, and the schema for parameters is empty, so the description carries the burden of explaining behavior, which it fails to fully do.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so the baseline of 4 applies. The description does not need to clarify parameter meanings since none are defined, and the schema is empty (allowing 'additionalProperties': {} with no properties listed).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('copy') and resource ('effects') with scope ('between clips'), making the tool's function understandable. However, the phrase 'expanded operation' is vague and does not differentiate this from the similar sibling tool 'copy_effect_values', so it does not fully distinguish.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as 'copy_effect_values' or 'apply_effect'. The description does not mention prerequisites, target selection, or any exclusions, leaving the agent to infer the correct usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It only says 'create bars and tone' without revealing where the element is created, whether it is selected, if any sequence/project must be active, or if the operation is destructive. This is minimal disclosure for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler. It is front-loaded and every word serves a purpose, though 'expanded operation' adds little value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create-type tool with no annotations and no output schema, the description is under-specified. It lacks context about the target (project bin vs timeline), prerequisites, or typical workflow, making it incomplete for an agent deciding whether and how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description does not need to explain parameter semantics because there are none defined, though the schema allows arbitrary additional properties without any documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('create') and resource ('bars and tone'), which identifies the tool's function. It is distinct from sibling tools like create_sequence or add_to_timeline, though 'expanded operation' is vague and does not specify the exact output context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, nor any indication of prerequisites or side effects (e.g., whether it inserts into the timeline or adds to a bin). The description only states what the tool does, not when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only says 'Gets information', implying a read operation but giving no details about what information is returned, potential errors, or side effects. It does not add meaningful behavioral context beyond the bare action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that communicates the essential purpose without any unnecessary words. It is perfectly concise for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and a generic description that does not specify what 'information' includes, the tool is under-specified. The presence of more detailed sibling tools (e.g., get_sequence_structure, get_full_sequence_info) makes this description feel incomplete for an agent to predict the return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100% (empty). Per the baseline for zero-parameter tools, the description is not required to explain parameters, and it adds no extra constraints. This is a solid baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action (gets) and resource (currently active sequence), which makes the core purpose understandable. However, it does not distinguish itself from closely related sibling tools like get_sequence_settings or get_full_sequence_info, so it lacks differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. Given the many sibling tools that also retrieve sequence-related information, the lack of any context or alternative references leaves the agent without direction on choosing this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral details such as whether the operation is read-only, the return format, or any side effects. It only states the basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter, the description is adequate but incomplete: it does not specify the shape of the returned keyframes (since no output schema is provided) or offer usage context. This leaves the agent uncertain about what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for clipId, componentName, and paramName. The description adds no additional meaning beyond the schema, justifying the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets all keyframes for a clip component parameter, using a specific verb and resource. It does not explicitly differentiate from sibling tools like get_value_at_time or add_keyframe, but the intent is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as get_value_at_time or remove_keyframe. There is no mention of prerequisites or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It implies a read operation ('gets') but provides no detail on side effects, error cases, return format, or limitations. The vagueness of 'project metadata and XMP metadata' leaves the agent uncertain about what exactly will be retrieved.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the action and resource. No unnecessary words or details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter getter, the description is minimally adequate but lacks output schema information or any description of the return value. Given the existence of sibling tools like get_xmp_metadata, it does not fully clarify what makes this tool distinct or what callers should expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the only parameter (projectItemId) with a clear description. The tool description does not add additional meaning beyond what the schema provides, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets project metadata and XMP metadata for a project item. It uses a specific verb and resource, but it does not explicitly distinguish itself from similar sibling tools like get_xmp_metadata or get_project_item_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description does not mention any exclusions, prerequisites, or contexts where a different tool (e.g., get_xmp_metadata) would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It states the core behavior (reload from disk) but omits important details such as whether project changes are saved, whether the refresh is destructive, or how failures are handled.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that immediately states the action and object, with no unnecessary words or repetitive information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description is minimally adequate. It covers the basic function but lacks usage context and behavioral side effects, so it is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers the only parameter (projectItemId) with a clear description, achieving 100% schema coverage. The tool description adds no additional parameter semantics beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Refreshes'), the resource ('media for a project item'), and the mechanism ('reloading it from disk'). It is distinct enough from siblings like relink_media, though it does not explicitly call out the difference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 versus alternatives such as relink_media or check_offline_media. The only implied context is that media may be stale on disk, but no explicit when-to-use or when-not-to-use information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It merely restates the tool's name ('select clips by name') and offers no additional context about side effects, such as whether it clears previous selection, whether it matches substrings, or what happens if no clips match. It does not disclose any operational traits beyond the literal action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, making it very concise. However, the phrase 'Premiere Pro expanded operation' adds little value and could be considered filler. The key action is clearly present, and there is no redundant information beyond that prefix, so it earns a high score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations, output schema, and any parameter details, the description is too sparse to be complete. It does not explain the selection behavior (e.g., exact name match, case sensitivity, whether it operates on the active sequence), nor does it provide enough context for an agent to know if this tool is suitable for a given task. The tool's simplicity does not excuse the lack of essential behavioral details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so the baseline is 4. The description adds no parameter-specific information, but none is needed since the schema is empty. The lack of parameter details does not detract from the tool's usability in this case.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool selects clips by name, which is a specific verb+resource combination. It distinguishes itself from siblings like select_all_clips, select_clips_in_range, and select_clips_by_color by indicating the selection criterion (name). Despite the odd 'Premiere Pro expanded operation' prefix, the core purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 versus alternatives. It does not mention any exclusions, prerequisites, or situations where another tool would be more appropriate. For example, it doesn't clarify whether it should be used for exact-match selection or fuzzy matching, nor does it contrast with select_clips_by_color or select_clips_in_range.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the basic action without elaborating on side effects, reversibility, permissions, or interplay with existing color labels. This lack of detail is a significant gap for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that immediately states the tool's purpose. It is appropriately sized for a simple setter tool and contains no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description is adequate but leaves gaps: it does not mention related operations (e.g., reading a color label) or clarify any behavioral nuances. The schema covers parameter details, so completeness is moderate for such a straightforward setter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage of parameters, including a detailed mapping of colorIndex values (0-15). The description adds no additional parameter context, which is acceptable given the schema's thoroughness, but it does not go beyond the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Sets the color label') and the resource ('a project item'), using a specific verb and object. It does not explicitly differentiate from sibling tools like 'set_color_value' or 'get_color_label', but the term 'color label' is distinct enough to imply its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. The description simply states what it does without mentioning related tools like 'get_color_label' or 'set_color_value', leaving the agent to infer usage from the name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose behavioral details such as whether audio pitch is maintained by default, speed limits, or side effects like affecting keyframes or linked items. The 'maintainAudio' parameter is in the schema but not highlighted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that gets straight to the point. No wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema covers all parameter semantics, making up for the terse description. However, the tool is a mutation operation with no annotations and no output schema, and the description provides no behavioral context (e.g., defaults, side effects). It is minimally viable but lacks richness for a smooth decision-making process.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter already well-documented (e.g., speed range, maintainAudio purpose). The description adds no extra meaning beyond what the schema provides, so the baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Changes') and resource ('playback speed of a clip'), making the tool's purpose immediately understandable. However, it does not differentiate from similar siblings like 'set_clip_speed_qe', which also deals with clip speed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternative speed-related tools (e.g., set_clip_speed_qe, set_time_interpolation). The description only states what it does, not the intended use case or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'Updates an existing marker's properties' without revealing side effects (e.g., whether it's a partial update), required permissions, or error behavior when the marker doesn't exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence, front-loaded with the verb, and contains no irrelevant words. It is appropriately concise for a simple tool, though it lacks detail that other dimensions penalize.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a mutation tool with no annotations and no output schema, the description is too sparse. It doesn't mention prerequisites like the marker existing or the sequence being open, nor does it clarify that only supplied properties are updated. This makes it incomplete for an agent to safely rely on.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers all five parameters with 100% description coverage, so the baseline is 3. The description adds no additional meaning about parameter interactions, such as the fact that optional fields like name, color, and comment are only updated if provided. It relies entirely on the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates existing markers, using the specific verb 'updates' and identifying the resource as 'an existing marker's properties.' This distinguishes it from sibling tools like add_marker and delete_marker, which create or remove markers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 versus alternatives such as add_marker or list_markers. It lacks any mention of prerequisites, conditions, or exclusions, leaving usage context entirely ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states 'adds a marker' but does not mention whether this mutates existing markers at the same time, whether it creates point or span markers, if a sequence must be active, or any side effects. The schema documents parameters, not behavior, so the description is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler or redundancy. It is appropriately sized for the basic purpose statement, and every word contributes to conveying the action and intent. This is efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 parameters, 3 required, and introduces features like duration for span markers, yet the description is minimal. There is no output schema or annotations, so the description should explain return values or behavioral context. It does not mention ability to create span markers, required active sequence, or what happens on success/failure. This is incomplete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes 100% of the parameters with meaningful details. The description adds no extra parameter semantics beyond the generic 'timeline' context. Baseline is 3 due to full schema coverage, and the description does not improve upon it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Adds a marker to the timeline' and the purpose 'for navigation or notes'. It is specific about the resource (timeline) and the action, but does not distinguish from the sibling tool 'add_marker_to_project_item', which also adds markers but to project items. Thus it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for placing timeline markers for navigation or notes, but provides no explicit guidance on when to use this tool versus alternatives like 'add_marker_to_project_item', 'update_marker', or 'delete_marker'. No alternatives or exclusions are mentioned, so the usage context is only inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only restates the basic action. It does not disclose that the tool does not start rendering unless startImmediately is true, that it requires AME to be installed, whether it blocks, or what the return value indicates. With no annotations, the description carries the full burden but offers no behavioral context beyond the action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence that immediately front-loads the verb and resource. No words are wasted, making it highly efficient for its clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters, several related sibling tools, and no output schema or annotations, the description is far too minimal. It doesn't explain the typical queue-then-encode workflow, how to choose between presetName and presetPath, or what happens after adding a sequence, leaving significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% parameter description coverage, including explicit descriptions for presetName, sourceRange, and defaults. The tool description itself adds no parameter semantics beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Adds'), the object ('a sequence'), and the destination ('Adobe Media Encoder render queue'). This is specific and easily distinguishes from sibling tools like encode_file or start_batch_encode.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 versus related tools such as export_sequence, start_batch_encode, or encode_project_item. There are no example workflows, prerequisites, or alternative references, so an agent has no help choosing it over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action, with no mention of side effects (e.g., whether it affects source monitors, unsaved changes, or requires permissions). This is minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, extremely concise, and every word is relevant. It avoids any fluff and gets straight to the point, earning a top score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no params, no output schema), the description provides the core action but lacks context about after-effects or usage scenarios. It is adequate as a minimal description but not richly complete, hence a 3.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema provides no parameter details. The description adds no parameter semantics, but with no parameters to document, the baseline is 4. There is nothing to add, making 4 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'close all source clips.' It uses a specific verb and resource, leaving no ambiguity about what the tool does. However, it does not explicitly differentiate from sibling tools like close_source_monitor, so a 4 is given rather than a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 versus alternatives. It simply states the operation without mentioning prerequisites, context, or exclusions, resulting in a lack of usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of disclosing behavioral traits. It only states 'Deletes a sequence' without addressing permanence, undoability, side effects on open sequences, or required permissions, leaving the agent unaware of destructive implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with no wasted words, immediately conveying the action and target. It is appropriately concise and front-loaded with the verb.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no annotations and no output schema, the description is too sparse. It omits critical context about the consequences of deleting a sequence, such as irreversibility or impact on open sequence tabs, which is necessary for safe tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter sequenceId is already fully described in the input schema with 100% coverage, so the schema carries the parameter semantics. The description adds no additional meaning beyond the parameter's role, thus baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Deletes' and the resource 'sequence', clearly distinguishing it from sibling tools like delete_bin or delete_project_item. It is a precise statement of the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided regarding when to use this tool versus alternatives such as close_sequence or delete_project_item. There is no mention of prerequisites, context, or when this tool should be preferred over similar deletion tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral transparency. It discloses only the basic read operation ('Gets') and does not mention edge cases (e.g., no clip at the specified time), return behavior, error handling, or any side effects. This is a significant gap for a tool with no structured metadata to supplement it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence containing no filler or redundancy. It directly conveys the core function. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, no output schema, no annotations), the description is insufficient. It does not specify what exactly is returned (a clip ID, object, etc.), what happens if the position falls between clips or beyond the track duration, or how this relates to similar tools. The user/agent is left without critical context for invocation and result interpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the parameters with descriptions (time, trackType, trackIndex, sequenceId). The description adds no additional meaning beyond what the schema already provides. Given the high schema coverage, a baseline score of 3 is appropriate; the description neither clarifies nor confuses parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose using an action verb ('Gets') and a specific resource ('the clip at a specific time position on a track'). It is precise enough to be distinguished from the sibling tool 'get_clip_at_playhead' by explicitly mentioning 'specific time position' rather than the playhead. However, it does not explicitly name alternatives, so it doesn't fully differentiate itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the usage context: when you need to retrieve a clip at an arbitrary time on a track. It does not provide explicit guidance on when to use this tool versus similar ones like 'get_clip_at_playhead' or 'get_selected_clips'. There are no exclusions or alternative suggestions, so the guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only states the basic function. It does not mention that the MOGRT is placed into a sequence at a specified time and track, nor any prerequisites or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that is front-loaded and contains no unnecessary words. It efficiently states the tool's purpose and source.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter tool with no annotations and no output schema, the description is under-specified. It does not reveal key contextual details such as placing the MOGRT into a sequence at a specific time and track, which are essential for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage of all parameters with descriptions, so the baseline is 3. The description adds no additional parameter-level meaning beyond what the schema already documents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool imports a Motion Graphics Template from a Creative Cloud Library, using a specific verb and resource. It distinguishes from the sibling import_mogrt, which presumably imports from local files rather than a library.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. The source (Creative Cloud Library) is implied, but there is no explicit mention of when to choose this over import_mogrt or other import methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior, but 'play timeline' reveals nothing about side effects like playhead movement, whether it stops existing playback, or what happens if no timeline is open. The phrase 'expanded operation' adds no concrete behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words or repetition. It front-loads the core action and is appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description is minimally adequate but lacks important context such as which timeline is played (active sequence) or playback start position. Sibling tools like 'set_playhead_position' suggest more context could be useful, but the low complexity keeps this from being a critical gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero parameters, and the description correctly implies no arguments are needed. This aligns with the baseline of 4 for parameterless tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'play' and resource 'timeline', which distinguishes it from sibling tools like play_source_monitor. It is specific and unambiguous about the action, though it could be more explicit about the active sequence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as 'stop_playback' or 'play_source_monitor'. The description only states the action without any exclusions or context about the active timeline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavioral traits. It only says 'sets' without explaining side effects, whether both settings are required, whether the operation is reversible, or what happens on invalid input. This is insufficient for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with no redundant or filler content. It is front-loaded with the action and resource, making it easy to scan. Perfectly concise for the information it carries.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is minimally complete. It explains the basic operation but lacks context about how footage interpretation differs from related clip overrides, what the required projectItemId implies, and what happens to unspecified settings. Given the complexity and the existence of closely related sibling tools, this falls short.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage with descriptions for all three parameters, so the baseline is 3. The description adds little beyond restating that frame rate and pixel aspect ratio are involved; it does not clarify how the overrides interact or how the optional parameters behave when omitted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('sets'), the resource ('footage interpretation settings'), and the scope ('for a project item'), explicitly listing the two main settings (frame rate, pixel aspect ratio). This distinguishes it from sequence-level settings and other related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 versus alternatives like set_override_frame_rate or set_override_pixel_aspect_ratio. There is no mention of prerequisites, exclusions, or preferred scenarios, leaving the agent to infer usage from the sibling tool list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It only states the action 'set' without revealing side effects, required permissions, or what happens to the sequence (e.g., whether it modifies the active sequence, if it's destructive, or if any settings reset). The minimal wording leaves critical behavioral aspects undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise, containing only a prefix ('Premiere Pro expanded operation') and the core action. Every word earns its place, with no fluff or repetition. It is front-loaded and immediately clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description is minimally viable but lacks contextual details such as what 'display format' means, which sequence it applies to, or any constraints. The low complexity lowers the expectation, but the complete absence of behavioral or usage context keeps it from being fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description does not need to explain parameters, but it also does not clarify what the operation acts upon implicitly (e.g., the active sequence). Since there are no parameters to document, the description adds no parameter semantics, but the baseline applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific verb and resource: 'set sequence display format'. While it closely mirrors the tool name, it adds no ambiguity about the operation. It is distinguishable from sibling tools like set_sequence_frame_rate or set_sequence_resolution by the unique 'display format' target, though it could be more explicit about what 'display format' entails (e.g., timecode or frames).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention when to use this tool versus alternatives, nor any prerequisites like an active sequence or selection. There are no explicit exclusions or hints about context, leaving the agent to infer when this should be invoked.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosure. It states the intended effect but does not reveal whether the operation modifies the clip destructively, what happens to existing stabilization, whether it is reversible, or what the return value is. This is minimal transparency for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded and free of filler. It communicates the core function efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite complete parameter schema, there is no output schema or annotations, and the description is too brief to explain operational context like whether the clip is modified in place or a new clip is created. For a mutating video operation, this leaves important gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters (clipId, method, smoothness) are already described in the input schema with 100% coverage. The description itself adds no parameter-level detail, such as the meaning of 'warp' vs 'subspace' or the effect of the smoothness range, so it does not go beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's function: applying video stabilization to a clip. The verb 'applies' and resource 'video stabilization' are specific. There is no other stabilization tool among siblings, so it distinctively identifies the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use stabilization versus other clip operations, nor any exclusions or prerequisites. The purpose is self-evident, but there is no explicit usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the entire burden of behavioral disclosure. It only says 'stop playback' without detailing side effects, scope, or edge cases like already-stopped playback. This is minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler. It communicates the core function efficiently and is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple stop action, the description is adequate but leaves ambiguity about which playback context (timeline vs source monitor) and does not mention what happens in edge cases. Given the absence of annotations and output schema, it is complete enough for a minimal tool but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description is not expected to explain parameter semantics. The schema is trivial and additionalProperties allows arbitrary properties, but no parameter details are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (stop) and resource (playback), making it distinguishable from play-related siblings like play_timeline. However, it does not specify whether it stops timeline playback, source monitor playback, or both.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as play_timeline or play_source_monitor. It also does not mention whether playback must be active or how it behaves if nothing is playing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full burden of behavioral disclosure. It only states the core action and effect of shortening. It does not disclose whether the trim is rippled, how adjacent clips are affected, potential errors, or requirements like having an active sequence. This is insufficient for a mutation operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the purpose. No unnecessary words or repetition. It is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that modifies a timeline clip, the description is too sparse. It lacks usage context, behavioral side effects, and requirements. While the schema covers parameter syntax, the description does not explain how trimming interacts with the timeline or when this tool is appropriate relative to siblings, leaving significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter already clearly documented (e.g., inPoint/outPoint vs. duration exclusivity). The description adds the general context of 'shortening' but does not enrich parameter-level meaning beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Adjusts the in and out points') and the resource ('a clip on the timeline'), with the effect of shortening the clip. This distinguishes it from sibling tools like split_clip or ripple_delete, which have different editing behaviors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention any prerequisites, exclusions, or comparisons to related tools such as set_clip_start_time, move_clip, or ripple_delete. Usage must be inferred from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only restates the tool's function without additional context. It does not explain side effects, potential no-op behavior, or dependencies on prior actions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, straightforward sentence that efficiently conveys the core function without any unnecessary words. It is appropriately sized for a simple operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema, no annotations), the description is minimally viable but could be more complete by noting the scope of undo (e.g., last action) or how it differs from 'multiple_undo'. The absence of usage context makes it adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline score is 4. The description does not need to explain parameter semantics since the schema is empty, and there is no ambiguity to resolve.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs an undo operation in Premiere Pro, which is a specific verb and resource. However, it does not distinguish itself from sibling tools like 'redo' or 'multiple_undo' by specifying it handles a single undo step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 versus alternatives such as 'multiple_undo' or 'redo'. There is no mention of appropriate use cases or exclusions, leaving the agent without contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the core action and does not mention side effects, whether the operation is destructive, required permissions, or what happens to existing timeline content. The schema's insertMode parameter hints at behavior, but the description itself lacks transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the key information (source, destination, and placement specifics). It contains no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema is rich and covers all parameter semantics, but the description itself is minimal. It lacks usage guidance and behavioral context for a complex timeline-editing operation. However, the overall definition (description + schema) is moderately complete, justifying a mid-level score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with detailed explanations for each parameter (e.g., linkAudio's purpose, sourceInPoint/OutPoint semantics). The tool description adds no parameter meaning beyond the schema, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action: adding a media clip from the project panel to a sequence timeline at a specific track and time. This distinguishes it from siblings like insert_from_source (source monitor) and add_to_timeline_batch (batch operation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 versus alternatives like insert_from_source or overwrite_from_source. It also does not mention prerequisites or when not to use it, leaving the agent to infer the use case solely from the tool name and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It doesn't explain whether the adjustment is relative or absolute, how it interacts with existing keyframes, whether it affects the entire clip or just selected portions, or any side effects. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, with no redundant or filler content. It earns its place and is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with full schema coverage, the description is minimally adequate but lacks usage guidance and behavioral context. It doesn't explain return behavior or mention any effects on existing audio settings, so completeness is average.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for both parameters (level and clipId) with 100% coverage, so the description adds no additional meaning. The baseline of 3 applies as the schema handles parameter semantics adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action: 'Adjusts the volume (gain) of an audio clip on the timeline.' It identifies the verb (adjusts), resource (volume/gain), and target (audio clip on timeline), making it unambiguous and distinguishing it from generic operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 versus alternatives such as set_clip_volume or adjust_audio_keyframes. It does not mention any prerequisites, exclusions, or preferred use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description carries full burden. It mentions optional cuts/markers (a mutating action) but does not disclose that applying cuts modifies the timeline, that detection can be time-consuming/blocking, or that it relies on current clip selection. The parameter allowUnsafeSynchronous hints at blocking but is not referenced in the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the core purpose, no redundant words. Achieves high efficiency but at the cost of behavioral depth.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a tool whose parameters are fully documented, but lacks explanation of return values/output (no output schema) and behavioral caveats like synchronous blocking. Also doesn't address the similar sibling scene_edit_detection, which could confuse selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions, so baseline is 3. Description adds 'selected clips' context but does not elaborate on sensitivity or action enums beyond what schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Detects' and object 'scene changes in selected clips', clearly distinguishing from audio-based siblings like detect_silence. However, it does not differentiate from the similarly named sibling scene_edit_detection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage when scene detection is needed on selected clips, but no explicit guidance on when to prefer this over scene_edit_detection or detect_silence. The optional cuts/markers action is mentioned, but no exclusion criteria or prerequisites are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry full behavioral burden. It only states the basic toggle action without disclosing side effects, selection implications, undo behavior, or permission requirements. This is minimal disclosure for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant or filler content. It efficiently states the operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity and complete schema, the description is minimally viable but lacks usage guidance and behavioral context. It does not mention when to use it or what happens on the timeline, but the simple nature of the operation mitigates the gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides complete descriptions for both parameters (clipId and enabled), and the description adds no additional meaning beyond what the schema already covers. Baseline 3 applies due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('enables or disables') and the resource ('a clip on the timeline'). It distinguishes itself from sibling tools like batch_enable_disable by implying a single-clip operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. There is no mention that batch_enable_disable exists for multiple clips, nor any context about prerequisites or typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavior. It only says 'Exports...' without mentioning whether the output file is overwritten, whether the operation is asynchronous, what happens on failure, or if the AAF embeds media or references external files. This leaves the agent without critical safety or side-effect information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the action and object, contains zero filler, and communicates the core purpose efficiently. It earns its place without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description alone is somewhat thin for a 6-parameter export tool. However, the schema covers all parameters, and the core purpose is clear. Missing details like output behavior or return values reduce completeness, but the description is minimally viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all 6 parameters, providing complete parameter documentation. The description adds no additional meaning beyond stating the file's purpose, so the baseline of 3 is appropriate; the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Exports a sequence as an AAF file for interchange with other editing/audio applications' uses a specific verb (Exports), identifies the resource (sequence), and names the output format (AAF). This clearly distinguishes it from sibling tools like export_omf or export_as_fcp_xml by targeting AAF interchange specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool over alternatives (e.g., export_omf or export_as_fcp_xml). It does not mention prerequisites, compatibility considerations, or exclusions. The context implies interchange use but offers no decision-making support for an agent choosing among export formats.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It states the primary side effect (writing an image file to outputPath) but does not disclose whether it overwrites existing files, requires specific permissions, or has any restrictions. Mutation behavior (file creation) is implied but not elaborated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or repetition. Every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description plus schema provides enough to invoke the tool correctly, but it lacks usage alternatives and behavioral side-effect details. Without annotations or an output schema, the description is minimal and doesn't fully contextualize the tool within a larger workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds no extra meaning beyond what the schema provides; for example, it doesn't clarify the default format or how time is handled beyond 'seconds'. The schema already documents each parameter adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Exports') and resource ('a single frame from a sequence') with a clear outcome ('as an image file'). This distinguishes it from sibling tools like export_sequence (whole sequence) and capture_frame (likely different capture semantics).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. It does not mention trade-offs, prerequisites, or when not to use it. The context is only implied by the purpose description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only mentions the import action and the target project, but does not disclose side effects, error conditions, or behavior regarding bins or existing items.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the verb and resource. It contains no unnecessary words and is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with full schema coverage, but there is no output schema or annotations. The description is adequate for basic usage but lacks any caveats or behavioral notes that would make it complete for an agent, especially given the many sibling import tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional parameter semantics beyond what is already documented in the schema for filePath and binName.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'imports' and the specific resource 'media file (video, audio, image)' into the current Premiere Pro project. This distinguishes it from sibling tools like import_image_sequence or import_folder.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 versus alternatives. It only states what it does without any contextual hints, exclusions, or references to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose side effects, reversibility, or whether this operation affects the clip's selection state. It simply states the action without elaborating on behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, clearly stating the action and scope. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple and the schema is complete, the description does not explain the expected outcome beyond the action, nor does it address common use cases or limitations. No output schema exists, so the description could have provided more context on results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers 100% of parameter descriptions, so the baseline is 3. The description adds contextual meaning about audio/video components but does not provide additional details about parameter syntax or constraints beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Links or unlinks') and specifies the resource ('audio and video components of a clip'), clearly distinguishing from selection-based tools like link_selection/unlink_selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 link_selection/unlink_selection or other clip manipulation tools. The description does not mention prerequisites such as requiring a clip with separate audio/video or how it relates to selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It does reveal that the operation is read-only ('lists all') and scoped to sequences, which is useful. However, it omits details about return data structure, error handling, or whether the sequence must be open.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly scoped sentence that front-loads the action and avoids all redundancy. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only one well-documented parameter and no output schema, so the description needs to convey basic behavior, which it does. However, it leaves unspecified what marker data is returned (e.g., timing, type, comments) and any prerequisites, which is a notable gap for an unannotated tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the sole parameter 'sequenceId' with a clear definition, and coverage is 100%. The tool description adds no extra parameter context, so the schema sufficiently carries the semantic weight. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the verb 'lists' and resource 'markers' with scope 'in a sequence'. The word 'all' hints at differentiation from type-specific siblings like get_sequence_markers_by_type, though it doesn't explicitly name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 related alternatives such as get_sequence_markers_by_type or get_clip_markers. There is no mention of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool lists tracks but does not disclose whether it is read-only, what properties are included, how clips are nested, or whether locked/hidden tracks are covered. The return format is also unspecified without an output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that is front-loaded with the action 'Lists all video and audio tracks' and contains no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read tool, the description gives a reasonable summary of return content (tracks with properties and clips). However, without an output schema or details on track property names, nesting, or error conditions, it is only minimally complete for an agent planning to invoke the tool and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter sequenceId, matching the 'specific sequence' mention in the description. No additional meaning is added beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Lists' and resource 'all video and audio tracks in a specific sequence with their properties and clips'. This clearly identifies the tool's function and differentiates from siblings like get_track_info 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.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as get_track_info, get_sequence_structure, or get_full_sequence_info. The only implied context is that it requires a specific sequenceId, but no exclusions or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden of behavioral disclosure, but it only restates the tool's name. It does not explain whether the selection replaces or adds to the current selection, what 'color' refers to (e.g., label color), or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, but the prefix 'Premiere Pro expanded operation:' is filler and could be removed without losing meaning. Still, it is concise overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description leaves important context undefined, such as how color selection behaves relative to the current selection and whether any value is returned. The operation is simple, but the description is too thin for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no declared parameters, and the schema with additionalProperties allows arbitrary properties, so the schema fully covers the input space. The description adds no parameter details, but baseline 4 is appropriate for a zero-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation: 'select clips by color' – a specific verb, resource, and selection criterion. This distinguishes it from sibling tools like select_clips_by_name and select_all_clips.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 other selection tools, no prerequisites or exclusions. The phrase 'expanded operation' is generic and does not help an agent choose this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior, but it merely restates the tool name. It does not explain what 'disabled' means, whether the selection is cumulative, or if any prerequisites exist. This is a minimal disclosure with no added context beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff or repetition, making it concise. However, it is under-specified, but for a zero-parameter tool, this length is acceptable. It is front-loaded with the key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity and no output schema, the description should still clarify selection behavior and the meaning of 'disabled clips.' It lacks these details, leaving ambiguity about whether it replaces or adds to the current selection and what scope it applies to. The 'expanded operation' phrase adds no concrete value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4 per the rubric. The empty schema is appropriate, and there is no need for parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'select disabled clips.' This clearly distinguishes it from siblings like select_all_clips, select_clips_in_range, and deselect_all_clips, which target different subsets or actions. The mention of 'Premiere Pro expanded operation' adds context without confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description does not indicate whether it replaces the current selection, adds to it, or in what context (e.g., timeline vs project panel) it operates. No exclusions or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the basic action and does not mention side effects, prerequisites (e.g., sequence open/active), whether playback is affected, or failure modes. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is appropriately front-loaded with the verb and resource. Every word earns its place, and there is no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but with no annotations and no output schema, the description should provide more context about the operation's effects and requirements. It mentions 'specified sequence' but does not clarify if the sequence must be active or open, nor does it indicate the result. It is minimally adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with descriptions for both parameters (time in seconds, sequence ID). The description adds no additional meaning beyond what the schema provides, so this is at the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Sets the playhead (CTI) position in the specified sequence' clearly states the verb (sets) and resource (playhead/CTI position) and scope (in the specified sequence). It is specific but does not explicitly differentiate from sibling tools like move_playhead_to_edit or get_playhead_position, so it loses a point for no sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for setting the playhead to a given time in a sequence, but it does not provide explicit when-to-use vs alternatives or any exclusion conditions. This is acceptable as an implied usage but lacks clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only states the basic action. It does not clarify whether the 'visible' parameter sets the state directly or toggles the current state, nor does it disclose any side effects or reversibility, creating ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It front-loads the core action and is appropriately sized for a simple tool with only three parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple, but the ambiguity between 'toggle' in the name and 'shows or hides' in the description creates a gap. Since there is no output schema, the description could have clarified expected behavior, but it remains minimally sufficient for a basic setter-like operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage of the three parameters with clear descriptions. The tool description adds no additional semantic meaning beyond the schema, 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.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Shows or hides a video track' clearly states the tool's function with a specific verb and resource. It distinguishes itself from sibling track tools like lock_track or mute_track by focusing on visibility, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 versus alternatives. There is no mention of prerequisites, scenarios, or exclusions, leaving the agent without context for selection despite the clear purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only mentions 'using AI-powered motion tracking' and doesn't state whether the original sequence is modified or a new one is created, what side effects occur, or any permission requirements. The 'newName' parameter hints at creating a new sequence, but this is not explicitly described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core action and purpose. Every word contributes to understanding the tool's function without redundancy or filler, achieving high conciseness and good structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal and, despite the schema covering all parameters, it fails to provide crucial context about the tool's behavior, such as whether it creates a new sequence (implied by newName) or modifies the original, or what the output/result is. With no annotations and no output schema, the description leaves several important gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters have descriptions in the schema (100% coverage). The tool description adds no extra parameter-level meaning beyond mentioning 'reframes to a new aspect ratio', which aligns with numerator/denominator. It doesn't explain optional parameters like newName or motionPreset, but the schema already handles this, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Automatically reframes'), the resource ('a sequence'), and the specific goal ('to a new aspect ratio'). This distinguishes it from sibling tools like set_sequence_resolution or crop_clip, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when a sequence needs to be reframed to a different aspect ratio, but it lacks explicit guidance on when to prefer this tool over alternatives, any prerequisites, or exclusions. It provides clear context but no explicit when-to-use/which-alternative framework.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It states the primary action ('creates a subclip') but does not disclose whether the source item is modified, whether permissions are required, what happens on failure, or whether the subclip is selected or returned. For a mutation tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no filler. It effectively communicates the core action without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, 4 required), lack of annotations, and no output schema, the description is too terse. It does not explain the effect of optional parameters like takeAudio/takeVideo/hasHardBoundaries, nor does it differentiate from similar tools like create_subsequence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema fully documents all seven parameters. The description adds no extra meaning beyond the schema; it merely references in/out points, which map to startTime/endTime already documented in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('creates') and resource ('subclip from a project item') and clearly states the key input ('specified in/out points'). It is distinct from sibling tools like set_item_in_out or create_subsequence, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use this when you need to create a subclip from a project item using in/out points. However, it does not explicitly mention alternatives or exclusions, even though siblings like set_item_in_out and create_subsequence exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It does not explain whether the deselection applies to the active sequence, whether it is undoable, or what the resulting state is. The term 'expanded operation' is vague and adds no concrete behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence, but the prefix 'Premiere Pro expanded operation' is filler that does not earn its place. It could be simply 'Deselect all clips.' The core message is concise, but the wording is not optimally front-loaded or clean.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (no parameters, no output schema), the description is mostly sufficient. It clearly states the action, and the lack of further detail is acceptable for a straightforward selection operation. However, it could benefit from a note about affecting the current sequence, but this is not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes no parameters, and the input schema is empty. The description need not explain parameters, and with zero parameters the baseline for this dimension is 4. The description does not conflict with the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'deselect all clips.' This is a specific verb+resource pair that distinguishes it from sibling tools like 'select_all_clips' and other selection-related tools. The phrase 'Premiere Pro expanded operation' adds context but the core purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not mention that it's the inverse of 'select_all_clips' or suggest scenarios like clearing the current selection. The description simply states the action, leaving the usage context implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only says 'imports', giving no details about side effects, whether the sequence is modified in a reversible way, potential errors, or what happens to existing content at the specified time. This is a significant gap for a write/import operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no filler. It is front-loaded with the key action and resource, making it easily scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no annotations, and no output schema, the description is too minimal. It doesn't explain return values, error scenarios, or the behavior of the import (e.g., clip placement, track usage). The schema covers parameters but not the overall context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents all parameters. The description adds no additional parameter meaning beyond what the schema provides, thus baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (imports), the resource (Motion Graphics Template .mogrt file), and the target (into a sequence). This is specific and distinguishes from sibling tools like import_mogrt_from_library by emphasizing 'file'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied: use this tool to import a .mogrt file into a sequence. However, it does not explicitly state when to use this versus alternatives like import_mogrt_from_library or add_to_timeline, nor any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only restates the name without detailing side effects (e.g., removal from the original bin), permissions required, or failure modes. It adds minimal value beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with no redundant words, making it highly concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two well-documented parameters, the description is brief but generally sufficient. However, it omits any context about singular vs. plural behavior (which is covered by a sibling tool) and does not mention any constraints or return behavior, so it is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides complete and clear descriptions for both parameters (projectItemId and targetBinId). The tool description adds no additional parameter-level information, so it meets the baseline without exceeding it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Moves'), the resource ('a project item'), and the destination ('a different bin'), distinguishing it from the plural variant `move_items_to_bin` by using the singular 'a project item'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as `move_items_to_bin` (plural) or other bin-related operations. There is no mention of prerequisites, conditions, or when to prefer this over the plural variant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the saving action but does not disclose side effects such as whether the current project becomes the new file, whether the original remains, or overwrite behavior. Missing key behavioral context for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the action, and every word adds value. No fluff or repetition of schema content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a save-as operation with no annotations or output schema, the description needs to clarify post-save behavior (e.g., does the project switch to the new file). It also doesn't mention return values or failure modes. Incomplete for a tool that mutates project state.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both name and location, with clear field descriptions. The tool description adds no new semantic meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Saves') and identifies the resource ('current project') with a clear scope ('with a new name and location'). It distinguishes save_project_as from siblings like save_project and export_as_project by capturing the 'Save As' semantics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the intended use (when you want to save the project under a new name/location) but does not explicitly compare with alternatives or state when not to use this tool. Clear context but no exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool scans all project items and returns a list of offline ones, which implies a read-only check. However, it does not explicitly state that it makes no modifications, nor does it mention potential performance implications of scanning the entire project, leaving some transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded with the action ('Checks all project items') followed by the output. Every word earns its place with no redundancy or irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter tool with no output schema, the description adequately explains the tool's purpose and return value. It lacks explicit mention of edge cases (e.g., what happens when no items are offline) and does not clarify its relationship to 'get_offline_media', but these are minor gaps in an otherwise complete description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty, so the baseline is 4. There is nothing for the description to add about parameter semantics, and it correctly avoids inventing unnecessary details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'checks' with the resource 'all project items' and states the output: 'a list of any that are offline (missing media)'. This clearly conveys what the tool does, but it does not differentiate from the sibling tool 'get_offline_media', which likely serves a similar function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 'get_offline_media' or 'refresh_media'. The description only states the function, leaving the agent to infer appropriate usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It states what the tool does but gives no information about side effects, prerequisites (e.g., what happens if no in/out points are set), whether the original sequence is modified, or what is returned. This gap is significant for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the main action. It contains no redundancy or filler. Every word adds meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only 2 parameters, both documented in the schema, and no output schema. The description gives the core purpose but lacks behavioral details like prerequisite conditions and side effects. It is adequate for a simple tool but leaves some ambiguity about the subsequence creation process.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters (sequenceId and ignoreTrackTargeting) documented. The description adds context about the 'in/out points' concept but does not elaborate on the parameters themselves. Since the schema already provides adequate parameter descriptions, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Creates a subsequence') and the source ('in/out points of a sequence'). It distinguishes from sibling tools like create_subclip (which creates a subclip from a clip) and create_sequence (which creates an empty sequence). The verb and resource are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when a sequence has in/out points set and you want to create a subsequence from them. However, it does not explicitly mention alternatives or when not to use it. The guidance is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It indicates a destructive operation via 'Deletes', but does not disclose whether the action is irreversible, requires specific permissions, how it handles nonexistent markers, or any side effects. This is minimal disclosure for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that gets straight to the point without any filler. It is front-loaded, easy to parse, and every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter delete operation, the description conveys the core action, but it lacks context about return values, error behavior, and relationship to other marker tools. Without annotations, some behavioral context is missing, though the operation is straightforward and the schema covers parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for both parameters (markerId and sequenceId) with 100% coverage, so the description does not need to add parameter details. Per the baseline rule, a score of 3 is appropriate because the schema handles the semantic load and the description adds no additional parameter context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Deletes a marker from the timeline' clearly states the specific action (delete) on a specific resource (marker) within a specific context (timeline). It unambiguously distinguishes this tool from siblings like add_marker, update_marker, and list_markers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it is used to remove a marker, but provides no explicit guidance on when to use it versus alternatives such as update_marker or list_markers. There is no mention of preconditions, exclusions, or related tools, leaving the usage context implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It only states 'exports' without explaining file overwrite behavior, required state of the sequence, potential errors, or what happens on success/failure. This is a significant gap for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that immediately conveys the tool's purpose. No superfluous words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple, but the description lacks details about output path handling (e.g., overwrite behavior) and does not mention any return values or error conditions. Without annotations or an output schema, this leaves some contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides complete descriptions for both parameters (sequenceId and outputPath), and the description adds no additional parameter semantics. With schema coverage at 100%, 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.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Exports a sequence as Final Cut Pro XML' clearly states a specific verb, resource, and target format. It distinguishes itself from siblings like export_omf and export_aaf by naming the exact format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when FCP XML output is needed, but it does not explicitly mention when not to use it or compare with alternatives like export_omf or export_aaf. There is no guidance on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose return format (e.g., seconds, timecode), units, error behavior on invalid sequenceId, or whether the sequence must be active. With no annotations provided, the description carries the full burden but offers only the basic fact that it retrieves a position.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the action and resource. It contains no filler or redundant information, making it highly concise and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one param and no output schema, but the description does not mention what the returned position represents or its format. Given the absence of annotations and output schema, additional detail about the return value would be necessary for full contextual completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents sequenceId as 'The ID of the sequence' with 100% coverage. The description adds no further meaning beyond paraphrasing 'specified sequence' to the parameter, so it stays at the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb (Gets) and resource (current playhead position) tied to a specified sequence. This clearly distinguishes it from sibling tools like set_playhead_position (setter) and get_source_monitor_position (source monitor, not sequence).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The descriptor 'in the specified sequence' implies this tool is for sequence playhead positions, but it does not explicitly compare to alternatives such as get_source_monitor_position or state when to prefer this over similar getters. No exclusions or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only describes the basic action and destination. It does not mention side effects, whether existing media is replaced or duplicated, default recursion behavior, supported file types, or whether a bin is created. This is minimal disclosure for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence (17 words) that is front-loaded with the action and destination. Every word adds value, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 parameters, no output schema, no annotations), the description is minimally adequate. However, it lacks context about potential duplication behavior, default recursive settings, or success/failure indicators. It could be more complete for a mutation operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all three parameters (folderPath, binName, recursive). The tool description adds no extra parameter semantics, but the baseline score of 3 is appropriate because the schema handles the parameter details well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: 'Imports all media files from a folder into the current Premiere Pro project.' The verb 'Imports' is specific, the resource ('all media files from a folder') is precise, and it is distinguishable from sibling tools like import_media (individual files) and import_sequences (sequences).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case: importing all media from a folder. However, it provides no explicit guidance on when to choose this tool over alternatives such as import_media or import_sequences, and there are no exclusions or alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action without mentioning side effects like whether the currently open project is replaced, how errors are handled, or if unsaved changes prompt a dialog.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the action and input. No filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, but given the absence of annotations and the potential side effects of opening a project, the description could benefit from more context about what happens to the current session. 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.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes the single 'path' parameter (absolute path to .prproj). The description adds no extra parameter-level detail beyond confirming 'existing project', so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Opens'), identifies the resource ('existing Adobe Premiere Pro project'), and specifies the input ('file path'). It clearly distinguishes itself from sibling tools like create_project and close_project.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for opening existing projects, but provides no explicit when-to-use or when-not-to-use guidance, nor does it reference alternatives such as create_project or save_project_as.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It simply says 'saves' without mentioning that it overwrites the existing file, how it behaves for unsaved projects, or whether it returns a status. This is minimal and lacks important behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that immediately states the action and target. It is concise and contains no unnecessary words, earning a top score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool, the description is adequate but not complete. It does not mention potential side effects (e.g., overwriting), behavior for untitled projects, or return values. Given the lack of annotations and output schema, more detail would be helpful for full contextual completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the description aligns with the empty schema. Since there are no parameters to explain, the baseline of 4 applies; the description does not need to add parameter detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('saves') and resource ('currently active Adobe Premiere Pro project'). It distinguishes itself from the sibling save_project_as by specifying the target as the active project.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 save_project_as or other save-related alternatives. The description only states what it does, without any contextual usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the basic action. It does not disclose whether setting one point preserves the other, whether an active sequence is required, or whether the operation is destructive to existing points. This is a mutating operation with no behavioral context added.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no extraneous information, earning a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description names the action and the schema documents parameters, the tool lacks annotations and the description omits important context such as required sequence state and behavior when only one point is set, so it is only minimally complete for a simple setter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all three parameters, and the description adds no additional semantics beyond the schema. The phrase 'in and/or out' hints at optionality but doesn't clarify that both are optional in the schema, potentially leaving room for confusion about calling with only sequenceId.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Sets' with a specific resource 'in and/or out points on a sequence timeline', clearly distinguishing it from sibling tools like set_source_in_out or set_item_in_out by specifying the target as the sequence timeline.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for setting sequence in/out points but provides no explicit guidance on when to prefer it over alternatives like set_source_in_out or clear_sequence_in_out, nor does it mention any prerequisites such as an active sequence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action without mentioning potential long render times, overwrite behavior, dependency on Adobe Media Encoder, or failure modes. Parameter descriptions in the schema allude to behaviors (allowOverwrite, removeOnCompletion), but the main description itself is behaviorally thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the action ('Renders and exports') and purpose, with no wasted words. It is efficiently structured and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, no output schema, no annotations), this minimal description is insufficient. It fails to explain side effects, relation to other export/render queue tools (start_batch_encode, add_to_render_queue), or post-export behavior, leaving the agent with incomplete operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 does not add any parameter-specific meaning beyond stating the core function of rendering a sequence to a video file, which the schema already captures via sequenceId and outputPath. It does not clarify deprecated parameters or the preset resolution logic.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Renders and exports a sequence to a video file' and specifies its purpose as 'creating the final video.' This distinguishes it from sibling tools like export_frame (single frame), export_omf/AAF (other workflows), and export_as_project, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'This is for creating the final video' provides clear context that this tool is intended for final video output, implicitly distinguishing it from exports of frames or intermediate formats. However, it does not explicitly name alternatives or state when not to use this tool, so it lacks full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation via 'gets', but with no annotations, it carries the full burden. It does not disclose behavior in edge cases (e.g., invalid projectItemId) or the format of the returned index.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action and resource, with no redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description adequately explains the return value (the index) but lacks details on error handling or indexing convention. With no output schema, some clarification could help, but it's sufficiently complete for a getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides full description coverage for the single parameter (projectItemId). The tool description adds no additional semantic detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'gets' and identifies the resource as 'color label index of a project item', clearly distinguishing from siblings like set_color_label and select_clips_by_color.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 versus alternatives. There is no mention of related tools or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. It clearly implies a read-only operation ('Gets') but does not disclose details such as what the returned settings structure looks like, error handling for invalid sequence IDs, or whether it returns all settings versus a subset. The phrase 'etc.' is vague but not misleading, so this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the action and object. Every word is useful; there is no redundancy or filler. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with one parameter and no output schema, the description is mostly complete. It tells the agent what the tool does and gives a hint of what 'settings' includes (resolution, framerate). However, the 'etc.' could be more explicit given no output schema exists, and there is no mention of what exactly is returned, so a small gap remains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the only parameter (sequenceId) with 100% coverage. The description only reinforces that the tool operates on a sequence, adding no new meaning beyond the schema. The baseline of 3 applies because the schema handles the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Gets' and clearly identifies the resource as 'settings for a sequence', with concrete examples (resolution, framerate). This distinguishes it from sibling tools like set_sequence_settings (which sets) and get_sequence_structure (which retrieves structure, not settings).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives such as get_sequence_structure or get_full_sequence_info. It does not mention exclusions or contrast with related getters, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It states the action but doesn't disclose edge cases (e.g., behavior if no keyframe exists at the given time) or any side effects. The mutation is implied but not elaborated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the verb and object, and contains no unnecessary words. It is efficient and easily scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a focused single-operation tool with all parameters documented in the schema, the description is largely complete. However, without annotations or an output schema, it doesn't fully communicate behavioral expectations (e.g., error handling or exact matching semantics for 'time'), leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, as all four parameters include descriptions. The description adds no additional parameter semantics beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Removes' with a clear resource ('a keyframe from a clip component parameter') and the qualifier 'at a specific time' distinguishes it from the sibling tool remove_keyframe_range. This is a precise statement of purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you need to remove a single keyframe at a specific time) but provides no explicit when-to-use guidance or alternatives. It doesn't contrast with similar tools like remove_keyframe_range, which could help an agent choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the behavioral disclosure burden. It only states the basic replacement action without mentioning side effects, reversibility, permissions, or how existing effects/settings are handled (despite the preserveEffects parameter existing in the schema). This is a meaningful gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence that front-loads the verb and states the operation efficiently. Every word adds value, and there is no unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a relatively simple 3-parameter tool with full schema coverage, the description combined with the schema is sufficient for basic invocation. It lacks deeper behavioral/return details, but the operation is straightforward and the required inputs are well-documented, so the overall package is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all three parameters clearly described in the schema. The tool description itself adds no new parameter meaning beyond what the schema already provides, 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.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Replaces' with the resource 'clip on the timeline' and the target 'another media item'. This clearly distinguishes the core operation from sibling tools like overwrite_from_source or insert_from_source, making the tool's purpose immediately understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool's usage context: replacing an existing timeline clip with a different media item. However, it provides no explicit guidance on when to choose this tool over similar siblings such as replace_clip_media or overwrite_clip, nor any exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full transparency burden. It only states the action without disclosing side effects, such as whether existing keyframes are overwritten, prerequisites (e.g., clip must have audio), or reversibility. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence, direct, and free of fluff. It efficiently communicates the essential behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only two well-documented parameters, so the description's brevity is understandable. However, without an output schema or behavioral details, the agent cannot infer return values or whether keyframes are appended or replaced. It is adequate but has gaps for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% — both clipId and keyframes are fully documented. The description adds context about the purpose (audio levels) but does not add parameter-specific details beyond the schema. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds keyframes to audio levels, with a specific scope ('for dynamic volume changes'). It distinguishes itself from generic keyframe tools like add_keyframe and other audio adjustment tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for dynamic volume changes' provides clear context for when to use this tool. However, it does not explicitly mention alternatives or when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the primary action but omits critical details such as whether existing transitions are overwritten, whether the sequence must be open, or any side effects. This is a significant transparency gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the core action and a practical usage note. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description sufficiently explains the tool's purpose and typical use, and the schema covers parameters. However, with no annotations and no output schema, an agent lacks guidance on prerequisites, error conditions, or expected outcomes beyond the side effect. It is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters are documented in the schema. The description adds a minor example ('cross dissolves') but does not enrich parameter semantics beyond the schema. The baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: 'Adds a transition to all clip boundaries on a track.' It distinguishes itself from sibling tools like add_transition or add_transition_to_clip by specifying 'all clip boundaries' and batch behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: 'Useful for quickly adding cross dissolves or other transitions between every clip.' It implies when to use this tool (batch transitions across a track) but does not explicitly exclude alternatives or state 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.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It merely restates the core function and parameter usage without mentioning side effects, prerequisites beyond import, error potential, or return behavior. The phrase 'Pass the SRT project item ID directly' adds a parameter hint but is already in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and contains no unnecessary words. Every phrase serves a purpose, such as clarifying the import prerequisite and the direct ID passing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema and no annotations, the description covers the main use case and prerequisite but omits return values, error handling, or post-creation behavior. It is adequate for a simple creation tool but leaves gaps in behavioral context that annotations or a richer description would fill.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline for this dimension is 3. The description adds minimal value beyond the schema, providing an example (.srt) and emphasizing to pass the project item ID directly, but this does not fundamentally enhance understanding beyond the parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific verb 'Creates' and the resource 'caption track on a sequence', clearly distinguishing it from the sibling 'read_sequence_captions' which reads captions. The example of .srt and mention of import_media provide concrete context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context by specifying that the caption file must be imported via import_media and instructs to pass the project item ID directly. It does not explicitly state when not to use this tool or name alternatives, but the context implies the workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states the primary action but does not disclose side effects, such as whether the project file is immediately saved to the location, whether it becomes the active project, or what happens if the file already exists. This lack of detail is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action, and no unnecessary words. Each sentence earns its place: the first states the purpose, the second provides usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with well-documented parameters, the description provides purpose and usage. However, it omits behavioral consequences (e.g., saving, active project state, error conditions) which would be expected for a creation tool without annotations or an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both 'name' and 'location' having descriptive comments. The description does not add any additional parameter semantics, 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.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a new Adobe Premiere Pro project with the verb 'creates' and the resource. It also adds 'from scratch' which differentiates it from sibling tools like open_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.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: 'Use this when the user wants to start a new video editing project from scratch.' It does not explicitly mention alternatives or when not to use it, but the context is clear for a simple create operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should carry the burden of behavioral disclosure. It states the core action but does not describe side effects like whether the duplicate is selected, its exact placement beyond what the offset parameter implies, or any return value. The schema partially compensates by explaining the offset behavior, but the description itself adds little contextual depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that directly conveys the purpose. No unnecessary words or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter mutation tool with no output schema and no annotations, the description is minimally viable but does not fully elaborate on the duplicate's placement, selection state, or return value. The offset parameter's schema description covers some context, but overall completeness is adequate yet leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for both parameters (clipId and offset). The description adds no parameter information beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Duplicates' with a clear resource 'a clip on the timeline', which distinguishes it from sibling tools like duplicate_sequence. It unambiguously states the action and target.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when duplicating a clip), but does not explicitly exclude alternatives or mention when not to use it. It lacks guidance relative to other clip operations, though the distinct name helps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the search action and target types, but fails to mention whether it returns all matches or a single item, whether it selects the found item, how results are presented, or any side effects. The schema adds case-insensitive partial matching, but that is structured data, not description value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the action, and contains no filler. Both sentences earn their place: the first states the core function, the second provides context on applicable item types.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 parameters, no output schema), and the description provides a baseline understanding. However, it omits return value semantics and does not clarify how this tool relates to overlapping siblings like search_project_items. Given the lack of annotations and output schema, the description could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 'name' and 'type'. The description adds no parameter-specific details beyond what the schema provides, which is acceptable given the high coverage. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'searches' and a specific resource 'project items' with a clear scope 'by name'. It distinguishes itself from siblings like find_items_by_media_path (searches by media path) and search_project_items (likely more extensive) by explicitly naming the search criterion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Useful for finding media files, sequences, or bins' provides clear context on when to use this tool, aligning with the type filter. However, it does not explicitly state when not to use it or mention alternatives like search_project_items for more complex searches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses that it returns 'readable' presets and admits that factory preset enumeration is incomplete, which are useful behavioral details. However, it does not explain the return format, default folder behavior, or error handling, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the primary purpose and followed by a relevant caveat. There is no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple discovery tool, it covers the key limitation (factory presets not complete). However, there is no output schema and no description of the return value or how the discovered presets can be used with sibling encoding tools, leaving the agent to infer the result format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with a clear description of the optional 'directories' parameter. The tool description adds no additional parameter semantics, but the schema already provides full meaning, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: discovering readable user Adobe Media Encoder .epr presets from local AME preset folders. It uses a specific verb (discovers) and a specific resource, and the caveat about factory presets clarifies its scope, distinguishing it from potential preset enumeration tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (for discovering user presets) but does not explicitly compare against alternatives or state when not to use it. The schema provides guidance for the optional directories parameter, but the overall usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden of behavioral disclosure. It indicates a read-only operation via 'Gets' but does not detail potential nuances such as whether disabled clips are included, ordering, or side effects. For a simple getter, this is minimally acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action and scope, containing zero redundant or vague wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description explains the conceptual return (selected clips) but not the structure of the return value (e.g., array of clip IDs vs. objects). Given the lack of annotations and output schema, this is a notable but minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents the single parameter sequenceId with 100% coverage, so the description adds no extra parameter-level meaning. Baseline of 3 applies as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Gets'), the object ('all currently selected clips'), and the scope ('in the specified sequence'), which distinguishes it from sibling selection tools like select_all_clips or deselect_all_clips that modify selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its use for retrieving the current selection in a given sequence but provides no explicit guidance on when to use it vs. alternatives or when not to use it. Since the purpose is straightforward, the implied usage is adequate but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of behavioral disclosure. It only says it 'builds' a timeline but does not state that it creates a new sequence, whether source media is modified, whether existing sequences are overwritten, or what the tool returns. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and contains no unnecessary words. It is concise yet covers the main purpose and the two operational modes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a complex clipPlan and no output schema, yet the description does not mention what the tool returns, any prerequisites (e.g., media must be imported), or side effects beyond 'builds'. This leaves the agent under-informed for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaningful value by explaining the two modes: template defaults (fallback parameters) versus an explicit clipPlan that overrides them. This conceptual relationship is not evident from the schema alone, justifying a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Builds') and names the resource ('production-oriented promo timeline') and source ('real media assets'), clearly distinguishing it from siblings like build_motion_graphics_demo and build_brand_spot_from_mogrt_and_assets, which target different asset types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for when to use the tool: when you have real media assets and want either template defaults or an explicit clipPlan for LLM-directed pacing and effects. However, it does not explicitly mention alternative tools or exclusion criteria, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses that default polish is optional and that clipPlan can drive creative direction, but it omits operational details such as whether a new sequence is created, whether existing sequences are overwritten, what prerequisites exist (e.g., open project, valid media paths), and 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the primary action ('Builds a branded ad assembly') and followed by key differentiators. Every clause adds meaningful guidance, with no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex 12-parameter assembly tool with no output schema and no annotations. The description conveys the high-level goal but omits crucial context: usage alternatives, side effects, prerequisites, return values, and safety behavior. The rich schema does not compensate for these operational gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% parameter coverage, so the baseline is 3. The description adds semantic framing beyond schema by connecting 'optional MOGRT overlay' to mogrtPath, 'explicit clipPlan control' to clipPlan, and explaining that applyDefaultPolish can be left off to allow LLM-driven creative direction rather than hardcoded passes. This helps the agent decide how to set parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Builds') and names the resource ('branded ad assembly'), while calling out distinct capabilities: 'optional MOGRT overlay' and 'explicit clipPlan control.' These features differentiate it from siblings like assemble_product_spot or build_motion_graphics_demo, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: build a branded ad from real media assets, optionally add a MOGRT, and control the edit via clipPlan. It also implies a design choice by noting 'Default polish is optional so creative direction can come from LLM planning.' However, it does not explicitly name alternatives or state when not to use this tool, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It clarifies that a bin is a folder in the project panel and adds the context 'to organize media', but it does not mention potential side effects, permission requirements, or failure conditions, leaving these aspects implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence (12 words) that states the core function and context with no redundant phrasing. It is front-loaded and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create operation with full schema coverage and no output schema, the description is adequate and unambiguous. However, it could further clarify that parentBinName is optional or explain what happens when no parent is specified, which would make it more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both 'name' and 'parentBinName' documented in the schema. The description adds no parameter-specific details beyond what the schema already provides, so it meets the baseline but does not enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'creates' and identifies the resource as a 'new bin (folder)' in the 'project panel', clearly distinguishing it from sibling tools like delete_bin, rename_bin, and create_smart_bin. It also indicates the purpose ('to organize media').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for organizing media in the project panel but does not explicitly state when to use it over alternatives like create_smart_bin or delete_bin. There is no when-not guidance or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It states only that it retrieves settings, without noting that it's read-only, potential return format, or error conditions. This leaves the agent without crucial context about side effects or output structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence that front-loads the action and resource, includes useful enumerations, and contains no redundant fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description provides sufficient context about the purpose and the kind of data returned. It could be improved by specifying the return structure, but the examples mitigate this gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter projectItemId is documented in the schema with a basic description ('The ID of the project item'), achieving 100% schema coverage. The description adds no additional parameter semantics beyond what the schema already 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.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Gets' and identifies the resource as 'footage interpretation settings' for a project item, with examples (frame rate, pixel aspect ratio, field type). This clearly distinguishes it from sibling tools like set_footage_interpretation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear that this tool is for retrieving footage interpretation settings, but it does not explicitly mention alternatives or when-not-to-use scenarios. The presence of a sibling setter implies its role, but no direct guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing side effects. 'Gets' implies a read-only operation with no destructive behavior, but it does not state prerequisites (e.g., open sequence) or behavior on invalid input.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It efficiently states the action and target resource, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with one fully documented parameter, the description is adequate for selection and invocation. It lacks return format details and prerequisites, but the low complexity minimizes the impact of these omissions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents sequenceId with a clear description and 100% coverage. The tool description adds no additional parameter semantics, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the operation as retrieving the in and out points of a sequence timeline. The verb 'Gets' and specific resource distinguish it from sibling tools like set_sequence_in_out_points and clear_sequence_in_out.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when/when-not guidance or alternative tools are mentioned. However, the getter nature implies it is used to read the current sequence in/out points, making the usage context implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it 'gets' the in/out points, implying a safe read operation, but does not describe return format, error behavior (e.g., when no work area is set), or whether a sequence must be open. Basic behavior is clear, but details are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence (10 words), front-loaded with the action verb 'Gets', and contains no filler or redundant details. Every word earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple tool with one parameter and no output schema, so the description is nearly complete. It clearly states what is retrieved and for which entity. However, it does not specify the output format (e.g., ticks, seconds, dict) or any prerequisites, which would be helpful but is mitigated by the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the single parameter 'sequenceId' with a description ('The ID of the sequence'), so schema coverage is 100%. The tool description adds no additional meaning to the parameter, such as where to obtain it or its format, matching the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Gets' with the resource 'work area in/out points' and delimits scope 'for a sequence'. This clearly distinguishes it from sibling tools like set_work_area and is_work_area_enabled, making the purpose immediately unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives. It implies a read operation, but does not contrast with set_work_area or is_work_area_enabled, nor does it mention prerequisites like an open sequence or active sequence. The usage context is only implied by the verb 'Gets'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description is the only source of behavioral info. It clearly states the effect (mute/unmute) and the scope (entire track), but doesn't disclose any further side effects, prerequisites, or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, zero waste, front-loaded with the action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple state-change tool with three well-documented parameters and no output schema, the description is sufficient. It could mention when the track is an audio track, but it already says 'audio track'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all three parameters. The description doesn't add any additional semantic detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool mutes or unmutes an entire audio track, specifying both the action and the resource. It distinguishes itself from sibling tools like lock_track or toggle_track_visibility.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case (muting/unmuting a track) but provides no explicit when-to-use guidance or alternatives. For a simple setter, the use case is clear from the verb.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It adds useful context by stating it operates in a single ExtendScript call, returns per-clip results, and saves roundtrips. However, it does not disclose potential failure modes, whether existing effects are replaced or appended, or any prerequisites beyond what the schema mentions, leaving gaps about the mutation behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, front-loaded with the core purpose ('Bulk: applies...'), and each sentence adds value: one for the action and one for the benefits. No wasted words or redundant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool involves a nested parameters object and no output schema, so the description should clarify the return format. It only vaguely says 'Returns per-clip results', without detailing the structure or error handling. It also does not distinguish from sibling batch_apply_effect, leaving some ambiguity about its unique role, though the bulk-all-clips scope is evident.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all parameters with detailed descriptions, including effectName examples and the note that sequenceId must be the active sequence. The description itself does not add any parameter-specific semantics, so it stays at the baseline of 3 given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'applies', the resource 'a single audio effect', and the scope 'to ALL audio clips of a sequence', distinguishing it from singular or non-bulk audio effect tools. The 'Bulk:' prefix and 'in one ExtendScript call' further specify the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does 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: 'Saves N MCP roundtrips when calibrating or applying same chain' and the 'Bulk' label imply use for applying the same effect to all clips. However, it does not explicitly mention when not to use it or name alternative tools like apply_audio_effect for single clips, so no explicit exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey the behavioral profile. The verb 'Gets' clearly indicates a read-only operation, implying no side effects. It also enumerates the kind of information returned, which adds transparency beyond just the name. However, it does not explicitly state that it does not modify anything, but for a getter this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence. Every phrase adds value: the verb, the resource, and the specific fields. No unnecessary words or repetition. It is as concise as possible while remaining informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool, the description adequately scopes what is included (name, path, settings, status). It does not have an output schema, so the description itself must communicate the return value shape. The use of 'comprehensive' is somewhat vague and there is no mention of the response structure, but the listed categories give a reasonable baseline. Given the presence of a sibling 'get_full_project_overview', this could be more precise.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is 100% covered by an empty properties object. The baseline for 0 params is 4. The description does not need to explain parameters, and the listed info categories provide context for what will be returned, which is valuable given the lack of an output schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets comprehensive information about the current project and lists specific fields (name, path, settings, status). However, it does not differentiate from the sibling tool 'get_full_project_overview', which likely overlaps in scope, so it lacks explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'current project' implies the tool is used when project-level information is needed, but there is no explicit guidance on when to use this over alternatives like 'get_sequence_settings' or 'get_full_project_overview'. No when-not or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The verb 'Lists' implies a read-only operation, but the description does not explicitly state side effects or behavioral details such as output format, sort order, or inclusion of third-party effects. Since no annotations are provided, the description carries the full burden but adds minimal transparency beyond the core purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clearly worded sentence that immediately states the tool's function. There is no wasted content, and the essential information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless list tool with no output schema, the description 'Lists all available video effects in Premiere Pro' fully conveys the tool's purpose and expected return. It is sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, as indicated by the empty input schema. According to the baseline rule for 0 params, the description is not expected to explain parameter behavior, so a score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Lists' and a specific resource 'all available video effects' with context 'in Premiere Pro'. This clearly distinguishes it from sibling tools like list_available_audio_effects and list_available_transitions by explicitly limiting to video effects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 versus alternatives. It does not mention exclusions, prerequisites, or alternative tools. The usage is only implied by the tool's name and the generic description, not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden. It goes beyond 'applies an effect' by stating the tool 'identifies the exact newly created component' and 'verifies parameter readbacks,' giving the agent expectations about return values and side effects. However, it does not mention permissions, reversibility, or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly composed sentence that leads with the core action and appends two meaningful behavioral details. Every phrase adds value, with no verbose or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core operation and adds post-apply behaviors (component identification and readback verification), which is helpful given the absence of an output schema. However, it does not describe what is returned (e.g., component ID or verification results) or how parameters should be structured, though the schema covers parameter syntax.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema documents all three parameters with clear descriptions (coverage 100%), so the description does not need to add parameter details. The description adds no extra semantic information beyond what the schema already provides, thus baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('Applies a visual or audio effect to a clip') and clearly distinguishes itself from siblings like remove_effect, batch_apply_effect, and list_clip_effects. It also adds unique behavioral details (identifying the component and verifying readbacks) that further differentiate it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (apply an effect to a specific clip) but provides no explicit guidance on when to choose this tool over alternatives such as batch_apply_effect for multiple clips or set_effect_property for adjusting existing effects. No exclusions or alternative names are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the key behaviors: generating stills, creating a sequence, adding dissolves, and applying scale animation. It explains the multi-step process and the intended aesthetic. It does not mention prerequisites or side effects, but the description is granular enough to set expectations for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently lists the steps without redundancy. Every phrase adds value, and the information is front-loaded with the primary action ('Generates clean demo stills') followed by supporting details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema and no annotations, the description provides a comprehensive overview of its behavior. It explains the full sequence of actions and the intended outcome. It could mention the optional sequenceName parameter or prerequisites, but overall it is sufficiently complete for a high-level automation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter (sequenceName), so the schema already documents its purpose. The description does not add any additional meaning about the parameter, but the baseline of 3 applies because the schema covers the parameter semantics adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Generates'), names the resource ('demo stills', 'sequence', 'timeline'), and describes the full workflow. It clearly distinguishes itself from sibling tools like 'create_sequence' or 'assemble_product_spot' by explicitly mentioning 'motion graphics demo' and the specific effects (dissolves, scale animation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context with 'polished minimalist ad-style demo' but does not explicitly state when to use this tool over alternatives. It does not mention when not to use it or name alternative tools for different scenarios, leaving the comparison to the agent's inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It accurately states that the tool lists all available audio transitions, which implies a read-only operation, but it does not disclose return format, whether a project must be open, or any other behavioral details. For a simple list operation, this is minimally adequate 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that immediately communicates the operation. No wasted words, ideal structure for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters, so the description covers the primary behavior. However, without an output schema or annotations, it doesn't specify the structure of the returned list (e.g., names, IDs), leaving some ambiguity. Still, for a list operation, this is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema fully covers parameter semantics. Baseline for zero-parameter tools is 4, and the description adds no parameter-specific information, which is acceptable since no parameters exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Lists' and resource 'all available audio transitions', clearly distinguishing it from sibling tools like 'list_available_transitions' (which could include video) and 'list_available_audio_effects' (effects vs. transitions).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for discovering audio transitions but provides no explicit when-to-use or exclusions. It doesn't mention alternatives like 'list_available_transitions' or 'list_available_audio_effects', so guidance is only inferred from the tool name and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It implies a read-only operation by saying 'Lists' and 'discover,' but it does not explicitly state the tool makes no modifications, nor does it mention any performance implications or permissions. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, both essential: the first states what it does, the second states when to use it. No filler, no repetition, and it is front-loaded with the core function immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only two optional parameters and no output schema. The description covers the purpose and usage adequately, though it does not detail the return format. However, given the simplicity, this is near-complete; a full 5 would require a bit more detail on what the response structure looks like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptions for 'includeBins' and 'includeMetadata', so the baseline is 3. The description adds no additional parameter guidance beyond that, leaving the agent to infer parameter usage from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Lists') and resource ('all media items, bins, and assets in the current Premiere Pro project'), making the tool's purpose unmistakable. It clearly distinguishes this from sibling tools like 'list_sequences' or 'get_project_item_info' by its broad scope of 'all' items in the project.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'Use this to discover available media before performing operations.' It implies this is the go-to discovery tool, but it does not explicitly mention when not to use it or reference alternatives, so it misses the top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It adds the consequence 'prevent/allow editing', which goes beyond the raw action. However, it does not disclose potential error conditions, whether the lock affects clips already on the track, or any prerequisites like an active sequence. This is a minimal but non-zero disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the verb and resource, and contains no extraneous words. It earns its place by clearly stating the action and purpose without elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with 4 fully documented parameters and no output schema, so the description does not need to explain return values. The purpose and effect are covered, and the schema handles parameters. It could be improved by noting prerequisites (e.g., sequence must be open) but overall it provides sufficient context for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter having a clear description (e.g., 'Whether to lock (true) or unlock (false)', 'The ID of the sequence'). The tool description itself adds no parameter-level detail, so the baseline score of 3 applies; the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Locks or unlocks') and resource ('a track') with the purpose ('to prevent/allow editing'). This clearly distinguishes it from sibling tools like toggle_track_visibility, which controls visibility, and rename_track, which changes names.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this tool to lock or unlock a track for editing. It does not explicitly name alternatives or exclusions, but among the siblings there is no other lock/unlock tool, so the usage context is clear. A slight omission is not mentioning when not to use it (e.g., if the track is already in the desired state).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It discloses the default behavior when no track arrays are provided, which is useful, but does not mention side effects, reversibility, or what happens to existing clips. More detail could be added.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the primary action, and contains 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.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a straightforward multi-track cut operation, covering the action and default behavior. Parameter details are covered by the schema. It could mention the result of the cut or the active sequence, but overall it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all parameters already have descriptions. The tool description reinforces the default behavior of track indices but does not add meaningful information beyond the schema. Thus, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool cuts multiple tracks at an absolute timeline time, using a specific verb and resource. It also clarifies the default behavior when no track arrays are provided, which distinguishes it from similar tools like razor_all_tracks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: to cut at a specific time across multiple tracks. It explains the default behavior for missing track arrays, but does not explicitly name alternative tools or state 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the action but does not disclose potential side effects, requirements (e.g., file existence), permissions, or whether the operation is reversible. This is a moderate gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that immediately states the tool's purpose. No redundant words or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool, the description covers the core functionality and use case. However, without an output schema, it does not mention what the tool returns (e.g., success indicator), which is a minor gap. Overall, it is reasonably complete given its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters clearly documented. The description adds no extra meaning beyond the schema, simply restating that a new file path is used and identifying the project item.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Relinks') and a specific resource ('an offline or moved media file') to a new file path. It distinguishes itself from related tools like replace_clip_media by focusing on relinking existing media rather than replacing it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: when a media file is offline or has been moved. It does not explicitly name alternatives or state when not to use, but the context is sufficient for typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It adds a meaningful behavioral detail: if sequenceId is omitted, it searches the active sequence first, then all sequences. However, it does not mention destructive side effects, undo behavior, or any prerequisites beyond the sequenceId hint, which is a notable gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action and followed by a targeted usage hint. Every word earns its place; no fluff or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple three-parameter tool with no output schema. It covers the core operation, the tricky sequenceId case, and refers to the related tool list_sequence_tracks. While it doesn't mention side effects or undo, the schema handles parameter details, so the description is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes all three parameters (100% coverage), giving a baseline of 3. The description adds value beyond the schema by specifying when to use sequenceId in a concrete context (clip ID from list_sequence_tracks for a non-active sequence), which is not captured in the parameter description itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Removes a clip from the timeline' with a specific verb and resource. The second sentence adds a scoping detail about sequenceId, distinguishing it from simpler removal tools like remove_selected_clips by indicating how to handle clips from non-active sequences.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a specific, useful guideline for when to pass sequenceId (when the clip ID came from list_sequence_tracks for a non-active sequence). However, it does not explicitly contrast this tool with alternatives like remove_selected_clips, lift_selection, or ripple_delete, leaving the choice among siblings implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses important behavioral details about the return format (position in normalized and pixels, using sequence frame size) and the implicit read-only nature. It does not cover error cases or exhaustive property list, but the disclosed details are meaningful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, then specific details about output and sequenceId. No wasted words; every sentence contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description provides essential return value details (motion.position format) and a usage condition. It is fairly complete for a read-only property retrieval tool, though it does not enumerate all properties beyond motion.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters. The description adds extra context for sequenceId beyond the schema, explaining when it is needed. This is a value-add over the structured field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets detailed properties of a clip and specifically calls out Motion values, making the purpose explicit. However, it does not explicitly differentiate from sibling tools like get_effect_properties or get_full_clip_info, so it misses the 'distinguishes from siblings' bar.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for when to pass sequenceId (when clip ID came from list_sequence_tracks for a non-active sequence). It does not mention when not to use the tool or alternatives, but the usage note is specific and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It describes the action ('renames') and a side-effect context (the duplicate_sequence naming issue), but does not disclose potential limitations, error conditions, or return behavior. It is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences, about 30 words, with the core action in the first sentence and a practical use note in the second. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool with no output schema, the description is complete. It states the purpose, the target resource types, and a specific usage context. The sibling tool list provides enough surrounding context to understand when this tool is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description adds no extra meaning about parameter constraints or relationships beyond what is already in the schema, earning the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Renames a project item (sequence, bin, clip) by setting its name.' This provides a specific verb and resource, and explicitly enumerates the item types, distinguishing it from siblings like rename_track or rename_bin.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a concrete usage scenario: 'Use this when duplicate_sequence does not propagate the new name to the project panel.' This advises when to use the tool, though it does not mention alternative tools for renaming clips/bins/tracks directly, so it lacks explicit when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the MOGRT requirement and field mapping but omits side effects such as imported project items remaining (mentioned only in schema for rollbackOnTextFailure) and the best-effort nature of duration. These omissions prevent a higher score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three focused sentences, front-loading the main purpose and then providing necessary requirements and mapping details with no filler. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (11 params) and rich schema, the description adequately explains the core behavior and the trickiest part (MOGRT text mapping). It doesn't cover all parameters, but the schema handles those, so this is complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, providing a baseline of 3. The description adds extra meaning through the example 'Basic Lower Third' and clarifies how text/text2 etc. map to AE.ADBE Text components, going beyond the schema's individual parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Adds a text layer (title) over the video timeline.' It further specifies the MOGRT requirement and the up-to-4-field mapping, distinguishing it from generic timeline or adjustment tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context by stating the MOGRT requirement and the intended text field usage. It does not explicitly list alternative tools or exclusions, but the prerequisite is implied sufficiently for a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries full responsibility and provides excellent coverage: it discloses a status/verified result field, explains the accepted_unverified state ('Premiere accepted the command but inspection could not prove the edit'), and explicitly warns not to retry automatically. This gives the agent actionable decision-making context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences; the first fronts the core action ('Adds a transition...') and the second delivers crucial result-handling advice. No filler or redundancy; each clause contributes operational value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description compensates by explaining the key edge case (accepted_unverified). Combined with 100% parameter schema coverage, this is largely complete, though it could mention failure modes like invalid transition names or prerequisites (e.g., active sequence).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for clipId, duration, position, and transitionName. The tool description adds no parameter-specific details beyond the schema, which matches the baseline of 3 for high coverage. The position enum (start/end) is also repeated in the description, so no new semantic information is gained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses 'Adds a transition to the beginning or end of a single clip' with a specific verb and resource. The scope qualifier 'single clip' distinguishes it from sibling batch operations like batch_add_transitions. This is a clear, unambiguous statement of the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'single clip' implies the tool's use case, and 'do not retry automatically' provides a clear operational directive. However, no alternative tools are mentioned; given the siblings add_transition and batch_add_transitions exist, explicit when/when-not guidance would strengthen this dimension.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, and it does a solid job. It reveals that execution happens locally via child_process with ffmpeg, requires ffmpeg on PATH, returns an explicit error if ffmpeg is missing, and is non-destructive. It does not specify the exact shape of the returned intervals, but it covers the most important behavioral and operational traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, each earning its place: clear action, execution/reason, safety, and follow-up usage. It is front-loaded with the core purpose and avoids redundant rephrasing of the schema. No filler or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers the key contextual needs: external dependency (ffmpeg), failure behavior, non-destructive nature, and how to act on the results. It could be more explicit about the interval format (e.g., start/end times and units), but it is otherwise complete enough for an agent to select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all four parameters with descriptions, defaults, and examples, so schema coverage is 100%. The description adds little parameter-specific meaning beyond noting the use of the silencedetect filter and pointing to the returned intervals. This matches the baseline expectation for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Analyzes a media file's audio for silent stretches using ffmpeg's silencedetect filter.' It clearly distinguishes this tool from editing/destructive siblings by stating 'This is DETECTION ONLY -- it does not cut or modify anything,' and even notes why Premiere's scripting API cannot do this. This makes the tool's purpose unmistakable and well differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool (to detect silence) and explicitly rules out Premiere's scripting API as an alternative. It recommends follow-up tools (split_clip/ripple_delete/razor_timeline_at_time) for removing detected silence. While it doesn't enumerate exhaustive when-not-to-use scenarios, the intended usage and downstream workflow are clearly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and does well: it states the tool is read-only, that checkConnection is optional and defaults to false, and that no Premiere request is made otherwise. It doesn't mention error handling or exact return shape, but for a capability report this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main purpose, followed by the parameter behavior. No filler words, each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool and the well-documented schema, the description is largely complete. It covers what the tool reports and the optional flag behavior. A minor gap is not describing the output format, but with no output schema and the nature of capability reporting, this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter checkConnection is fully described in the schema (100% coverage) with clear semantics and default. The description adds only a small note about being read-only and the default behavior, which is already implicit in the schema. This matches the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Reports') and enumerates the exact resources it covers (runtime, bridge status, catalog sizes, integration surfaces). This distinguishes it from siblings like verify_premiere_connection and get_version_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit context on when to set checkConnection and explains the default behavior (non-invasive capability discovery). It references verify_premiere_connection as the underlying check, giving a hint of alternatives, though it doesn't explicitly say 'use verify_premiere_connection instead.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that Premiere creates a new sequence, that UI suppression is requested, and that malformed/unsupported XML can be rejected. This is more transparent than average, though it omits details like undo behavior and return values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences with zero waste: purpose, outcome, and critical warning/guidance. Every sentence earns its place, and it's front-loaded with the main function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given only one parameter and no output schema, the description covers the essential context: what gets created (new sequence), the expected input format, and a key failure mode. It could mention if the import is additive to the current project or how success/error is reported, but it's quite complete for a single-param tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema property description fully covers the filePath parameter (absolute path, .xml extension), so schema coverage is 100%. The description adds no new parameter-level meaning beyond identifying the file type as FCP7 XML, which is already implied by the tool's purpose. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool imports a Final Cut Pro 7 XML (XMEML) file into the current project, specifying the exact resource and action. It distinguishes from siblings by explicitly noting it's for FCP7 XML, not modern FCPXML from FCP X, setting it apart from import_edl and import_sequences.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear usage context: import legacy FCP7 XML files, not FCPXML 1.x. This is an explicit when-to-use and when-not-to-use guideline. However, it doesn't name alternative tools like import_edl or import_media, so it stops short of the 'alternatives' level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The verb 'Lists' clearly indicates a read-only, non-destructive operation. It does not mention any side effects or prerequisites, but for a simple listing tool, the behavior is transparent enough. A higher score would require explicit confirmation of non-destructiveness or context requirements, but the simplicity of the operation justifies this score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action and resource, and contains no unnecessary words. Every word earns its place. It is highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description is complete enough: it tells the agent exactly what the tool does and implies what the return value is (a list of audio effects). It could be argued that a bit more detail about the output format or context would be helpful, but for a trivial listing tool, this is sufficient. The score reflects the minimalistic nature without penalizing unnecessarily.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is an empty object with no parameters. Per the baseline for 0 parameters, the description does not need to explain parameters. The description adds no parameter-related information, but none is needed. The schema provides full coverage (100%), so this dimension is satisfied.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Lists all available audio effects in Premiere Pro.' It uses a specific verb ('Lists') and a specific resource ('all available audio effects'), and it distinguishes itself from sibling tools like list_available_effects (which likely lists all effects) and list_available_audio_transitions (audio transitions, not effects). The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when you want to see what audio effects are available in Premiere Pro, but it provides no explicit guidance on when to use this tool versus alternatives like list_available_effects or list_available_audio_transitions. There is no 'when not to use' or mention of prerequisites, so usage context is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. The verb 'Lists' implies a read-only operation without side effects, which is useful but not explicit. The description does not mention return format, performance, or any edge cases, but for a simple listing tool this may be adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, front-loaded with the primary action. It contains no filler or redundant information, earning a perfect conciseness score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only listing tool, the description is complete in stating what it returns (available video transitions). It could be enhanced by explicitly noting the return format or read-only nature, but given the simplicity, it meets the minimal requirements without major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter schema to explain. The description appropriately focuses on the action and resource. A baseline of 4 is justified since parameter semantics are irrelevant here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Lists' with a clear resource ('available video transitions') and scope ('in Premiere Pro'). This distinguishes it from sibling tools like list_available_audio_effects and list_available_effects, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: this tool is for listing available video transitions, as opposed to audio transitions or effects. No explicit exclusions or alternatives are mentioned, but the simple scope and sibling naming provide sufficient guidance for when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. It implies a read-only operation ('Lists') and specifies the output fields, but does not mention edge cases such as behavior with no open project, sort order, or whether 'basic properties' includes mutable fields. This is acceptable for a simple list tool but not highly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence starting with the action verb 'Lists', followed by the target and output details. It is concise, front-loaded, and contains no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description explains the return value by mentioning IDs, names, and basic properties, which gives the agent a reasonable expectation. However, 'basic properties' is somewhat vague, and the description could be improved by listing examples of those properties. Still, the scope ('current project') is explicit and the tool is simple enough that this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description correctly omits parameter details. According to the baseline for 0-parameter tools, a score of 4 is appropriate since no parameter explanations are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Lists' with the resource 'all sequences in the current Premiere Pro project' and states the output contents (IDs, names, basic properties). This clearly differentiates it from sibling tools like list_sequence_tracks (which lists tracks) and get_sequence_count (which returns a count).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by scoping to the 'current Premiere Pro project', which tells the agent when this tool is appropriate. It does not explicitly mention alternatives or when not to use it, but for a basic listing tool the usage is self-evident and no exclusions are necessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the return format (per-clip result array with an applied map) and the success semantics (success only when every property is found and set, with missing properties reported rather than silently ignored). This is valuable, though it does not mention potential side effects like overwriting existing properties or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core action. It provides essential context (speed advantage) and return semantics in two sentences, with no filler or repetition of schema details. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter, fully covered by the schema, and no output schema. The description compensates for the missing output schema by clearly explaining the return array structure and success criteria. It also covers the batch behavior and error reporting, making the tool's behavior sufficiently complete for an agent to understand and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so parameters are fully described in the structured data. The description does not add additional parameter-level meaning beyond listing the property names (opacity/scale/rotation/position) already in the schema. Baseline 3 is appropriate because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: applies Motion properties (opacity/scale/rotation/position) to many clips in a single round-trip. It distinguishes itself from the singular set_clip_properties by emphasizing the batch capability and speed advantage, making it unique among sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly identifies this as the fast path for per-speaker framing across a rebuilt edit and compares it to set_clip_properties with a 50x speed advantage. This gives clear context for when to use the batch version, though it does not explicitly state when not to use it (e.g., for a single clip).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explicitly discloses the tool is non-destructive and enumerates what it checks. This is meaningful behavioral context, though it stops short of detailing return type or error behavior, which would be useful for agents.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no redundancy. The first sentence gives the core purpose, and the second efficiently lists the audit categories. Every syllable earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides a solid overview of scope and checks, but does not specify what the tool returns (e.g., boolean, list of issues, or throws errors). Since there is no output schema, this omission is a notable gap for agents to interpret results. Otherwise, it is reasonably complete given the moderate complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by mapping outputPath/presetPath to 'missing export preset/output folder inputs' and sequenceId to 'active or requested sequence,' enriching the schema's semantic meaning beyond simple field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines the tool as a non-destructive export readiness audit, with a specific verb ('Runs') and resource (project/sequence). It lists concrete checks (timeline content, offline media, gaps, markers, etc.) and distinguishes itself from sibling export/encode tools by focusing on pre-flight validation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states its usage context: 'before an agent queues an export.' This gives clear when-to-use guidance. It does not explicitly name alternative tools or exclusion cases, but the context is intuitive given the tool's name and sibling export functions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses key behavioral traits: an existing Crop effect is reused when present, otherwise one is added, and omitted parameters keep their current/default values. This goes beyond the schema's parameter definitions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and every clause adds value. There is no filler or redundant restating of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the schema's thorough parameter documentation and the description's coverage of effect reuse and omitted-parameter behavior, the tool is well-specified for invocation. No output schema exists, so return values do not need to be explained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers all 7 parameters with descriptions and ranges, so the baseline is 3. The description adds meaningful semantics by stating that omitted parameters retain current/default values and that existing effects are reused, which is not encoded in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Crops') and names both the resource ('timeline clip') and the mechanism ('Premiere Pro's built-in Crop video effect'). This clearly distinguishes crop_clip from generic transform or effect tools among the siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context that the tool is for cropping clips via the built-in Crop effect and explains the conditional reuse behavior. It does not explicitly name alternatives or exclusions, but the intended usage is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses a key behavioral nuance: the tool currently returns guidance for Adobe Media Encoder rather than live queue telemetry. This goes beyond a simple status check and prevents false expectations. Minor ambiguity remains about the exact return shape (boolean vs. string), but the main caveat is well communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences. The first sentence states the primary purpose, and the second provides a critical caveat without any fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description adequately covers the essential context: what it reports and its current limitation. An example return value or more explicit type information would improve it, but it is still sufficient for an agent to decide whether to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema has 100% coverage (empty object), so no parameter documentation is needed. The baseline for zero-parameter tools is 4, and the description adds no unnecessary parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses 'Reports whether render queue monitoring is available,' providing a specific verb and resource. It also distinguishes itself by explicitly noting it returns Adobe Media Encoder guidance rather than live queue telemetry, which separates it from sibling tools like add_to_render_queue or start_batch_encode.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool: to check render queue monitoring availability. It also warns that it does not provide live queue telemetry, setting expectations and preventing misuse, though it does not explicitly name an alternative tool for live telemetry.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
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 key behavioral trait: the tool does not import but reports unavailability, and explains why. However, it does not specify the exact return value or outcome when invoked (e.g., error, message), 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: the core behavior, the technical reason, and the alternative. Perfectly front-loaded with the most important information first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a stub tool with one parameter and no output schema, the description is quite complete: it explains the limitation, the reason, and the recommended path. It could be improved by explicitly stating the return behavior, but overall it gives an agent enough context to avoid misuse.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with filePath described as 'The absolute path to the .edl file'. The description adds no additional parameter meaning, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: it reports that CMX 3600 EDL import is unavailable, rather than performing an import. It distinguishes itself from sibling tool import_fcp_xml by naming it explicitly as the recommended alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description directly instructs to use import_fcp_xml for unattended timeline interchange, providing a clear alternative. It also explains the context (dialog-safe MCP server, Premiere's EDL API blocking CEP), which tells the agent when this tool is not suitable and when to choose the alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the key behavioral trait that the tool does not open the New Sequence dialog and requires presetPath to avoid it. It does not cover failure modes or permissions, but the provided info adds meaningful context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary function, followed by concise alternative guidance. No redundant or vague wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple creation tool with two fully documented parameters, the description is complete. It explains the core behavior, the prerequisite (presetPath), and provides alternatives. No output schema is needed for this level of complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description adds context about the dialog behavior but does not add new parameter-level details beyond what is in the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a new sequence from a specific .sqpreset file, with the distinctive behavior of bypassing Premiere's New Sequence dialog. It also explicitly differentiates itself from siblings by naming create_sequence_from_clips and duplicate_sequence, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance is provided: prefer create_sequence_from_clips for footage-driven edits, and use duplicate_sequence with clearContents=true for an empty copy of an existing sequence. This gives clear when-to-use and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that caption track deletion is accepted by the schema but returns an explicit unsupported result, which is a key behavioral trait. It doesn't discuss reversibility or side effects, but the operation is straightforward and the main edge case is covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is just two sentences, front-loaded with the main action, and each part earns its place. The second sentence adds a critical caveat without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter delete operation with no output schema, the description covers the essential functionality and the notable exception. It is sufficiently complete for an agent to understand the tool's behavior and constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 important semantic context for the trackType parameter by noting that 'caption' is accepted by the schema but unsupported at runtime, which is valuable beyond the schema's simple enum description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Deletes' with a clear resource 'a video or audio track from the sequence', and explicitly distinguishes from sibling tools like rename_track or lock_track. It also clarifies the unsupported caption track case, adding precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for removing video or audio tracks and explicitly warns against caption track deletion, providing a clear 'when not to use' scenario. However, it does not name alternative tools for other track operations, so it lacks full comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden well. It discloses the keyframe generation algorithm (4 per window, plus boundary keyframes), the base level + window model, and the clip-source-time convention. It stops short of stating whether existing keyframes are overwritten or what side effects occur, but the core behavior is well communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense, purposeful sentences: purpose first, then algorithm, then convention. Every sentence contributes unique information with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with nested parameters, no output schema, and no annotations, the description is thorough. It covers the algorithm, defaults, edge case (empty windows), and time conventions. Missing explicit preconditions or error scenarios, but the overall context is strong enough for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds substantial meaning: it clarifies how baseDb and duckingWindows interact, explains the fallback for clipEndTime, defines defaults for fadeSeconds and clipStartTime, and details the time convention. This goes well beyond the schema's field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('builds') and resource ('ducking curve'), and immediately distinguishes itself from add_audio_keyframes by calling itself a 'high-level wrapper.' This makes the tool's purpose unmistakable and differentiates it from its key sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly frames the usage context: automated ducking versus the manual '8 keyframes per video' pattern from Sprint 3. It also ties the time convention to add_audio_keyframes, helping the agent know when to choose this tool. It lacks explicit exclusions or alternatives beyond the manual pattern, but the guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explicitly states the tool is read-only and runs without changing the project, and lists what it reports. This is transparent for a simple readiness check, though it doesn't detail error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the core purpose ('Read-only readiness check') and 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.
Completeness5/5Given 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 is complete: it states what the tool checks, when to use it, what it reports, and that it has no side effects. No essential information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description appropriately mentions the outputs (version, project, active sequence) and adds no unnecessary parameter info, which is sufficient given the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool verifies the live CEP bridge and Premiere Pro host, using the specific verb 'verify' and identifying the resource. It also distinguishes itself from siblings like 'ping' by being a readiness check that reports version, project, and active sequence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to run this before an editing workflow to confirm the bridge responds, providing clear when-to-use context. It does not mention when not to use it or name alternatives, so it misses the full criteria for a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does explain the key behavioral nuance: clearContents=true produces an EMPTY copy that inherits frame rate/resolution/track layout, while default false is a full copy. It doesn't mention return values or side effects like activation of the new sequence, but the primary behavioral distinction is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose. The second sentence earns its place by explaining the critical parameter and providing a rationale for using it, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description, schema, and sibling context are enough for an agent to select and invoke the tool correctly. It explains what the tool does, when to use clearContents, and how it differs from create_sequence. It lacks only minor details such as whether the copy appears in the same bin or becomes active, but no output schema is promised.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all three parameters. The description adds real value by explaining the clearContents parameter's effect and the practical use case, going beyond the baseline. It doesn't need to elaborate on sequenceId and newName because their schema descriptions are clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with a specific verb+resource: 'Creates a copy of an existing sequence with a new name.' It also distinguishes the tool from create_sequence by noting that create_sequence ignores frame rate, clarifying the niche of clearContents=true.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly prescribes when to use clearContents=true: 'the reliable way to auto-create a correctly-specced blank target' and contrasts with create_sequence. This gives concrete usage guidance and names an alternative tool, satisfying the when-to-use dimension.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It thoroughly discloses the unexpected behavior (always returns empty results due to API limitations), explains the response fields (captionReadSupported:false) that signal this limitation, and clarifies that a zero result does not mean the sequence lacks captions. This is exemplary transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with the core purpose stated first followed by the critical warning. Each sentence provides necessary context, and the imperative alternative is clearly separated. No words are wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description explains the exact return shape (each caption clip as { start, end, text } in seconds), the response fields for the unsupported case, and the operational context (Premiere Pro scripting DOM limitation). This makes the tool's behavior fully predictable and complete for the user.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides full coverage for the sole parameter sequenceId with the description 'Optional sequence ID. Defaults to the active sequence.' The tool description does not add any additional parameter semantic information, 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.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads caption tracks of a sequence and specifies the return format as { start, end, text } in seconds. It starts with a specific verb and resource, and the unique caveat about Premiere Pro's API limitations distinguishes it from sibling tools like create_caption_track or list_sequence_tracks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when not to rely on this tool ('returns trackCount:0 / captions:[] even when the sequence HAS a working caption track') and provides a direct alternative ('parse the source .srt file directly instead'). This gives clear guidance on when to use or avoid the tool relative to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden, and it delivers: it reveals the internal loop mechanism (one ExtendScript pass), the speed advantage, per-clip result arrays, and the exact aggregate status semantics (success only when every clip placed; 'success'|'partial'|'failure' with counts). It also notes one bad clip does not sink the batch, which is important error-handling context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place: it covers purpose, performance, equivalence, parameter context, and return semantics without redundant fluff. The structure is well-paced, with the core action and value proposition stated first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex batch operation with no output schema and no annotations, so the description must compensate—and it does. It fully explains the lifecycle: what the tool does, why it's faster, how per-clip failures are handled, and what the aggregate result means. Complete enough for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value beyond the schema by relating parameters to the use case (e.g., 'Each clip supports per-clip linkAudio and sourceInPoint/sourceOutPoint (Source-monitor in/out)' and clarifies overwrite semantics). It also ties linkAudio to preventing overwrite in rebuild workflows, which complements the schema's detailed comments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool places many clips onto one sequence in a single round-trip, explicitly distinguishing it from the sibling add_to_timeline by noting it is the 'fast path' and 'equivalent to calling add_to_timeline (overwrite) once per clip'. The verb 'Places' plus the resource ('clips onto one sequence') is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a concrete use case ('rebuilding a whole edit, e.g. a Descript/EDL stringout') and explicitly names the alternative (add_to_timeline), explaining when the batch version is preferable (~50x faster, single round-trip). It also hints at when per-clip options like linkAudio matter for overlay/rebuild workflows.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/hetpatel-11/Adobe_Premiere_Pro_MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server