Adobe Premiere Pro MCP
Server Quality Checklist
Latest release: v1.3.0
- Disambiguation1/5
Hundreds of tools have overlapping purposes, such as multiple set_clip_* variants for transform properties, multiple get_* clip info tools, and many unclear 'expanded operation' wrappers with no distinct descriptions. Agents cannot reliably distinguish which tool to use.
Naming Consistency2/5Snake_case is consistent, but verb usage is inconsistent (list vs get, add vs create vs set), and many tools have arbitrary suffixes (set_clip_speed_qe) or are simply the operation name (roll_edit, ping). There is no coherent naming pattern across the set.
Tool Count1/5284 tools is an extreme mismatch for an MCP server, far exceeding the typical well-scoped 3-15 tool range. This bloat makes selection and maintenance impractical.
Completeness2/5Despite the huge count, there are significant dead ends (read_sequence_captions cannot read captions, get_render_queue_status returns no real status, import_edl is unavailable) and missing functionality. The surface is not reliable for full editing workflows.
Average 2.7/5 across 279 of 284 tools scored. Lowest: 1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 54 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.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
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?
The description discloses no behavioral traits. It does not mention whether the operation is read-only or mutates state, what effects it has on the clip, whether it requires specific permissions or conditions, or if it is reversible. With no annotations, the description carries full burden but provides nothing.
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 extremely brief, but it fails to convey any meaningful information. The single sentence is a restatement of the tool name and does not earn its place; it adds noise rather than value. It is under-specified, not 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 lack of annotations, an empty schema, and no output schema, the description is the sole source of information. It is completely inadequate: it does not explain what the tool does, its inputs, its outputs, or when to use it. The tool is essentially undocumented.
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 empty, so there are no parameters to describe. However, the tool name implies parameters are needed (e.g., clip reference, speed factor). The description does not clarify what inputs are expected or how they should be formatted, leaving the agent without guidance.
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 speed qe' is tautological, merely restating the tool name without specifying what the operation does, what resources it acts on, or how it differs from similar tools like 'speed_change' or 'set_clip_speed' (if any). It provides no clear verb or resource description beyond a vague 'expanded operation' and the cryptic suffix 'qe'.
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 context is provided. The description does not indicate when to use this tool instead of alternatives (e.g., 'speed_change' or other clip speed-related functions). There is no mention of prerequisites, workflows, or typical 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 must disclose behavior, but it only states a phrase without details. It does not mention effects on project files, media, undoability, or any side effects. The agent is left 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 technically concise (one sentence), but it is so under-specified that it fails to convey any actionable information. It is not a tautology like 'process' but it's barely an expansion 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?
With no annotations and an empty schema, the description is the sole source of information ROM an agent. It provides no details on inputs, outputs, side effects, or operational context. This is severely incomplete for a tool that likely performs a complex operation in Premiere Pro.
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 (an object with no defined properties), yet the tool is named 'consolidate and transfer' which implies at least some input (e.g., target location, items to consolidate). The schema provides no guidance, and the description doesn't clarify what parameters might be accepted or expected.
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' is essentially a label rather than a description. It names the tool but does not explain what 'consolidate' and 'transfer' mean in this context, nor does it distinguish it from siblings like consolidate_duplicates or export_aaf. The purpose is completely 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?
There is no guidance on when to use this tool versus alternatives. No context about workflows, prerequisites, or scenarios is provided. The description is far too vague to help an agent 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?
With no annotations and a generic description, there is no disclosure of side effects, permissions, or return behavior. The phrase 'expanded operation' adds no transparency about 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 description is concise (one sentence) but lacks structure and substance. It is so brief that it doesn't convey meaningful information, making it ineffective despite its brevity.
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 fails to provide necessary context about what 'effect values' are, the source and target of the copy, or any related workflow. It is incomplete for an operation that likely requires specific parameters and understanding.
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?
Although the schema shows no defined parameters, the description does not clarify that the tool accepts no arguments or explain what fields might be expected. Since the schema is permissive, the description should compensate but fails to provide any parameter semantics.
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: copy effect values' is extremely vague, providing no specific action or context. It does not distinguish from sibling tools like copy_effects_between_clips, 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 indication of prerequisites, typical scenarios, or steps, 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 and no description of side effects, permissions, or state changes, the tool's behavior is completely opaque. The term '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.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (one sentence), but it is too sparse to be useful. It lacks structural elements like separated clauses or lists, and the phrase 'expanded operation' is filler.
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 complex context of Premiere Pro operations and the minimal schema/annotations, the description is woefully incomplete. It provides no information about return values, errors, or how it relates to the broader toolset.
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 an empty object, implying no parameters, but the description doesn't explain whether parameters are expected or how they might affect the operation. No meaning is added beyond the 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: encode project item' is extremely vague. It does not specify what encoding entails (e.g., export, render, compress) nor does it distinguish this tool from similar siblings 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 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 context, 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.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and a vague description, there is no disclosure of side effects, permissions required, or potential impacts on the project. The operation's behavior remains 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 brief, but its brevity is not effective because it omits essential details. It is under-specified to the point of uselessness, rather than being a well-structured 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?
The description is critically incomplete for an export operation. It lacks information about output format, file handling, sequence requirements, or any relevant constraints, making it impossible for an agent to use this tool effectively.
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?
Although the schema has no parameters (100% coverage trivially), the description adds no meaning beyond the schema. It fails to clarify what the operation does or what inputs would be expected, leaving the empty parameter list meaningless.
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: export omf.' merely restates the tool name without explaining what exporting OMF entails, its purpose, or its effect. It is a tautology that provides no actionable 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 gives no indication of when to use this operation versus alternatives like export_sequence or export_aaf. No context is provided regarding prerequisites, typical scenarios, or distinguishing features.
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 and the description provides no behavioral details—no mention of side effects, permissions, return values, or any operational characteristics. The agent is left completely uninformed about what the tool does or expects.
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, which might be seen as concise, but it is under-specified rather than efficiently minimalist. It lacks structured information and front-loads no actionable 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 the complete lack of annotations, output schema, or meaningful parameter details, the description is woefully incomplete. It fails to explain the tool's purpose, usage, or expected behavior, making it essentially unhelpful.
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 tool has zero defined parameters and the description adds no meaning about potential implicit inputs (though the schema allows additionalProperties). With no annotation and no description of what the tool requires, the agent cannot infer how to provide inputs.
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: scene edit detection' merely rephrases the tool name without stating what the tool does. It lacks a specific verb or resource, and 'expanded operation' is vague and does not distinguish it from siblings like 'detect_scene_edits'.
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, context, or exclusions, leaving the agent without any direction on invocation.
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 only restates the name and gives no information about side effects, required permissions, or what happens when the operation executes—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 minimal and concise, but it is under-specified to the point of uselessness. It lacks any structured detail or front-loaded information that would aid decision-making, so brevity doesn't earn credit.
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 permissive but ambiguous input schema, the description provides virtually no context. The tool likely requires knowledge of preset settings and parameters, but none of that is disclosed, making it incomplete for any real-world use.
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 zero explicit parameters but allows arbitrary additional properties, making the schema effectively uninformative. The description adds nothing about what parameters (like preset name or file path) are expected, leaving the agent without any guidance on how to invoke the operation 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 'Premiere Pro expanded operation: create sequence from preset' essentially restates the tool name without providing specific details on what constitutes a preset or how it differs from similar tools like create_sequence or create_sequence_from_clips. It lacks a clear verb-resource-object structure and offers no distinction 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 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 other sequence creation tools, no mention of prerequisites, and no exclusions or alternatives. The description fails to give any context 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 carries the full burden of behavioral disclosure. It does not mention what the operation does (e.g., places a clip from the source monitor into a sequence), any side effects, or constraints. It is wholly 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 a single vague sentence, but this is under-specification rather than conciseness. It does not front-load any useful information and wastes the opportunity to provide essential 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 complexity of a Premiere Pro editing operation, with no annotations, no output schema, and an empty input schema, the description fails entirely to explain the tool's purpose, behavior, or usage. It is completely inadequate for an agent to select or invoke this 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 input schema has zero defined parameters (only an empty object with additionalProperties), so there is nothing to explain. The description adds no parameter-related information and does not compensate for the lack of schema details or clarify how the operation is invoked. While 0 params typically allows a baseline of 4, the description contributes no semantic value whatsoever.
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: insert from source.' is essentially a restatement of the tool name. It provides no specific verb+resource beyond the name itself and fails to distinguish this from sibling tools like 'overwrite_from_source' or 'open_in_source'.
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 gives no context about prerequisites, editing workflows, or scenarios where insertion from source is preferred over other 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 does not disclose side effects such as whether the selection replaces or augments the current selection, or if it affects the playhead or timeline state. The tool's behavior is 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 brief, consisting of a single sentence. While it is not wordy, it omits essential details, so it is not well-structured or sufficiently informative for a tool of this nature.
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 lacks context about the environment (Premiere Pro), the selection scope (which clips), and any constraints or side effects. Compared to sibling tools that have more descriptive names, this one provides minimal operational 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 shows an empty object with arbitrary properties, but no parameters are described. There is no explanation of expected inputs like a clip name or regex pattern, making it impossible to know how to invoke the tool 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 states the tool selects clips by name, which is a clear action and resource. However, the phrase 'expanded operation' is ambiguous and does not clarify the specific context (e.g., timeline vs. project panel) or how selection is applied.
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 other selection tools like select_clips_by_color or select_all_clips. The description lacks any mention of prerequisites, typical use cases, or scenarios where this tool is preferable.
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 fails to mention permissions, effects on existing settings, reversibility, or return values. The description provides 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?
While the description is a single short sentence, it is under-specified rather than concise. It omits essential information and reads as a placeholder, similar to the 'Process' example in the rubric.
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 there are many sibling color-related tools and no annotations or output schema, this description is completely inadequate. The agent cannot determine how to invoke the tool or what to expect.
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, so the baseline is 4, but the description should compensate by explaining how the color value is specified. It does not, leaving the agent without any clue about the required input format. The vague 'set color value' adds nothing beyond the tool 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 color value' is a tautology that merely restates the tool name. It does not specify what color value is being set, on which target (clip, project, sequence), or how it differs from related tools like set_color_label or color_correct.
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 gives no context about intended scenarios, prerequisites, or how it fits into a workflow.
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 states 'expanded operation' with no mention of effects, side effects, required permissions, or output. Nothing beyond the raw action is revealed.
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 it is under-specified rather than concise. It omits essential context and does not earn its brevity because it lacks substantive 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 apparent complexity (setting in/out points on an item in Premiere Pro) and the absence of annotations, output schema, or documented parameters, the description is severely incomplete. It provides no guidance on input, expected behavior, or relation to surrounding tools.
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 an empty object with additionalProperties allowed, yet no properties are documented. The description provides no parameter details, leaving the agent with no idea how to specify the item or in/out values. Schema coverage is technically 100% but only because there are zero defined parameters, so the description fails 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 states a verb ('set') and a resource ('item in out'), implying it sets in/out points on an item, but 'expanded operation' adds no clarity and it does not distinguish itself from siblings like set_sequence_in_out_points or set_source_in_out. The purpose is only vaguely inferred, not clearly articulated.
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 exclusions, and no context about the intended workflow. The single phrase provides zero actionable 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?
With no annotations provided, the description carries full responsibility for disclosing side effects, expectations, or state changes. It merely states the action with no elaboration on consequences, required resources, or whether the operation is reversible. 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.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is not conciseness—it is under-specification. It front-loads the core action but offers no additional value. Every sentence is present, but the description fails to convey essential information, making it ineffective despite its brevity.
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, this description is grossly inadequate. With no annotations, no output schema, and no parameter documentation, the agent has almost no information about how to invoke the tool correctly, what inputs it requires, or what result to expect. The level of completeness is far below a minimum viable description.
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 explicit parameters (only allows arbitrary properties), and the description does not mention or clarify what inputs the operation expects. Even though the schema has zero defined parameters, the tool likely requires context (e.g., a target clip), and the description fails to compensate for this 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 states it sets a poster frame in Premiere Pro, but provides no detail on what a poster frame is, what object it applies to (clip, sequence, etc.), or how the operation behaves. This is only slightly more informative than the tool name, lacking the specificity needed to distinguish it from similar 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 on when to use this tool versus alternative approaches. No mention of prerequisites, contexts, or exclusions. The description provides zero usage direction, 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 carries full burden for behavioral disclosure. It implies a mutation (setting audio settings) but does not state what settings are affected, how they are provided, whether the operation is reversible, or any side effects. The complete lack of detail makes 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 extremely concise (one sentence) but not effectively structured. Brevity does not compensate for missing critical information; the sentence provides no actionable content beyond restating the tool's name. A structured description should front-load the purpose and then detail usage, which this fails to do.
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 be a setting operation with no schema, annotations, or output schema, making it entirely dependent on a thorough description. The description is grossly insufficient: it does not explain what audio settings exist, how to specify them, or what the result is. For a complex operation like this, completeness is far below the minimum viable level.
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 has zero defined parameters (additionalProperties allowed), yet no guidance is given on what properties to pass. The description does not compensate for the schema's emptiness—it offers no hints about expected keys, value formats, or defaults. An agent has no way to know what to provide.
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 a clear verb and resource ('set sequence audio settings') but provides no specificity about what audio settings are modified or how. It reads almost as a restatement of the tool name, with only the vague qualifier 'expanded operation' adding any distinction from other set_* tools. This does not adequately communicate 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 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 like set_sequence_settings or other audio-related tools. No context is provided about prerequisites, conditions, or scenarios where this specialized 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 disclosing behavioral traits. The phrase 'expanded operation' is vague and does not explain side effects, prerequisites, or the nature of the operation. It offers no information about what happens when invoked or any 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 a single sentence but it is under-specified, not concise. It contains the redundant phrase 'expanded operation' which adds no value, and the rest merely restates the tool name. It does not earn its place by providing 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 large number of sibling set_sequence_* tools and the complete lack of annotations, output schema, or parameter details, this description is grossly incomplete. It provides no context to distinguish it from related tools or to understand its operational requirements.
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 allows arbitrary properties but defines none explicitly. The description mentions no parameters, and the 'expanded operation' hint does not clarify what arguments are expected. With zero described parameters and an ambiguous schema, the agent has no guidance on how to call 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 repeats the tool name ('set sequence field type') with the phrase 'expanded operation' which adds no clarity. It states the verb and resource but fails to explain what 'field type' refers to or how it differs from sibling set_sequence_* tools like set_sequence_frame_rate or set_sequence_resolution.
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, under what conditions, or any mention of alternatives. The description provides no context for decision-making, making it impossible for an agent to determine if this is the appropriate 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 offers no insight into side effects, permissions, or any behavioral aspects. Since there are no annotations, 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.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief, but it is front-loaded. However, it lacks enough substance to be considered appropriately sized; it 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 description is too vague to be complete. It does not place the tool in context, nor does it explain any related concepts or expected outcomes.
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?
There are no parameters to document, so the description's lack of parameter information is not penalized heavily. However, the input schema itself is unusual with propertyNames and additionalProperties but no properties, which might confuse. Still, baseline 3 given no parameters.
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 repeats the tool name without explaining what a 'zero point' is or what setting it accomplishes in Premiere Pro. It lacks a clear verb-resource distinction and does not differentiate 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 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, why a user would set a zero point, or any prerequisites. It does not mention alternative 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 or description disclose side effects, permissions, or state changes. The tool's behavior is entirely unspecified.
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 not verbose, but the lack of structure or additional details makes it minimally 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?
With no output schema, no annotations, and a vague description, the tool is far from complete in conveying its purpose, inputs, or outputs.
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 has no defined parameters, and the description does not hint at any expected inputs, leaving the tool's interface completely opaque.
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 'evaluate expression' but does not specify the target or context, leaving ambiguity about what expression is being evaluated and why.
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, nor any conditions or prerequisites.
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 description of behavior, the agent is left without any information about side effects, return values, or operational characteristics. The description neither explains what the tool checks nor whether it performs any action, failing to meet the burden when annotations are absent.
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 extremely brief, but it is under-specification rather than concise efficiency. A single phrase with no substantive content fails to meet the standard of informative brevity; it is more like a placeholder than 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?
Even for a simple tool with no parameters or output schema, the description must clarify the purpose of checking if 'work area is enabled' and what 'enabled' means. It lacks any contextual information, leaving the tool ambiguous and 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 fully describes the empty contract. According to the rubric baseline, a description need not add parameter details for a no-parameter tool. The description adds no value but does not contradict the schema, so a baseline score is awarded.
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: is work area enabled' simply restates the tool name without explaining what it does, what 'work area' refers to, or what result it provides. It is a tautology, lacking a specific verb or resource outcome, and does not distinguish from sibling tools like get_work_area or set_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 context is given for when to use this tool, what it is for, or how it differs from related tools (e.g., get_work_area, set_work_area). There is no mention of prerequisites, conditions, or alternatives, providing zero guidance 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?
No annotations provided and the description reveals no behavioral details—no mention of read-only nature, return format, or any side effects. The description is purely a restatement of 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 extremely short but under-specified rather than concise. It lacks essential details, making it ineffective despite its brevity.
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 is the sole source of information. It is inadequate for an agent to understand the tool's purpose, scope, or expected results.
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?
Though there are zero parameters (baseline 4), the description adds no semantic value—it doesn't clarify what 'clip' entails or what effects are listed. It fails to compensate for the lack of schema detail.
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 it lists clip effects, but it's vague about what 'clip' refers to and doesn't distinguish from list_available_effects. The prefix 'Premiere Pro expanded operation' adds little context. It's a verb+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 Guidelines1/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 like list_available_effects or list_available_transitions. The description gives 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?
With no annotations, the description must disclose behavioral traits. It merely says 'remove all effects' without indicating scope, reversibility, potential side effects, or whether it applies to audio/visual effects. This is critically under-specified.
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 very short, the single sentence is not informative enough to be considered truly concise; it is under-specified. It lacks necessary context, similar to the 'Process' example.
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 there is no input schema, output schema, or annotations, this description is the sole source of information. It fails to provide essential context such as what objects are affected, how effects are removed, or what happens if no selection exists. Completely inadequate for a tool with this 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?
There are zero parameters, so the description doesn't need to explain parameter details. However, since there are no parameters, the description must clarify what the operation targets (e.g., selected clips vs. entire sequence). It does not, leaving ambiguity about what 'all effects' means.
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 the tool 'remove all effects' but is vague about what it applies to (selected clips, sequence, etc.). It does not differentiate from siblings like 'remove_effect' or 'remove_effect_by_name'. 'Expanded operation' is unhelpful and 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 provided on when to use this tool versus alternatives. It doesn't mention prerequisites, typical use cases, or distinctions from similar tools like 'batch_apply_effect' or 'remove_effect'.
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 is no annotation or description of side effects, reversibility, or permission requirements. The tool's behavior is entirely opaque; it does not even confirm whether it is destructive or how it handles missing effects.
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 and to the point, but it lacks any substantive content. It is well-structured as a single sentence but adds no 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?
Given the complexity of the surrounding toolset, this description is grossly incomplete. It does not mention the target (clip, sequence, etc.), the effect type, or any options, making it 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.
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 any parameters or optional arguments. It fails to clarify what inputs the tool accepts or expects.
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 ('remove effect') without specifying what effect, from which element, or how it differs from sibling tools like 'remove_effect_by_name' or 'remove_all_effects'. It provides no additional clarity 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 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 does not mention typical scenarios, prerequisites, or any conditions that would make this the preferred choice.
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 mention whether the operation modifies source or sequence clips, whether it is destructive, or what the outcome of a roll edit 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 a single short sentence, but its brevity is due to under-specification rather than effective conciseness. It provides no substantive information 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?
Without an output schema, annotations, or a substantive description, the tool is severely incomplete. The mechanics, prerequisites, and effects of a roll edit are entirely absent, making correct invocation impossible.
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 defines zero properties but allows arbitrary additional properties via additionalProperties. The description offers no insight into what parameters the tool expects, leaving the agent without any meaningful input guidance.
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: roll edit,' which essentially restates the tool name without explaining what a roll edit is or what the tool accomplishes. It fails to distinguish this 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?
There is no guidance on when to use roll_edit versus alternative editing tools such as trim_clip, slide_edit, or slip_edit. No context or exclusion criteria 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 disclosing behavior. It does not explain what 'expanded operation' means, what side effects occur, or what is selected. The description is essentially 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 extremely short (one sentence), but brevity without substance does not earn credit. It lacks any meaningful information, so 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 large set of sibling selection tools and the absence of annotations or output schema, a complete description is essential. This description provides almost no useful context, 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.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero defined parameters, so the baseline is 4, but the description fails to explain what 'range' refers to or how it is specified. Since there are no parameters, the description should clarify the implicit inputs, but it does not, forcing the agent to guess.
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 the action 'select clips in range' with a verb and resource, but 'range' is ambiguous (time, track, or clip order) and the term 'expanded operation' adds no clarity. It does not differentiate this from sibling selection tools like select_clips_by_name, select_all_clips, or invert_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 on when to use this tool versus alternative selection tools. The description gives no context about its intended use case, making it impossible for an agent to decide between this and other selection options.
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 mention side effects, permission requirements, reversibility, or what happens to the clip's current pan value. The description adds no behavioral insight beyond the implied mutation.
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, this is under-specification rather than conciseness. It fails to provide essential details and does not front-load useful information. A concise description should still include enough to guide usage, which this 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?
Given the complexity of Premiere Pro operations and the large set of sibling tools, this description is woefully incomplete. It lacks behavior, parameters, output type, and usage context. The absence of any detail makes it impossible for an agent to select and invoke this tool correctly.
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 zero properties and allows arbitrary additional properties, so the schema itself provides no parameter documentation. The description does not compensate by explaining what parameters the tool expects (e.g., pan value, clip identifier). Schema coverage is technically 100% because there are no properties, but this is meaningless without parameter 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 'Premiere Pro expanded operation: set clip pan' barely goes beyond the tool name, using the same verb and resource. It does not clarify what 'pan' refers to (e.g., audio pan, camera pan) nor distinguish from sibling tools like set_clip_volume or set_clip_scale. It 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 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 context about prerequisites, typical use cases, or exclusions. The description merely labels the operation 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 or behavioral details are given. The description does not mention side effects, required permissions, or what happens to existing keyframes. The lack of transparency is severe.
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, which is structurally clean, but its brevity results in a lack of substantive content. It is not wordy, but it is underinformative.
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 schema details, no annotations, and a vague one-line description, the tool is not contextually complete. It leaves the user entirely unaware of what the operation entails or requires.
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 empty (no parameters defined), and the description provides no information about what inputs are expected. The description adds no meaning to parameter usage.
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 it sets keyframe interpolation in Premiere Pro, but lacks specifics on what interpolation method, which property, or how it differs from similar operations. It is too vague to clearly convey the tool's 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 provided on when to use this tool versus alternatives. There is no context about prerequisites, typical scenarios, or how it fits into a workflow.
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 only the vague phrase 'expanded operation', the description does not disclose what side effects occur, how the renaming is determined, what gets modified, whether it's reversible, or any permission/capability requirements. This is a mutation tool, and without annotation coverage, the description must carry the full burden—which it utterly fails to do. The user is left blind to 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 extremely short (one sentence), but this is under-specification rather than conciseness. It lacks any structured breakdown (e.g., input expectations, output, examples) and offers no front-loaded useful information beyond the tool's name essentially repeated. It's brief but not efficient—it fails to earn its place with substantive 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?
For a batch operation that mutates multiple clips, with no annotations, no output schema, and an empty input schema, the description is wholly inadequate. It doesn't explain what 'batch' entails (how many clips, selection criteria), what the renaming rule is, how the user provides names, or what happens after execution. An agent cannot correctly invoke or reason about this tool based on this description.
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 (0 parameters, propertyNames type string only, additionalProperties allowed), so there's no structured info about parameters. The description offers zero explanation of how the batch rename is parameterized or scoped (e.g., selection-based, pattern-based, naming convention). Despite the 0-param baseline of 4, the description adds no meaning beyond the vague 'batch rename', so it does not help an agent understand what inputs or state are needed.
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 it's a batch rename operation for clips, which conveys the basic verb-resource relationship. However, it lacks distinction from the sibling tool 'rename_clip' (singular), and the phrase 'expanded operation' is vague. It's clear but not differentiated enough for an agent to know exactly what makes this batch version unique.
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 'rename_clip' or other batch operations. There's no mention of prerequisites (e.g., whether clips must be selected), nor any exclusions or context for when batch renaming is appropriate. Completely lacks usage orientation.
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, and the description discloses zero behavioral traits: no side effects, destructiveness, mutation, or state-change implications. An agent cannot determine whether this operation affects project structure, media files, or requires a specific selection 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 one-sentence description is short but vacuous; it primarily repeats the tool name. Under-specification is not true conciseness—the sentence does not earn its place by adding 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?
With no annotations, no output schema, and an opaque name, the description must carry the full burden of explaining operation semantics, prerequisites, and side effects. It provides none of this, making the tool effectively undocumented.
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, so there is nothing for the description to clarify. The baseline for 0-parameter tools is 4, even though the description adds no explicit detail.
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: detach proxy' merely restates the tool name and adds a generic 'expanded operation' label. It doesn't define what detaching a proxy does—whether it removes proxy links, deletes proxy files, or toggles proxy state—nor does it distinguish itself from related tools like manage_proxies or has_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 given about when to use this tool versus alternatives. It doesn't mention prerequisite conditions (e.g., selected clips with proxies, existing proxy files) or contrast with sibling tools like has_proxy, manage_proxies, or set_offline.
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 description of side effects, permissions, or return behavior, the tool provides zero behavioral transparency. The agent has no idea whether this is a read-only inspection or a mutation, or what operational constraints apply.
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 conciseness is about appropriately sized, front-loaded content that earns its place. This one-liner provides no substantive information, so 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 no output schema, no annotations, and a vague one-line description, the tool is completely inadequate for an agent to understand its purpose, behavior, or invocation context, especially compared to sibling tools with richer descriptions.
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 per the rubric. The schema is empty and the description does not need to explain any parameter semantics; however, the description also fails to add any contextual meaning about the tool's scope, but this dimension is about input parameters only.
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 linked items' merely restates the tool name without any elaboration on what 'linked items' means, what the tool does, or how it differs from siblings like get_clip_links or get_sequence_structure. It is a tautology with no verb+resource specificity.
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 context, prerequisites, or exclusions, 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, so the description carries the full burden for behavioral disclosure. It does not state whether the operation is read-only, what data it returns, or whether it has any side effects on the Premiere Pro 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 under-specified rather than concise. The phrase 'Premiere Pro expanded operation' adds no information and the remainder restates the tool name. The single sentence does not earn its place as it conveys almost nothing.
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 vague description, the tool is completely under-described. The agent has no way to know what 'qe clip info' refers to, what the return value is, or how to use it effectively among the large set 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?
With 0 parameters, the baseline is 4 according to the scoring rules. The schema is trivially covered (100%), and the description adds nothing about parameters, but no parameter explanation is needed given there are none.
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 qe clip info' is essentially a tautology of the tool name. It does not explain what 'qe' means, what clip info is retrieved, or how it differs from sibling tools like get_full_clip_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?
There is no guidance on when to use this tool vs alternatives. The description offers no context about prerequisites, selection requirements, or typical use cases, leaving the agent with no 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 the full burden of behavioral disclosure, and it fails entirely. It does not state what the operation does, whether it requires a prior selection, what occurs on invocation, side effects, or prerequisites. The phrase 'expanded operation' actively obscures rather than reveals 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 this is under-specification, not conciseness. The sentence wastes its limited space on the meaningless prefix 'Premiere Pro expanded operation' rather than delivering any factual content. Like the 'process' calibration example, minimal length without information earns a 2.
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 an operation in a large Premiere Pro tool family with 0 params, 0 annotations, and no output schema, the description is completely inadequate. It should explain what the source operation entails, what object it acts on, and any prerequisites or side effects — none of which are 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 per the baseline rule for param-free tools, a score of 4 applies. There is no parameter burden for the description to carry.
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: open in source' is essentially tautological — the operative content 'open in source' restates the tool name with zero added specificity. The phrase 'expanded operation' is boilerplate filler with no informative value, and it never clarifies what gets opened (a clip? selected media?) or what 'source' refers to (presumably the source monitor, but this is never stated).
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. This is especially problematic given the dense cluster of sibling tools (close_source_monitor, insert_from_source, overwrite_from_source, play_source_monitor, get_source_monitor_info) — the description does nothing to distinguish when opening in source is appropriate versus using those alternatives.
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 whatsoever. It does not mention scope, side effects, prerequisites, expected state changes, or what happens after invocation, 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 short but severely under-specified. The phrase 'Premiere Pro expanded operation' is meaningless filler, and the rest simply repeats the tool name. This is not concise completeness; it is absence of 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?
For a setter tool with no annotations, no output schema, and an empty parameter schema, the description is the sole source of behavioral information. It provides almost none, making the tool non-discoverable and unsafe 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?
There are zero declared parameters, so per the rubric baseline is 4. The schema's loose additionalProperties offers no parameter names or types, and the description does not clarify how the blend mode value should be supplied, but with no explicit params the schema imposes no burden the description must overcome.
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 ('set blend mode') with the filler phrase 'Premiere Pro expanded operation,' providing no actual information about what the tool does, what a blend mode is, or how it differs from related siblings like set_frame_blend or set_time_interpolation.
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 set_blend_mode versus alternatives, when not to use it, or any prerequisites. The sibling list includes many similarly named setter tools, but the description offers no differentiation.
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, but it discloses nothing beyond restating the tool name. It does not state whether the operation affects selected clips, project items, media files, or whether it is reversible or requires specific conditions.
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 brevity here is under-specification rather than conciseness. The single sentence does not earn its place because it provides no useful information beyond the tool name, while lacking structure to convey any actionable guidance.
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 operating in a complex domain like Premiere Pro media offline management, the description is completely inadequate. It has no annotations, no output schema, and no explanation of the operation's scope, effects, or relationship to other tools, leaving the agent without essential 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 input schema is empty, so the parameter semantics burden is minimal. Per the rubric, 0 params receives a baseline of 4, and no additional parameter explanation is needed.
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 tautology: "set offline" restates the tool name without saying what resource or state is affected. It does not distinguish this from siblings like check_offline_media, get_offline_media, or relink_media, and the generic "Premiere Pro expanded operation" prefix adds no specific meaning.
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 workflows, or how it relates to offline media handling in Premiere Pro. A user or agent cannot determine the appropriate context from the description 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 available, the description carries the full burden of disclosing behavior. It merely states 'set sequence resolution' without revealing whether the operation is destructive, requires specific permissions, or has any side effects on 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 extremely brief, but it is under-specified rather than concisely informative. The single sentence fails to earn its place as it provides no useful information beyond 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?
Given the lack of output schema, annotations, and parameter details, the description is grossly inadequate. It does not explain what resolution is set, how it is determined, or any operational context, making it 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, and the schema description coverage is vacuously 100%. The description adds no parameter-specific meaning, but with no parameters to document, the baseline of 4 applies.
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 sequence resolution' is essentially a restatement of the tool name, adding no additional specificity. It does not differentiate from sibling tools like set_sequence_frame_rate or set_sequence_pixel_aspect_ratio 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?
No guidance is provided on when to use this tool versus alternatives. There is no mention of context, prerequisites, or exclusions, leaving the agent without any decision-making 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 and no descriptive detail, the description discloses no behavioral traits, side effects, or state changes that would occur when setting a workspace.
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 and contains no filler, but it also fails to convey any meaningful information, making the single sentence not truly 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 simple structure and no annotations or output schema, the description still fails to provide essential context about what 'set workspace' does or when to call 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 lack of parameter description is acceptable; the baseline of 4 applies because no input schema exists to be explained.
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?
Description is extremely vague: 'Premiere Pro expanded operation: set workspace.' It does not state what setting a workspace actually does, what workspace type is set, or how it behaves, failing to convey 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 provided on when this tool should be used versus any of the many sibling tools, or whether it applies to a specific workspace 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?
No annotations are provided, so the description carries the full transparency burden. It fails to disclose whether the property is written to a file, a project item, or a sequence; whether it can overwrite existing properties; or whether any side effects or permissions are needed. The empty annotation block offers no mitigation.
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 of 9 words, front-loaded with the verb 'attach'. It contains no redundancy or clutter.
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 operation has no documented input meaning, no output schema, no annotations, and the short description gives no context about which Premiere Pro entity can carry custom properties. Given the large sibling collection of metadata tools and effect tools, the description is insufficient to distinguish this operation from alternatives.
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 permissive object with arbitrary property names and values, but the description defines none of them. With 0 parameters and 100% schema coverage, the description should compensate by naming the expected property shape, but it does not reference the schema at all.
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 uses the verb 'attach' and mentions 'custom property' as the resource, but never specifies what the property is, its allowed values, or how the attachment is performed. It reads as a paraphrase of the tool name rather than a functional definition, and is indistinguishable from several sibling metadata 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 like metadata setters/getters, project info tools, or composition tools. Absent any exclusions, prerequisites, or example use patterns the agent must infer the tool's role from its 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 must convey side effects and permissions. It only states 'get bin contents' and gives no indication of read-only behavior, potential side effects, or required permissions.
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 (one sentence) but lacks structural clarity and substantive information. It reads like a placeholder rather than a useful tool 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 does not explain what a bin is, what contents are returned, or how this tool fits into the broader context. With no output schema, the description should clarify return values, but it does not.
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 empty (no parameters), so there is no parameter information to describe. The description implicitly handles this by having no parameters, and the schema itself fully covers the parameter space, making a baseline score 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 'get bin contents' is vague and does not specify what a bin is or what kind of contents are returned. It does not clearly differentiate this tool from many similar getter tools in the sibling list, such as get_project_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?
There is no guidance on when to use this tool or when to prefer alternatives. The description provides no context, exclusions, or examples.
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 explaining side effects, return values, or required permissions. It only states the operation name, providing no 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 very brief (one sentence), but it essentially duplicates the tool name without adding informative content. It is concise in length but fails to earn its place by providing 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?
The description is extremely incomplete. It does not explain what clip markers are, how they are returned, or how this relates to other marker-related operations. Given the lack of annotations and output schema, the description leaves the behavior almost entirely unspecified.
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 no parameters, so the schema covers 100% of parameter information. The description adds nothing beyond the schema, but with no parameters, there is nothing extra to explain, 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.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description restates the tool name ('get clip markers') without adding any clarity about what markers are or in what context they are retrieved. It does not distinguish this tool from similar sibling tools like 'list_markers' or 'get_sequence_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 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 others, nor does it mention any 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?
Annotations are absent. The description 'get color space' suggests a read-only getter, but there is no explicit read-only annotation, no mention of side effects, permissions, or error behavior. The word 'get' implies a non-mutating operation but this is not guaranteed.
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?
Only one short sentence, no repetition, but the phrase is so generic it just restates the tool name with minimal signal. It may form a 'sentence' but not as a good 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?
No output schema, no return values, no behavior under failure, no examples, no context. For an agent to properly invoke this tool, it would need to know the expected return type and possible values for the color space. Also, no flow or no use case.
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 an object with {'propertyNames': {'type': 'string'}, 'additionalProperties': {}} — this effectively says property names must be strings, but values can be anything. It does not name meaningful parameters or supply types, defaults, constraints, or examples. The description and the schema add no real semantic info for 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 uses the verb 'get' and identifies 'color space' as the resource, but the phrase 'expanded operation' is vague. It does not specify what color space is retrieved (e.g., working space, display space, sequence space) or how it relates to Premiere Pro operations. It also does not distinguish itself from sibling tools that inspect 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 the many sibling tools (e.g., get_project_info, get_xmp_metadata, get_item_info, set_color_value). There are no alternatives, 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 behavioral information is given. The description does not indicate whether the operation is read-only, what side effects it might have, or what the output format is. With no annotations, this lack of transparency leaves the agent uncertain 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.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but not front-loaded with useful information. The generic 'Premiere Pro expanded operation' wastes space and adds no value, making it inefficient despite its brevity.
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 incomplete. It lacks details about the returned metadata, output structure, or any relevant context. With no annotations and no output schema, this tool definition is essentially a stub that does not equip an agent to understand its purpose or use 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 is empty, so there are no parameters to explain. The description adds no meaning beyond the schema, but since there are no parameters, it is not a significant deficiency. However, it could have clarified what the tool returns or expected inputs if any existed.
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 project panel metadata') with a generic prefix ('Premiere Pro expanded operation'), adding no distinguishing information. It does not clarify what specific metadata is retrieved or how it differs from other 'get' tools like get_project_info or get_sequence_settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 scenarios where 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.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations supplied, the description must carry the full burden of explaining behavior. It does not disclose whether this operation is read-only, whether it requires a project to be open, what side effects occur, or what the output looks like. The name implies a read operation but this is never verified.
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 minimal—a single fragment-like sentence (26 words), which is under-specification rather than conciseness. No structure is offered to clarify scope, triggers, or output.
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 guidance on when to use this vs siblings like get_unused_media, get_duplicate_media, get_offline_media. No prerequisites (open project), no output contract, no named inputs. Despite no annotations, the description carries all responsibility and provides nothing.
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 parameters) yet oddly has a propertyNames constraint that would permit arbitrary string-keyed properties slant to any value. This is unexplained and could confuse an agent into thinking parameters exist or are optional/free-form.
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 used media report' only tells the agent that this tool generates some kind of used-media report in Premiere Pro. It does not specify what 'used media' includes (e.g., clips referenced in sequences), how the report is delivered, or whether it filters by project/sequence. It is marginally more informative than the name but lacks operational detail, and the 'expanded operation' prefix adds no semantic 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?
No guidance is provided on when to choose this tool over siblings like get_unused_media_report, get_duplicate_media, or get_offline_media. There's no description of invocation context, prerequisites (e.g., open project), 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 carries the full burden of behavioral disclosure. It reveals nothing about side effects, required selections, or what state changes occur. 'Match frame' is ambiguous and could imply navigation, selection, or source-monitor switching, but none of this is explained.
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 phrase, which is under-specification rather than effective conciseness. It does not earn its place because it provides no actionable information. A well-structured description would front-load the core purpose and add necessary 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 lack of annotations, schema detail, and output schema, the description is the only source of information. It provides almost nothing: no indication of what the operation does, when to use it, or what the result will be. This is completely inadequate for an agent to make an informed decision.
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 no parameters (0), which normally warrants a baseline of 4. However, the description does not clarify what the operation acts upon (e.g., the current playhead position, selected clip, or active sequence). Even with zero parameters, the tool must operate on some implicit context, and the description fails to specify it.
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 states 'match frame' which is essentially the tool name. It does not specify what the operation does (e.g., locating the source frame in the source monitor) or how it differs from sibling tools like capture_frame or set_playhead_position. It is a tautology with no added 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. The description does not mention prerequisites, intended contexts, or exclusions. Without any context, an agent cannot determine if match_frame is the right tool for a given task.
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 side effects, prerequisites, or effects on the timeline. The user has no idea what 'razoring' entails (e.g., splitting clips at playhead, affecting all tracks).
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 (one short phrase), but it is so brief that it omits necessary details. It does not waste words, but it also does not provide meaningful content, striking a neutral balance.
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 parameters, no output schema, and a description that merely restates the name, the tool's functionality, usage context, and behavior are entirely unspecified. It is not complete enough for an agent to decide when to invoke it.
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 tool has no parameters, so the empty schema is fully covered. However, the description adds no information about any arguments (though none exist), so it neither helps nor hurts. Baseline score 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 'razor all tracks' essentially repeats the tool name without explaining what 'razor' means in the Premiere Pro context or what specific action is performed. It barely distinguishes from sibling tools that also operate on tracks.
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 other track-related operations (e.g., split_clip, ripple_delete). No context or alternative tools 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It fails to mention that ripple delete is destructive, how it affects timeline gaps, whether it acts on all tracks or only targeted ones, or whether it relies on the current selection.
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 is under-specified rather than concise. 'Premiere Pro expanded operation' is filler and does not meaningfully aid understanding of the tool's function.
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 be a destructive timeline operation with ripple effects, yet the description omits crucial context such as scope, selection requirements, track behavior, and relation to undo. Given the tool's complexity and the rich set of sibling editing operations, this description is gravely insufficient.
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 zero defined parameters but allows arbitrary additionalProperties, creating ambiguity about whether arguments are needed. The description adds no clarification about potential parameters (e.g., track selection, ripple direction). Given the schema's openness, a score of 3 reflects the neutral baseline for no formal parameters, but the description provides no compensating insight.
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' essentially restates the tool name and adds the vague phrase 'expanded operation'. It does not explain what ripple delete does (e.g., deleting selected clips and closing gaps), unlike more informative 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 given on when to use this tool versus alternatives like lift_selection or extract_selection. It does not state that it operates on selected clips or how it differs from other deletion tools, leaving the agent without context for proper 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 full responsibility for disclosing behavior. It only mentions 'expanded operation' without describing what happens, side effects, or requirements (e.g., needing a selected clip). This is severely under-specified.
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 well-structured; it's just a fragment ('expanded operation') that adds no value. It's concise but not informative, and the phrase feels like placeholder text.
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?
Even though the operation has no parameters or output schema, the description should at least specify the target (e.g., the selected clip) or any side effects. It provides none, making it incomplete for safe and 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 schema has zero parameters, so there is nothing to document. The description adds no semantic meaning beyond the empty schema. While baseline for 0 params is 4, the description contributes nothing, so a 3 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: set clip opacity' essentially restates the tool name. It identifies the resource (clip opacity) but 'expanded operation' is vague and doesn't differentiate from sibling property setters like set_clip_volume or set_clip_scale, which are equally self-explanatory.
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 the many alternative property-setting tools. There is no mention of prerequisites such as selecting a clip, or any context that would help an agent decide when to invoke this operation.
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 burden. It does not disclose any behavioral traits such as whether it mutates state, requires a selected clip, or has side effects. The term 'expanded operation' is unhelpful and does not clarify 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 under-specified. It is not concise in a useful way; it omits critical information. The phrase '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?
Given the tool's complexity (likely a mutation on a clip), the description is completely inadequate. No output schema, no annotations, and no parameter details. The agent cannot infer how to invoke this tool correctly or what it does.
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 zero parameters and 100% schema description coverage (vacuously). The description adds no parameter semantics because there are no parameters. Baseline for 0 params is 4, but the description does not explain how the tool knows which clip to affect or what 'position' means, so a 3 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: set clip position' is vague. It identifies the tool as an expanded operation but does not specify what 'clip position' means (e.g., position in timeline, spatial position, or playhead). It does not distinguish from siblings like set_clip_start_time, move_clip, 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 on when to use this tool versus alternatives. The description does not mention prerequisites, context, or exclusions. It is unclear whether this is for spatial position, timeline position, or something else.
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 not provided, so the description carries the full burden. It does not disclose whether the operation is destructive, requires a selected clip, affects only the width/height proportionally, or has any side effects. 'Expanded operation' is vague 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 very short, which is concise, but it lacks informative content. 'Premiere Pro expanded operation' is filler and does not earn its place. The structure is flat and does not front-load meaningful information 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?
The tool operates on a complex application (Premiere Pro) and likely requires a selected clip to apply uniform scaling. With no annotations, no output schema, and no parameter details, the description provides almost no actionable context. It fails to explain what 'uniform scale' means, how it is set, or what the outcome is.
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 tool has zero formal parameters, and schema coverage is 100% (the schema is empty). The description does not explain how the scale value is provided (perhaps via a property or global state), but with no parameters to document, the baseline is 4. Since it adds no parameter-related semantics, a 3 is appropriate: average but not failing.
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 uniform scale.' is minimal. It identifies the tool as setting uniform scale in Premiere Pro, but it lacks a clear verb-resource statement and does not distinguish it from siblings like 'set_scale_width_height' or 'set_scale_to_frame_size'. Purpose is implied rather than explicit.
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 such as 'set_scale_width_height' or 'set_clip_scale'. There is no mention of context, prerequisites, or exclusions, making it ambiguous for an agent.
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 any annotations, the description must disclose behavioral traits (e.g., side effects, output, limitations). It does none of this—'Premiere Pro expanded operation: encode file' reveals nothing about what the tool actually does, what it returns, or any side effects, constituting 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 brief, but brevity here is not conciseness—it is under-specification. The single sentence adds no actionable information, making it unhelpful rather than efficient.
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 parameters, and a complex operation like encoding, the description is grossly incomplete. It fails to explain what file is encoded, what inputs are expected, what the outcome is, or how it relates to other encode/export tools, making it inadequate 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?
Since the tool has zero parameters (schema is empty), the baseline is 4. The description does not need to add parameter information, and indeed it does not, so it meets the baseline 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 states a generic action ('encode file') but provides no specifics about what 'expanded operation' means or how it differs from sibling tools like encode_project_item, export_sequence, or start_batch_encode. The verb-resource combination is clear only at a superficial level, lacking the scope and distinction needed for reliable tool 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 given on when to use this tool versus the many encoding/exporting siblings. There is no mention of prerequisites, expected input, or context in which 'expanded operation' applies, leaving the agent with zero 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 must explain side effects, permissions, or return behavior. It does not mention any of these, leaving the tool's impact 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 its brevity sacrifices clarity. It is not well-structured and reads more like a placeholder than a useful tool 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 tool appears to execute arbitrary scripts, which could have wide-ranging effects, yet the description offers no context about expected inputs, outputs, or side effects. It is 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 input schema has zero parameters, so there is nothing to describe. The description adds no parameter info, but since none exist, this is not a deficit; the baseline for high schema coverage is 3, and here there is no parameter to cover.
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 'execute extendscript' but does not clarify what extendscript is or what it accomplishes. It is too vague to distinguish from other tools in the sibling list.
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 lacks any context about suitable scenarios or prerequisites.
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 disclosure. It does not explain what happens to the selected clips, whether they are deleted, copied, or moved, or any side effects on the timeline.
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 concise. It offers no useful information beyond a vague restatement of the tool name, and the term 'expanded operation' adds no 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 with no annotations and no output schema, the description is grossly inadequate. The agent has no idea what 'extract selection' does, what parameters it might accept (even if none), or what the outcome is. This is a complete gap in contextual information.
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 explain. The baseline of 4 is given for zero-parameter tools, and the description does not need to add parameter meanings.
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' restates the tool name without any detail on what 'extract selection' does. It does not specify the verb's meaning or resource, and it does not distinguish it from similar siblings like lift_selection, remove_selected_clips, or ripple_delete.
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 simply names the operation without explaining the use case, prerequisites, or contrast with related tools like lift_selection or remove_selected_clips.
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 state whether the operation is read-only, what side effects exist, if any permissions are required, or what the return format is. The description provides no behavioral information beyond the bare action verb.
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 (one sentence), it is under-specified rather than concisely effective. It omits essential information about the tool's purpose and behavior, so it does not earn credit for conciseness—it is merely sparse.
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 presumably returns duplicate media, the description is completely inadequate. With no output schema and no annotations, the description must explain what qualifies as duplicate, how duplicates are detected, and what the result looks like. It does none of this, making it minimally viable 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 contains no properties. With no parameters to document, the description does not need to add any parameter semantics. The baseline of 4 is appropriate because there is nothing to explain and no ambiguity introduced.
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 duplicate media' essentially restates the tool name with a prefix. It identifies the action (get) and resource (duplicate media) but adds no detail about what constitutes duplicates or how results are presented, and it fails to distinguish itself from related tools like consolidate_duplicates or check_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?
There is no guidance on when to use this tool versus alternatives such as consolidate_duplicates or check_offline_media. No context, prerequisites, or exclusions are provided, leaving the agent without any 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?
No annotations provided, so the description must carry the full burden of behavioral disclosure. It fails to state what the tool returns (e.g., the extension string), whether it requires an active export or a selected item, or any side effects. It merely says 'expanded operation,' which 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.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but it is under-specified rather than concise. It uses the word 'expanded' which adds no value and might confuse. It is a single sentence but lacks necessary information, so it cannot receive full credit for 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 is part of a large set of Premiere Pro operations, and it lacks annotations, output schema, and parameter details, the description is severely incomplete. It does not explain what 'get export file extension' is used for, what it returns, or how it fits with export-related tools like export_sequence or export_as_fcp_xml. The description does not enable an agent to use the tool effectively.
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 zero parameters, and the schema description coverage is 100% (vacuous). Since no parameters exist, the description does not need to explain parameter semantics. It gets a high score because there is nothing 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 says 'Premiere Pro expanded operation: get export file extension' but the description adds the word 'expanded' which is vague. It does not specify what the tool actually does (e.g., retrieves the file extension for an export operation) or what resource it acts upon. It is almost a restatement of the name without providing concrete functionality.
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 on when to use this tool versus alternatives. There is no mention of typical use cases, prerequisites (e.g., an active export setting), or when not to use it (e.g., for extension of other file types). The description is too sparse to infer 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 provided, the description carries the full burden of behavioral disclosure and fails entirely. It doesn't state whether this is a read-only query, whether side effects occur, whether an open project is assumed, or what triggers the 'offline' state. For an operation that presumably queries or modifies project media linkage state, this is a significant transparency failure.
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?
At eight words, the description is brief, but this reads as under-specification rather than deliberate conciseness. The opening clause 'Premiere Pro expanded operation:' is filler that could be removed with zero information loss, highlighting that the entire description is just 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?
With no output schema and no annotations, the description must explain both behavior and return value, and it does neither. The agent cannot determine if the tool returns a list of offline items, a count, a boolean, or triggers a UI dialog — especially ambiguous given the presence of similarly-purposed siblings like `get_used_media_report` and `check_offline_media`. This is completely inadequate for an agent to select 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?
Per rubric, 0 parameters sets a baseline of 4, since there are no schema semantics for the description to elaborate on. The schema coverage is 100%, so there are no undocumented parameters for the description to compensate for. No deduction needed here.
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' merely restates the tool name with underscores replaced by spaces. The phrase 'expanded operation' is opaque jargon that adds no semantic content, and no clarification is given about what 'offline' means in this context. This borders on a tautology, adding almost nothing beyond the tool's own name.
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, explicit or implied, on when to use this tool versus alternatives. Given the extensive sibling list including `check_offline_media`, `refresh_media`, `relink_media`, and `set_offline`, the absence of any differentiation or usage context is a critical gap. There is no indication of prerequisites, alternatives, 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 carries full burden for behavioral disclosure. The description only labels this as an 'expanded operation' but does not explain what that entails. There is no mention of whether the operation is read-only, requires an open project, returns a list, or has side effects. The agent is left blind to crucial behavioral traits.
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 concise. It uses vague language ('expanded operation') that adds no value and does not front-load useful information. Every word should earn its place, but 'expanded operation' is filler. A clear, detailed single sentence would be better; this lacks 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?
Given the tool's apparent role in getting scratch disk configuration from a Premiere Pro project, and given that the schema provides no meaningful structure (propertyNames with additionalProperties allows arbitrary keys), the description is wholly inadequate. It does not explain what is returned, the format, or how it relates to other scratch disk operations. There is no functional guidance for the agent beyond the name 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 zero parameters, and the schema description coverage is 100% (though propertyNames with additionalProperties: {} allows arbitrary properties, but no specific parameters). Since there are no parameters to document, the description does not need to provide parameter details. The baseline for 0 params is 4, which is reasonable here because the tool's interface is trivially simple.
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 scratch disks.' provides a vague purpose. It names the tool and mentions 'expanded operation' without specifying what the tool retrieves or returns. It does not clearly distinguish from sibling tools like set_project_scratch_disk or get_project_info. The description is essentially a restatement of the tool name with minimal added 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 provides no guidance on when to use this tool versus alternatives. There is no mention of context, prerequisites, or situations where this tool is preferred. It does not indicate that it pairs with set_project_scratch_disk or differentiate from other getters. The tool name alone suggests retrieval, but no usage guidance is offered.
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 doesn't mention whether this is a read-only operation, whether it requires an active Premiere connection, what state assumptions exist (e.g., is a source monitor already open?), or what side effects might occur. The phrase 'expanded operation' is opaque and gives no insight into operation semantics.
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 padded with the generic 'Premiere Pro expanded operation:' prefix, which is misleadingly vacuous. It wastes tokens on a template phrase that could be dropped, leaving just the tool name repeated. True conciseness would be a self-contained 'Gets current source monitor 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 is part of a large sibling set with several source-monitor-related tools (get_source_monitor_position, play_source_monitor, open_in_source, close_source_monitor). Without annotations or an output schema, the description should clarify what 'source monitor info' includes and how it differs from position queries. The description is far too thin to support correct invocation, especially given the complexity of the Premiere Pro environment.
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 schema description coverage is 100% (trivially, as there are no properties to describe). The description adds nothing about parameters, but there is nothing to add. Baseline 4 is appropriate for a no-parameter 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 says 'Premiere Pro expanded operation: get source monitor info.' The verb is 'get' and the resource is 'source monitor info', but 'expanded operation' is vague and doesn't clarify what exactly is retrieved. This phrasing reads like a generic template label ('Premiere Pro expanded operation:') followed by the tool name, providing minimal distinguishing information from siblings 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 Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool. It doesn't mention when it should be preferred over related tools like get_source_monitor_position or close_source_monitor, and there is no context about prerequisites or typical scenarios. The description is purely declarative with 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 carries the full burden of behavioral disclosure. It adds no information about side effects, required state (e.g., a loaded sequence), or what data is returned. While it is not misleading, it provides essentially zero useful 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 its brevity is due to under-specification rather than efficient writing. The phrase 'expanded operation' is vague and adds no value. It offers no structure or key information for the 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?
Given the lack of annotations, output schema, and parameter details, the description should provide substantial context about what 'track info' entails, what state is required, and what the output will be. It fails entirely to do so. Even the tool name is generic.
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 declares zero parameters in the schema, so there is no parameter semantic burden on the description. The schema coverage is 100% trivially, and the description provides all needed information about parameters (none exist).
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 mere restatement of the tool name: 'Premiere Pro expanded operation: get track info.' It uses no specific verb or resource beyond the name itself, and fails to distinguish from siblings like 'get_sequence_structure' or 'get_timeline_summary' that could also return track-related data.
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 as to when this tool should be used over alternatives. The phrase 'expanded operation' is ambiguous and offers no context about prerequisites, timing, 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 bears full responsibility for behavioral disclosure, but it provides none. There is no information on side effects, requirements, return values, or edge cases, leaving the tool's behavior entirely opaque to the agent.
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 concise in a meaningful way; it is under-specified and tautological. The few words it uses add no informative value beyond restating 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?
Given the lack of annotations and output schema, the description needed to provide substantial explanatory context but offers none. The tool appears to be a getter with no parameters, yet the description does nothing to clarify its purpose, expected output, or relationship to the many sibling tools, making it wholly 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 parameters, so the description has no parameter semantics to explain. According to the rubric, 0 params sets a baseline of 4, and there is no contradiction or omission in 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 'Premiere Pro expanded operation: get value at time' is largely a restatement of the tool name and does not specify what resource or action is actually being performed. It fails to convey what 'value' refers to or what 'at time' means in this context, providing no differentiation from any 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?
There is no guidance on when to use this tool versus alternatives. The description merely repeats the tool name without any contextual or alternative-based suggestions, so an agent receives no help in selecting it appropriately.
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 fails to mention whether the tool is read-only, requires an active project or connection, what happens if Premiere is not running, or the nature of the returned data. The phrase 'expanded operation' is obscure and 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 extremely short (one vague sentence). While brevity is valued, this is under-specification rather than concise. The phrase 'expanded operation' is filler and does not earn its place; it contributes nothing toward understanding 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 tool has no parameters, no output schema, no annotations, and a highly complex environment (Premiere Pro), the description is grossly incomplete. It should at minimum state what kind of data is returned (list of workspace names?), whether the tool is safe to call anytime, and any prerequisites like verifying a connection.
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 essentially empty (with only propertyNames constraint). Since there are no parameters to describe, the baseline is 4. The description doesn't need to add parameter semantics, and none are missing.
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 says 'Premiere Pro expanded operation: get workspaces.' This is vague and tautological—it simply restates the tool name with a generic prefix. It doesn't state what the tool does, what information it returns, or how it differs from similar tools like set_workspace or get_encoder_presets.
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. While siblings include set_workspace and other get_* tools, the description provides no context on the appropriate scenario for retrieving workspaces, such as before switching to a specific workspace or for UI customization.
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 effects. It does not mention side effects such as creating sequences in the project, potential overwriting, or required conditions. The phrase 'expanded operation' hints at something additional but is too vague to inform the agent of any consequences.
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 concise. 'Premiere Pro expanded operation: import sequences' adds no meaningful detail and fails to communicate core functionality. It is more similar to the tautological 'Process' example than a truly concise, information-dense 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 imports sequences into a complex application like Premiere Pro, the description is woefully incomplete. There is no mention of the import source, destination, behavior on name conflicts, or any prerequisites. Without annotations or output schema, the description must stand alone, and it provides almost no contextual information.
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, so the description has no obligation to explain parameter usage. The schema allows additional properties, but with no defined parameters, there is nothing for the description to add. The baseline for 0 params is 4, and no deduction is warranted since the schema coverage is 100% (vacuously).
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 'import sequences' as the action, which provides a verb and resource, but the prefix 'expanded operation' adds confusion and does not clearly differentiate this tool from its sibling 'import_sequences_from_project'. There is no specificity about what kind of sequences (e.g., from a project, from a file) or what makes this operation 'expanded'.
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. Given the many sibling import tools (import_sequences_from_project, import_fcp_xml, import_edl, import_folder, import_media), the lack of any context for selection is a critical omission.
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 state whether the operation is reversible, how many undo levels are affected, what happens if there are no more undos, or any side effects. This is a significant gap for a mutation-like 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, which is concise, but it is under-specified to the point of vagueness. It lacks structure or front-loading of key information; 'expanded operation' adds no value and is ambiguous.
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 simple undo operation, the description should at least mention scope (e.g., 'undo last N steps') or behavior (e.g., 'performs consecutive undos until the project is at a certain state'). Without an output schema and with no annotations, this description is profoundly incomplete for even a basic 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 input schema is effectively empty. The description does not need to explain parameters, and the baseline is high because there are no parameters to describe. The description adds nothing about parameters, but that is acceptable given 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 says 'multiple undo' which indicates the tool performs undos, but 'expanded operation' is vague and does not specify the exact behavior (e.g., how many steps, whether it's a single batch operation or repeated). It does not clearly distinguish from the sibling 'undo' tool beyond implying multiple steps.
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 'undo' or 'redo'. No context about typical workflows, prerequisites, or scenarios where multiple undo is appropriate. The description lacks any usage advice or alternatives.
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 reveals nothing about side effects, required permissions, undo behavior, track targeting, or what happens to the source and destination. The agent has no insight into the operation's impact.
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 detailed. It is a single vague phrase that lacks any structure, benefits, examples, or clear action. It does not front-load useful information; it merely 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?
Given the absence of annotations and output schema, the description is the sole source of context. It is grossly insufficient for a mutating operation that clearly affects the timeline. It provides no information about behavior, edge cases, or expected results, making it nearly useless for an agent deciding 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 defined parameters and the schema is effectively empty (only additionalProperties allows arbitrary properties). Since there are no parameters to explain, the baseline is 4. The description does not add or subtract from this, though it also gives no hint of implicit inputs that might be expected.
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: overwrite clip' merely restates the tool name with a generic 'expanded operation' prefix. It fails to specify what overwrite clip does in Premiere Pro, such as replacing a clip on the timeline without affecting other tracks, or distinguishing it from related 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 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 phrase 'expanded operation' is vague and does not explain the intended context, prerequisites, or conditions for invocation. No comparisons to sibling tools or exclusion criteria 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, and the description does not disclose any behavioral details such as connectivity checking, communication with Premiere Pro, or what response to expect. The agent is left completely in the dark about side effects or runtime characteristics.
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 and front-loaded, but it is under-specified rather than concise. The single sentence 'Premiere Pro expanded operation: ping' does not earn its place because it conveys almost no 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?
Even for a tool with no parameters and no output schema, the description must explain what ping does and when to use it. This description provides no context, making it impossible for an agent to select or invoke the tool confidently.
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 explain. Per the rubric, 0 parameters receive a baseline score of 4; 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 says 'Premiere Pro expanded operation: ping' but doesn't define what ping does or what resource it acts on. It's essentially a category label plus the tool name, with no clear verb or outcome.
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 ping versus any of the many sibling tools. There are no exclusions, prerequisites, 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.
- 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 mention whether the operation mutates the project, requires a selected bin, or returns any confirmation. 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.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and is concise in length, but it is severely under-specified. It does not earn its place because it omits vital information about selection context and side effects.
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 name, the description is grossly inadequate. There is no output schema, no annotations, and no explanation of prerequisites or consequences. It cannot guide an agent 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?
The schema has zero parameters, so the description must clarify how the bin is identified (e.g., via current selection). It does not provide any such information, leaving the operation ambiguous. The baseline for zero parameters is 4, but the description fails to add necessary clarification.
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 clearly states the operation is to rename a bin, which is a specific resource in Premiere Pro. However, it lacks specificity about which bin is targeted (e.g., the selected bin) and does not differentiate from similar sibling tools like rename_project_item 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 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 rename_project_item or rename_clip. The description merely states 'Premiere Pro expanded operation: rename bin' without any context on prerequisites or suitable situations.
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 burden. It gives zero behavioral detail: no mention of side effects, prerequisites (e.g., active sequence), what 'expanded operation' means, or what happens to existing selection. The term 'expanded operation' is opaque 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.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one sentence) but it's under-specified rather than concise. 'Expanded operation' is filler that adds no meaning. It fails to earn its place because it doesn't communicate anything useful 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?
Given the tool has no parameters, no output schema, and no annotations, the description is the only source of information. It is completely inadequate for an agent to understand what this tool does, when to use it, or what the result will be. The context signals show 0 params and no schema details, so the description must carry the full load and it fails.
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 provides no parameter information. The description doesn't need to explain parameters, but it also doesn't clarify what the tool operates on (e.g., current selection, active sequence). Baseline 4 for 0 params is appropriate, though the description could have explained the implicit context.
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 selection' is vague. It names the tool and says it's an 'expanded operation' but doesn't specify what setting clip selection entails (e.g., selecting clips in the timeline, setting a selection range, or defining a selection set). It doesn't distinguish from sibling tools like select_clips_by_name, select_all_clips, 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 on when to use this tool versus alternatives. There are many selection-related sibling tools (select_clips_by_name, select_all_clips, select_clips_in_range, etc.) but the description provides no context for when 'set clip selection' is appropriate or how it differs.
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 states the operation without describing side effects, requirements, or expected results. There is no information about what 'frame blend' does or what changes it makes to the project, which is a serious 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?
The description is only one sentence and contains no redundant words, but it is severely under-specified. While conciseness is a virtue, this is not 'appropriately sized' because it fails to provide essential information, making it more a placeholder than 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?
With no annotations, no output schema, and a minimal description, the tool is almost entirely unexplained. Even a simple setter action like this should clarify what frame blend means, how it is applied, and what the expected outcome is. The description is far too sparse 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 input schema is an empty object with zero parameters, so there is nothing for the description to add. The baseline for zero parameters is 4, and the description correctly omits any parameter details since 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 says 'set frame blend' which names a specific operation, but it does not explain what frame blend is or how it differs from similar operations like set_time_interpolation or set_blend_mode. Without context, the purpose is only marginally clearer than the tool 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, when not to, or what alternatives exist. The description provides no contextual hints about typical use cases or prerequisites, making it impossible for an agent to decide 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 discloses no behavioral traits such as mutability, which source it affects, or whether it requires an open source clip. This is fully 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 under-specified rather than appropriately concise. It is a single fragment with no useful structure, similar to the 'Process' example.
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?
Even for a parameterless operation, the description fails to mention what state changes occur, any preconditions, or the relationship to the source monitor context. This is 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?
There are zero parameters and the input schema has no defined fields, so the description is not required to document parameter meanings. The baseline of 4 applies because there is nothing for the description to add for 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: set source in out' essentially restates the tool name and adds the unhelpful filler phrase 'expanded operation'. It does not clearly indicate whether this sets in/out points in the source monitor or defines a specific verb+resource action distinct from siblings like 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 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 such as set_item_in_out, set_sequence_in_out_points, or clear_item_in_out. The description provides no 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?
No annotations are provided, and the description only restates the operation. It does not disclose side effects, whether existing time values are overwritten, what object must be selected, undo behavior, or what 'expanded operation' means.
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 'expanded operation' is vague filler. It is concise rather than helpful, lacking the necessary scoping to earn full credit.
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 many similarly named sibling tools, this one-sentence description is severely under-specified. It does not identify the target object, required input, or resulting behavior, making correct invocation very unlikely.
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 defines no named properties but allows arbitrary properties via additionalProperties; the description does not explain how to pass the start time value, what property key to use, or whether time is in seconds, frames, or timecode. The agent is left guessing despite the tool being a setter.
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 ('set start time') without identifying what entity's start time is being set (clip, sequence, playhead, etc.). 'Premiere Pro expanded operation' adds no semantic differentiation and does not distinguish this from siblings like set_clip_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 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 set_clip_start_time or set_sequence_in_out_points. There are no usage contexts, 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?
With no annotations provided, the description was expected to carry the full burden of disclosing behavioral traits, but it reveals nothing about side effects, whether the operation is blocking, what it affects, or what outcome is returned. It 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 very short, but it is under-specified rather than concise. It provides a single vague sentence without structure, and the phrase 'Premiere Pro expanded operation' adds no meaningful information, making the brevity 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?
Given the complexity of Premiere Pro operations and the presence of many encoding-related sibling tools, this description is wholly inadequate. It lacks any explanation of what batch encoding does, what inputs it expects, what the output will be, or how it fits into a workflow. The absence of annotations and output schema further exaggerates the 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 defined parameters (schema coverage 100%), so the baseline is 4. The description adds no parameter details, but since there are no parameters to describe, this is not a significant gap. The open additionalProperties in the schema is not clarified, but the 0-parameter baseline 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 a verb ('start') and a resource ('batch encode'), but it's essentially a restatement of the tool name with the ambiguous phrase 'expanded operation'. It doesn't clarify what items are being encoded, how batch encoding works, or how it differs from related tools like encode_project_item or encode_file.
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 preferred use cases, prerequisites, or exclusions, leaving the agent without any direction among the many sibling encode/export 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 exist, so the description must fully disclose behavioral traits. It fails to state whether the operation is destructive, what gets unlinking, whether it applies to selected clips only, or any side effects. The description offers zero 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?
One sentence that adds no value is not conciseness; it is under-specification. The phrase 'expanded operation' is filler and does not earn its place. The description fails to convey essential meaning in any structured 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 simplicity of the tool (no params, no output schema), the description still has an obligation to clarify intent. It is completely inadequate, offering no context about which selections are affected, how to invoke it, or what the outcome is. It is virtually indistinguishable from a placeholder.
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 schema_description_coverage is trivially 100%. With no parameters to document, the baseline of 4 applies. The description adds nothing, but no parameters means nothing is missing.
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: 'Premiere Pro expanded operation: unlink selection.' It merely restates the tool name without explaining what 'unlink' means in the Premiere Pro context (e.g., breaking audio-video linkage) or how it differs from sibling tools like 'link_selection' or 'link_audio_video'. No specific action or resource is described.
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 selection requirements, prerequisites, or scenarios where unlinking is appropriate. With numerous sibling tools for selection and linking, this absence leaves 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?
No annotations exist, so the description carries the full burden of behavioral disclosure. It does not mention side effects, safety, required selections, or outcomes. The single sentence offers zero detail about what happens when the tool executes, making it inadequate for an agent.
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, which is concise, but it is under-specified to the point of being uninformative. There is no structure or front-loaded key information. The brevity is not 'appropriate' because it sacrifices necessary 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 the tool's apparent complexity (unnesting is a meaningful operation) and the absence of annotations, output schema, and parameter details, the description is critically incomplete. It fails to convey the operation's effect, inputs, requirements, or results, leaving an agent without sufficient guidance.
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 per the rubric the baseline is 4. The description adds no parameter-level detail, but there is nothing to add since the schema is empty. However, there is no mention of implicit inputs like the current selection, which could be relevant; still, the baseline holds.
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: unnest sequence' essentially restates the tool name with a generic 'expanded operation' prefix. It does not explain what unnesting involves (e.g., extracting nested sequences, flattening) or how it differs from siblings like nest_clips or create_subsequence. The purpose is minimally stated 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 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 context about prerequisites, conditions, or exclusions is provided. The description gives no clue about workflow placement or which scenarios call for unnesting.
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 behaviors, but it only says "expanded operation" — vague and unhelpful. It doesn't state whether this modifies the project permanently, requires a specific context, or has side effects, leaving the agent 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, which is good for conciseness, but it's so underspecified that it lacks substance. It's a single sentence with no waste, yet the term "expanded" adds noise rather than clarity. It's minimal but not effectively structured.
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 zero parameters, the description is the only source of information. It fails entirely to explain what the tool does operationally, what arguments are expected (even if zero parameters, perhaps they come from context), or what the result will be. It is grossly inadequate for a complex tool like Premiere Pro metadata operations.
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 shows 0 parameters with 100% coverage (vacuously), so the baseline for 0 params is 4. The description adds no parameter details but also doesn't need to since there are none. However, the vagueness of "expanded operation" fails to clarify how the tool knows which metadata field to add (likely via context), so minor deduction 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 is a near-tautology: "expanded operation" adds no meaning beyond the name. It states the verb (add) and resource (custom metadata field), but "expanded" is unclear and the tool is distinct from siblings like set_metadata or add_marker without any clarifying scope or difference.
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 on when to use this tool vs set_metadata, attach_custom_property, or add_marker. It doesn't specify whether it applies to project items, clips, or sequences, nor any prerequisites (e.g., a project must be open).
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?
Despite the absence of annotations, the description does not document read/write behavior, side effects, permissions, return values, or reversible operations. Any toggling could change project state, yet each behavior is 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?
One-sentence solution, no redundant words, but 'expansion/full operation' is a wryware word filler; but a map schema was already made available. Minimal.
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?
All behavioral assumptions are not controlled: it does not specify preconditions, return, error, or illustrative examples. The tool is huge, but the description is in no context for any working-environment. Thus the agent is unable to decide precisely when in a given 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?
The input schema describes an object with string names but empty sets; nothing explains each field or what the parameter object controls. Several payload entries must be unspecified with a deep data value. But base schema fully describes map shape.
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?
Description is a near-synonym of the name and only says 'batch enable/disable', without naming a single tool resource or target (media, clips, sequences). It acts not as a verbose but vague resource. It cannot be distinguished from other reservation tool(s).
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 context for use or alternatives is described. No 'when to use' or 'when not to use' is provided; 'batch' is the only lifetime clue.
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. It does not state whether the deletion is permanent, requires confirmation, or affects linked items. The tool's destructive nature is implied by the name 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is concise, though it sacrifices necessary detail. The structure is front-loaded with the core action.
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 in a complex environment with many similar commands (delete_sequence, delete_bin, delete_multiple_project_items, etc.). The description provides no context on scope, side effects, or how to specify the target, making it inadequate for reliable agent 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?
There are zero parameters in the schema, so baseline is 4. However, the description adds no meaning about how the target item is identified (e.g., by ID, name, or selection). The schema allows arbitrary properties but provides no guidance, so score is 3.
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 'delete project item' which is a clear verb+object, but it's essentially a rephrasing of the tool name and does not differentiate from siblings like delete_sequence, delete_bin, or delete_multiple_project_items. It lacks specificity on what constitutes 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 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, selection requirements, or scenarios where other delete tools should be 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?
There are no annotations to provide safety or side-effect information. The description 'Premiere Pro expanded operation: find items by media path' gives zero behavioral detail—no return format, no side effects, no error conditions, no dependencies. It's essentially a restatement of the tool name with the word 'expanded' added, offering no transparency beyond what the agent can infer from 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 a single short sentence with no wasted words. However, it's minimal to the point of being nearly useless—'expanded operation' adds nothing, and there's no structure or front-loaded critical info (like required input or output). Brief but not helpful.
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 zero documented parameters)Skip this. The tool clearly requires some kind of path argument, but neither the schema nor the description explains how to supply it. There are no annotations, no output format, no edge cases, and no differentiation from sibling find_project_item_by_name. The agent gets essentially no actionable guidance.
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 (0 parameters, propertyNames allows arbitrary strings, no defined properties). The tool clearly needs a media path input, but the description provides zero guidance on what parameters to pass or their format/types. With 0 documented params and the description not mentioning any inputs, the agent has no way to correctly invoke this tool.
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 'find items by media path', which clearly indicates the action (find) and the resource (items) plus the filter criterion (media path). However, it adds 'expanded operation' which is vague jargon, and it doesn't differentiate from the sibling find_project_item_by_name or search_project_items, both of which could also find items. Purpose is clear but not distinctive.
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. There are many sibling tools that find or search items (find_project_item_by_name, search_project_items, get_all_project_paths), yet the description gives no context for when this is the right choice. No exclusions or comparisons 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?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only states that the tool gets XMP metadata. It does not disclose return format, side effects, operating scope, failure modes, or whether any Premiere Pro state 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.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but brevity here is actually under-specification rather than conciseness. The phrase "Premiere Pro expanded operation" is filler and does not earn its place, while the substantive content merely repeats 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 Premiere Pro metadata tool with no annotations and no output schema, this description is incomplete. It fails to indicate what object or selection the XMP metadata applies to, what the output looks like, and how it differs from get_metadata or set_xmp_metadata.
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 100% schema coverage, so the baseline is 4. The description adds no parameter detail, but none is needed because 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 essentially restates the tool name: "get xmp metadata" adds no new scope or target information beyond the name itself. "Premiere Pro expanded operation" is boilerplate and does not clarify whether this reads XMP from clips, project items, sequences, or something else, nor does it distinguish the tool from siblings like get_metadata or set_xmp_metadata.
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 get_metadata or the many other inspection tools. No prerequisites, selection requirements, or context 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?
The description does not disclose any behavioral aspects such as side effects, required permissions, or whether it modifies the clip's in-point or other properties.
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, which is concise, but it omits essential information, making it 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?
Given the lack of schema details and annotations, the description is far from complete; it does not mention input requirements, output, or any contextual information.
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, and the description does not explain what parameters are needed, such as clip identifier and start time value.
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 target (clip start time), distinguishing it from other set operations. However, it lacks specificity about the context or which clip.
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, or any prerequisites.
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 behavioral burden. It discloses nothing about whether this mutates project state, overwrites existing metadata, requires a selected project item, only affects the project panel view, or returns any confirmation. The single declarative sentence provides zero beyond the operation 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 brief but not concise in a useful way: it spends words on 'Premiere Pro expanded operation' without providing actionable content. The meaningful text is just a restatement of the tool name. This is under-specification rather than efficient communication.
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 an opaque free-form input, this description is completely inadequate. It does not explain the effect, the expected input structure, prerequisites, or whether the operation is reversible. An agent cannot reliably decide to call this tool or construct a correct payload from this description alone.
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 describes an arbitrary object with string property names and no defined properties, so schema coverage is effectively 100% but semantically thin. The description adds no information about what keys are expected, what value types are allowed, or how the metadata object maps to Premiere Pro's project panel. Because the schema itself is the only source of parameter structure, the description neither harms nor helps.
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 of the tool name: 'set project panel metadata' adds no detail beyond the name itself. The phrase 'Premiere Pro expanded operation' is vague filler and does not specify what metadata, on which items, or in what form. It does not differentiate this tool from siblings like set_metadata, set_xmp_metadata, or add_custom_metadata_field.
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 related tools such as set_metadata, get_project_panel_metadata, set_xmp_metadata, or attach_custom_property. The description does not state prerequisites, selection requirements, or scenarios where this operation is appropriate. It gives an agent no context for choosing this tool over alternatives.
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 reveals nothing about side effects—what kind of tracks are added (video/audio), to which sequence, whether existing tracks are affected, or any undo/restoration behavior. For a mutation operation in Premiere Pro, this is a total absence 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 technically short (one sentence), but brevity is not earned conciseness. The phrase 'Premiere Pro expanded operation' is filler that adds no information, and the remaining 'add tracks' merely repeats the tool name. Every word fails to earn its place by contributing new 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?
Adding tracks to a Premiere sequence is a complex operation involving track type, quantity, and placement, yet the description provides no details. With no annotations, no output schema, and zero substantive prose, the tool is wholly inadequate for an agent to understand its behavior or results.
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 100% vacuous schema coverage, so per the rubric the baseline is 4. With no parameters to describe, the schema needs no additional semantic help from the description; there is genuinely nothing to clarify here.
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: add tracks' is essentially a restatement of the tool name with a vague 'expanded operation' qualifier. It states a verb+resource but provides zero specificity about what adding tracks entails, nor does it distinguish this plural form from the sibling add_track, add_to_timeline, or add_adjustment_layer 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. With siblings like add_track (singular), add_to_timeline, and add_adjustment_layer, the description offers no context on sequencing prerequisites, target selection, or exclusions. The reader cannot determine 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 carries full burden. It only says 'expanded operation' and 'delete bin' without disclosing dangers like permanent deletion, cascade effects on clips/sequences, or confirmation requirements. Lack of safety warnings is a serious 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?
The description is extremely short (one phrase) and provides no structured information. It is under-specified, not concise; it omits critical context and reads like 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 deletion operation and absence of annotations/output schema, the description is inadequate. It does not explain return values, error handling, or behavior on non-empty bins. The tool name 'delete_bin' and the note 'Premiere Pro expanded operation' add nothing actionable.
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 the schema provides no parameter info. The description adds no param semantics, but with zero parameters the baseline is 4. However, it offers no explanation of how the tool identifies which bin to delete (e.g., requires a selected bin), which could be considered lacking.
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 says 'delete bin' but gives no detail on scope (deletes from disk or project?), effect on contained items, or whether it is a permanent action. It merely restates the tool name with action verb, offering minimal differentiation from siblings like 'delete_project_item' or 'delete_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 on when to use this tool versus alternatives like 'delete_project_item' or 'move_items_to_bin'. The description implies it deletes a bin, but does not specify prerequisites, effects on contents, or whether it is reversible.
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 responsibility for behavioral disclosure, but it only says 'get,' implying a read operation without specifying return values, side effects, required state, or failure modes. This is insufficient for an agent to predict 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 short, but it is under-specified rather than concise. The phrase 'Premiere Pro expanded operation' is filler that adds no value, and the remaining words merely echo 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 no annotations, no output schema, no parameter documentation, and no behavioral explanation, the description is completely inadequate. An agent cannot determine what a mogrt component is, how the result is returned, or what conditions must be met to successfully 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 declared parameters and 100% schema coverage, so there are no parameter semantics for the description to clarify. Per the rubric, a zero-parameter tool receives the baseline score of 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 mogrt component' essentially restates the tool name and adds only the vague modifier 'expanded operation.' It does not define what a mogrt component is, what 'get' returns, or how it differs from sibling tools like import_mogrt or import_mogrt_from_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?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. It is a bare statement with no usage context, earning the 'no guidance' score.
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 carry the full burden of behavioral disclosure, but it offers none. It does not indicate read-only nature, side effects, required connection, or return format, making the tool 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 extremely brief, but brevity without substance is not conciseness; it is under-specification. The single sentence lacks structure and essential content, failing to inform 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 no output schema, no annotations, and a vague description, the tool cannot be correctly invoked or interpreted. It is wholly inadequate for understanding what the state refers to or what the tool returns, making it nearly 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?
Since the tool has zero parameters, the description is not required to explain any. The input schema is an empty object, and the description adds nothing, but the baseline for 0 params is 4, so this score reflects that the description adequately covers the (nonexistent) parameter space.
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 premiere state') with a vague 'expanded operation' prefix, offering no specific action or resource detail. It does not differentiate from numerous sibling get_* tools such as get_project_info or get_playhead_position, making its 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. The description lacks any context about suitable scenarios, prerequisites, or exclusions, leaving the agent without direction among the many similar 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 says 'get target tracks' and gives no information about return values, side effects, read-only nature, or any other behavioral traits, providing no 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.
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 phrase 'Premiere Pro expanded operation' is filler, and the rest is just the tool name. It does not earn its place by adding meaningful 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 lack of an output schema and annotations, the description should explain what the tool returns or accomplishes. It does neither, making it completely inadequate for an agent to understand or correctly use 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 is an empty object. Per the baseline for 0 params, a score of 4 is appropriate; 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: get target tracks' essentially restates the tool name with a generic prefix. It fails to specify what target tracks are or how this differs from sibling tools like get_track_info or list_sequence_tracks, making it a tautology rather than 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 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 offers no context for selection, no exclusions, and no conditions under which this tool is preferred over other track-related getters.
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, but it only says 'expanded operation' without explaining side effects, return contents, or operational constraints. This is completely opaque for a tool that could summarize the timeline.
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 meaningfully concise—'Premiere Pro expanded operation' is filler that wastes space. The actual content merely restates the tool name, providing no additional structure or 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 the vast sibling toolset, this description is severely under-specified. There is no output schema, no behavioral details, and no differentiation from many other timeline-related tools, leaving the agent unable to correctly invoke or interpret results.
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 already covers everything. The description adds no parameter information, but none is needed; 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 repeats the tool name ('get timeline summary') with a vague qualifier ('Premiere Pro expanded operation') that adds no concrete meaning. It fails to explain what a timeline summary contains or how it differs from similar tools like get_sequence_structure or get_timeline_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?
No guidance is provided on when to use this tool versus alternatives. The description offers no context, prerequisites, or exclusions, leaving the agent to guess based solely on the name.
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 disclosing behavior. It offers no information about side effects, whether the operation is destructive, what 'overwrite' entails, or what happens to the source and timeline. The vague phrase 'expanded operation' adds no useful 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 description is extremely short, this is under-specification rather than effective conciseness. Similar to the 'Process' calibration example, the description fails to convey any meaningful information and wastes the opportunity to clarify the operation.
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, no output schema, and no parameters, the description must fully explain the operation's effect and context. It fails to do so, leaving the agent without essential information about what 'overwrite from source' does, what inputs it implicitly uses, 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 tool has 0 parameters, and the rubric sets a baseline of 4 for this case. There are no parameter descriptions needed, and the schema trivially covers all parameters. The description adds no parameter info, but it's 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 'Premiere Pro expanded operation: overwrite from source' essentially restates the tool name without explaining what 'overwrite from source' means. It lacks a specific verb+resource structure and does not distinguish itself from siblings like 'insert_from_source' or 'overwrite_clip', leaving the 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?
No guidance is provided on when to use this tool versus alternatives such as 'insert_from_source' or 'set_source_in_out'. The description gives no context on prerequisites, use cases, or exclusions, so the agent is left 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, so the description carries the full burden of behavioral disclosure. It does not state whether the selection replaces the current selection, whether it operates on the timeline or project panel, or whether it is safe/read-only versus a mutation of selection 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 brief but not concise in a useful way; 'Premiere Pro expanded operation' is filler and 'select item' simply repeats the tool name. It is under-specified rather than economically 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?
With no output schema, no annotations, zero parameters, and a large sibling set of selection tools, the description provides almost no information needed for correct invocation. The agent cannot know what object will be selected or what observable effect the tool will have.
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 there are no parameter semantics for the description to add. Baseline for a zero-parameter tool 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 says 'Premiere Pro expanded operation: select item,' which restates the tool name without adding meaningful scope. It does not specify what kind of item is selected, where selection occurs, or how this differs from selection siblings like select_clips_by_name, set_clip_selection, or 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?
There is no guidance about when to use this tool versus the many other selection-related tools. No context is given for selecting project items, clips, tracks, or other object types.
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 behavioral details. It only states the action without explaining what happens to existing target states, whether it's a toggle, or any other outcomes.
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 with no fluff. It is appropriately sized and front-loaded, though its brevity stems from lack of content rather than efficient elaboration.
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 or output schema, the description should explain the tool's purpose, prerequisites, and effects. It fails to provide any context, making it insufficient for an agent to understand when and why 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?
There are zero parameters, so the baseline is 4. The description adds no param-specific info, but none is needed. It does not detract from the inherent clarity of an empty parameter list.
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 without clarifying what 'targeted' means in this context. It does distinguish from the sibling 'set_target_track' (which targets one track) but provides no additional specificity.
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 like 'set_target_track' or 'get_target_tracks'. The description lacks any contextual or conditional advice.
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, but it reveals nothing: no units, no mutation effect, no selection requirements, and no semantics for how scale is applied. 'Expanded operation' is ambiguous 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 one sentence, but it is under-specification rather than concise: the first half is filler and the second merely restates the tool name. It has no information density.
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 no-parameter mutating tool with no annotations and no output schema, this description is far too sparse. It fails to explain what 'clip scale' means, which clip is affected, or how it interacts with the many scale-related 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 zero parameters, so the schema coverage is trivially complete and there is no parameter meaning the description must add. The baseline of 4 applies because no parameter documentation burden exists.
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 exactly: 'set clip scale.' 'Premiere Pro expanded operation' is generic filler and does not differentiate this tool from siblings like set_scale_to_frame_size, set_uniform_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 about when to use this tool versus alternatives. It also does not mention prerequisites such as having a clip selected or any exclusion cases.
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 is the sole source of behavioral information. It fails to disclose any side effects, requirements, or consequences of setting an override frame rate. It provides no detail about what changes occur or what the user should expect.
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 concise—a single sentence—with no redundant text other than the generic 'Premiere Pro expanded operation' prefix. While it is not front-loaded with useful detail, it does not waste words.
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 any parameter complexity, the description must carry the full burden of explaining what the tool does. It fails to provide any meaningful context about the 'override frame rate' concept, its effects, or its relationship to other frame-rate settings, leaving the agent poorly informed.
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. According to the rubric, a 0-parameter tool gets a baseline of 4 since there are no parameter meanings to convey. The description does not need to add 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 provides a verb ('set') and resource ('override frame rate'), but it essentially restates the tool name without explaining what 'override frame rate' means in Premiere Pro context. It does not differentiate from closely related tools like set_sequence_frame_rate or set_clip_speed, 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 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 prerequisites, typical scenarios, or when not to use it. The description offers no situational context 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?
The description gives no indication of side effects, reversibility, or permissions required. Since no annotations are present, the tool's behavioral impact (e.g., modifying the sequence's metadata) is not disclosed.
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, consisting of a single sentence with no superfluous words. However, it is too sparse to be considered well-structured for a tool definition, omitting essential operational 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?
The description lacks context about the sequence scope, valid frame rate formats, or any related constraints. Given the tool's complexity and the existence of many sibling tools, this definition is 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 empty (no properties defined), and the description does not enumerate parameters. Although the tool name implies a frame rate value, its type, range, and requiredness are completely undocumented.
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: setting the frame rate of a sequence. However, it is vague about which sequence is targeted (e.g., active sequence) and lacks detail on the acceptable frame rate values.
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 mention when to use this tool versus alternatives, nor does it clarify any prerequisites or contextual conditions (e.g., sequence must be open).
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 only restates the tool name and does not disclose side effects (e.g., mutating keyframe interpolation state, requiring an active sequence, timeline refresh, undo behavior). Since this is a 'set' operation, the agent cannot infer destructive risks, permission requirements, or rate limits.
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, so it is very concise, but its content repeats the name of the tool and adds no independent meaning. It does not provide context, input/output details, or examples. It obtains one point for being brief but loses value for being essentially empty.
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 0 parameters and no output schema; however, it is one of a very long list of sibling tools (set_time_position, set_sequence_settings, set_frame_blend, etc.) that share the 'set_*' prefix. The description gives no basis for an agent to understand in which workflow to choose this tool, because it does not mention timeline, selected clips, keyframes, or interpolation type. There may be hidden prerequisites (for example, active sequence), and the missing output schema means no return value is described.
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?
The input schema declares zero parameters. However, it is malformed (using propertyNames as a schema keyword), although with param count 0 the description is not required to document parameters. Thus the baseline of 4 applies plus full marks for no params. Yet the malformed property name does not affect execution. The schema also strangely allows additional properties with an empty-object schema. So with 0 params, high score is warranted. But note the malformed schema is not the description's responsibility. The description carries no semantic burden. Baseline=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: set time interpolation' is tautological and vague. It restates the tool name without explaining what 'set time interpolation' actually does (e.g., set keyframe interpolation mode between keyframes). It does not specify the resource or behavior beyond the name. Sibling tools like set_keyframe_interpolation, set_clip_speed, and set_frame_blend exist in the same domain, but there is no distinguishing information. A specific verb+resource is present, but no semantic 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 instead of alternatives. There are no preconditions, no scenario descriptions, no examples. The phrase 'expanded operation' is meaningless context. Sibling tools include set_sequence_settings, set_clip_speed, set_keyframe_interpolation, etc., but there is no information about selection or exclusion.
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 whether this modifies project settings, is a toggle, affects existing media, requires a restart, or returns any feedback. The 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 very short, but this is under-specification rather than conciseness. 'Premiere Pro expanded operation' is filler, and the rest merely restates the tool name, so the sentence does not earn its place by adding useful 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?
This is a state-changing tool with no annotations and no output schema to clarify behavior, yet the description provides no information about scope, effects, verification, or side effects. Given the large sibling toolset and the need to disambiguate similar media/ingest operations, this is 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 tool has zero parameters per context signals, so there is no parameter semantics to document. The description does not add anything about parameters, but that is acceptable 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 simply restates the tool name ('set transcode on ingest') with the generic preface 'Premiere Pro expanded operation.' It offers no detail about what setting is changed or how, and it does not differentiate this tool from related sibling tools like manage_proxies or set_scratch_disk_path. 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 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 (e.g., open project, ingest settings enabled), and no exclusions. The phrase 'expanded operation' implies some advanced/specialized use but does not explain 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?
There are no annotations and the description offers no behavioral disclosure: it does not state side effects, whether it is destructive, what it operates on, or how it affects the timeline. 'Expanded operation' is meaningless without further detail.
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 concise at one sentence and is not bloated. However, 'expanded operation' is vague filler that adds little meaning, preventing a 5.
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 usage context, the description is far too thin. It fails to explain what a slip edit does, what is required to invoke it, or how it differs from similar trim tools like roll_edit and slide_edit.
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 is not required to explain parameter semantics, though it does not clarify implicit operating context such as selected clips or playhead position.
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 says 'Premiere Pro expanded operation: slip edit,' which names the operation but does not explain what a slip edit does. It does not distinguish itself from the sibling tools roll_edit and slide_edit, which are closely related trim 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?
No guidance is provided about when to use this tool, what selection or context is required, or which alternatives (roll_edit, slide_edit, trim_clip) might be more appropriate. The description contains zero 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 provided, the description carries the full burden of behavioral disclosure and fails entirely. It states no side effects, prerequisites, state changes, or output characteristics. An agent has no idea whether this writes a file, modifies the timeline, reads from the playhead, or requires an active project.
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 this is under-specification rather than conciseness. Like the 'Process' calibration example, the terseness is achieved by stripping all informative content rather than editing 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?
Despite the surface simplicity (0 params, no output schema), essential context is missing: what happens to the captured frame, whether it requires an active sequence, and what events or state trigger the capture. Even a simple operation deserves one sentence of behavioral context in a toolset this large.
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 with 100% schema coverage, so the baseline of 4 applies per the rubric's '0 params = baseline 4' rule. There is no parameter documentation burden, and the description's lack of parameter context 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?
"Premiere Pro expanded operation: capture frame." merely restates the tool name with a generic wrapper; "expanded operation" is meaningless flavor text that adds no semantic clarity. It doesn't define what capturing a frame entails or differentiate from sibling tools like export_frame or freeze_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?
The description provides no guidance on when to use this tool versus alternatives. Given the enormous sibling list including conceptually similar tools like export_frame and set_poster_frame, the complete absence of when-to-use or alternative-avoidance context 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 must disclose behavioral traits directly. It is nearly a tautology—'expanded operation' hints at a broad or enhanced behavior, but nothing explains what the operation does to the project, whether it modifies the timeline, whether it is destructive, or what side effects occur. The term 'expanded' is unclear and could even suggest the operation is a wrapper/kicker for other actions.
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 (one phrase), which is structurally minimal, but it is under-specified rather than concisely focused. The phrase 'expanded operation' adds noise rather than value—it is vague and could be applied to any tool. A truly concise description would state the exact action and result in a single sentence without filler.
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 zero parameters and no output schema, the description is the only channel to convey context. This description is inadequate: it fails to define what 'freeze frame' means, what the operation does to the timeline or project, whether it requires a selected clip or playhead position, and how it relates to sibling tools like 'match_frame' or 'capture_frame'. The description is a placeholder rather than a specification.
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 inherently complete with respect to parameter semantics. The baseline for zero parameters is 4, and since the schema has no property definitions, the description doesn't need to compensate. No parameter information is missing.
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: freeze frame.' states the resource (Premiere Pro) and a verb phrase ('freeze frame'), but the action is vague—'freeze frame' could mean capturing a still, creating a freeze frame clip, or setting a poster frame. The name 'freeze_frame' is similarly generic, and the description does not distinguish this from sibling tools like 'capture_frame', 'export_frame', or 'match_frame'.
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 compared to alternatives. The description does not mention context, prerequisites, or exclusions. With dozens of sibling tools in the same domain (e.g., 'capture_frame', 'match_frame', 'set_poster_frame'), this is a critical miss.
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 no side effects, return shape, active-seqeunce dependency, or error behavior, leaving the agent with only the phrase 'get clip at playhead.'
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 only meaningful content is a restatement of the tool name. The 'Premiere Pro expanded operation:' prefix is filler that does not earn its place, and no additional useful structure or detail is provided.
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 only a vague one-line description, the tool is not fully specified. An agent cannot tell what the operation returns, which sequence it operates on, or how it behaves when no clip is at the playhead.
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 documented parameters and 100% schema description coverage, so there is little for the description to add. This matches the baseline for a no-parameter tool; no parameter semantics are needed beyond what the schema already conveys.
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 clip at playhead.' The 'Premiere Pro expanded operation' prefix is boilerplate and adds no semantic clarity. It does not explain what 'clip' means in this context, whether it applies to the active sequence, or how it differs from get_clip_at_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 usage guidance is provided. There is no mention of when to prefer this tool over siblings like get_clip_at_position, get_selected_clips, or get_playhead_position, and no exclusions or prerequisites are stated.
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 only repeats the operation name and gives no information about return values, side effects, performance characteristics, or what 'white luminance' represents in Premiere Pro.
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 short, this is under-specification rather than effective conciseness. The single sentence adds no informational value beyond the tool name, so it does not 'earn its place' as a meaningful 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 needed to explain what value is returned and in what form. It does neither. Even for a simple getter, the description is incomplete because the semantics of 'graphics white luminance' and the expected result are not clarified.
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 documentation burden for the description to carry. The baseline for a no-parameter tool is 4, and the description does not mislead about inputs.
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 restated with a generic 'Premiere Pro expanded operation' prefix. It identifies the resource ('graphics white luminance') and a getter action, but provides no actual functional specificity or distinction from the paired set_graphics_white_luminance sibling beyond the verb in 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?
There is no guidance about when to use this tool, what prerequisites exist, or how it relates to set_graphics_white_luminance and other graphics-related operations. The description gives no context for selecting it over alternatives.
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, but it reveals nothing: no mention of side effects, permissions, read-only status, or return format. 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and easy to scan, so it is concise in length. However, it is under-specified—all it does is restate the tool name and add a meaningless qualifier. Brevity without substance is closer to a deficiency than an ideal 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 lack of annotations, no output schema, and a vague description, the tool is completely under-documented. An agent cannot infer what this tool does, when to call it, or what to expect in return. Competing tools like get_bin_contents offer clearer semantics, so this description is 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 parameters, so the description cannot add parameter meaning. Per the rubric, the baseline is 4 for no parameters, and the description does not need to compensate for any schema 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: get insertion bin.' is vague. It identifies a verb ('get') and a resource ('insertion bin'), but the phrase 'expanded operation' is an internal taxonomy label that adds no semantic value. It does not explain what an 'insertion bin' is or what the tool returns, and among sibling tools like get_bin_contents and get_project_item_info, this fails to distinguish 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?
There is no guidance on when to use this tool versus alternatives such as get_bin_contents or get_project_item_info. The description merely restates the operation name with no context about workflows, 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 carries the full burden. It only restates the operation name without disclosing return behavior, side effects, or safety profile (e.g., read-only assumption). The phrase 'expanded operation' hints at advanced functionality but fails to explain what that entails.
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 it is under-specified rather than efficiently informative. It lacks any elaboration that would justify its brevity, so it fails to earn its place beyond restating 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?
Given the empty schema and no output schema, the description is the only source of behavioral context. It fails to specify what 'position' means, what the return value is, or how this tool relates to similar tools like get_source_monitor_info. For such a simple tool, minimal information is expected, but this is insufficient.
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 tool has zero parameters, so the schema fully covers the input side. However, the description adds no context about what the returned position represents or how it should be interpreted, which is essential for a tool with no parameters. Baseline for 0 params is 4, but the lack of any added meaning brings it down.
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 'get source monitor position' but 'position' is ambiguous (playhead? cursor? selection?). It does not distinguish itself from the sibling tool get_source_monitor_info, which likely provides similar or broader information including position. The purpose is only vaguely 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 on when to use this tool versus alternatives. It does not explain when to prefer this over get_source_monitor_info or other source-monitor-related tools, nor does it describe 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?
No annotations are provided for this toolaineer's write/read/destructive hints, so the description carries the full burden of behavioral disclosure. The description fails to state what the tool returns, whether it requires an active project, whether it's a fast/cheap check, or what side effects might occur. It adds no behavioral context whatsoever 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 extremely brief ('Premiere Pro expanded operation: has proxy.'), which is concise but under-specified. This is not a case of efficient writing; it's a case of insufficient content. The word 'expanded operation' is vague filler that adds no 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?
Despite the tool's apparent simplicity, the description omits critical details: what it checks, what the return value means, whether it requires an active project, and how it relates to proxy workflows in Premiere Pro. With no annotations and no schema description beyond an open-ended propertyNames object, this is severely incomplete even for a simple predicate-style 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 parametersais the schema allows arbitrary properties, the description doesn't need to explain parameters. With an open-ended schema (any string keys allowed), some guidance on expected property names would be helpful, but the zero-parameter actual usage keeps this acceptable.
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: has proxy' is nearly a tautology of the tool name. It does not specify what action is performed, what resource is checked, or what 'has proxy' means in context (e.g., whether it checks if the current project has proxy media enabled). It fails to distinguish this from sibling tools like 'check_offline_media' or 'get_project_info'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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's no mention of prerequisites (e.g., requires an open project), typical scenarios, or exclusions. The agent gets no help choosing between this and the many other inspection tools in the sibling list.
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 reveals nothing beyond what the name implies, such as side effects, destructive potential, or what 'expanded' means in practice. 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler words, making it concise. However, it is so terse that it omits necessary context, clinging to the minimal 'expanded operation' phrase without explanation. It is appropriately short but lacks 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?
Given the absence of annotations, output schema, and rich parameter info, the description should offer more behavioral and usage context. It does not clarify what 'expanded' entails, prerequisites, side effects, or expected outcomes, leaving it inadequate for an agent to confidently 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 schema defines zero parameters, so there is nothing for the description to elaborate on. Per the baseline for zero parameters, the description does not need to compensate for missing parameter details, and the schema coverage 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 states the action 'replace clip media' but the qualifier 'expanded operation' is vague and fails to distinguish this tool from the sibling 'replace_clip' or 'relink_media'. The verb is clear but the scope and meaning of 'expanded' are undefined.
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 alternative tools such as 'replace_clip' or 'relink_media'. The description provides no 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 full burden for behavioral disclosure, but it fails to do so. There is no indication of side effects, reversibility, or changes to project state, which is especially important because 'set_active_sequence' directly modifies state.
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 concise sentence with no waste, but it is under-specified. Brevity is acceptable, but it lacks any useful supporting detail that could justify 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?
Given the tool's role in state modification and the absence of annotations and output schema, the description is incomplete. It offers no information about return behavior, failure modes, or how it interacts with other sequence-related tools, leaving many unanswered questions 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 coverage is 100% and the only parameter, 'sequenceId', is self-explanatory and fully described in the schema ('The ID of the sequence to activate'). The description adds nothing beyond the schema but does not need to, as the parameter is simple and well-documented.
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 'Sets the active sequence in the project' is minimal and only restates the tool's name without additional context. It does not distinguish this tool from siblings such as 'get_active_sequence' or other sequence-related operations, offering no specificity about what 'active' means or its implications.
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 (e.g., an open project) or the effect of setting an active sequence on subsequent operations, leaving critical usage context unaddressed.
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. It gives no behavioral details: what happens to the current volume, does it require a selected clip, what units are used (dB, percentage), is it a gain or absolute setting? Nothing beyond the act of setting volume is disclosed, making it 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 extremely concise (one short sentence) and front-loaded, which is good for scanning. However, it is under-specified and lacks structure to convey any useful context. It is concise but at the cost of meaning, so a middle score is appropriate.
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 there are no parameters, no output schema, and no annotations, the description is the sole source of information. It is clearly incomplete: it does not state the effect on the clip, the default value, error conditions, or how it integrates with other clip operations. This is nearly as minimal as the 'process' example and fails to provide necessary 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 tool has zero parameters, so the description must explain what value the volume is set to. It only says 'set clip volume' without specifying a target value or default. This leaves the agent guessing whether it's a toggle, a preset, or a fixed level. The description fails to compensate for the lack of schema 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 identifies the action: setting clip volume. It distinguishes from siblings like set_clip_opacity or set_clip_pan by naming volume specifically. However, it lacks specifics about the scope (which clip, what volume value) and uses vague 'expanded operation' filler, so not 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 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, target selection (e.g., selected clip), or exclusions. The agent has no idea when this should be invoked or what conditions apply.
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 (readOnly, destructive, etc.) were supplied, and the description provides no behavioral details—such as whether the operation is irreversible, whether it flushes unsaved work, prompts for confirmation, or raises an error if a sequence is not open. Annotation contradiction: none.
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?
One single sentence, no waste, but the phrase 'expanded operation' is filler and no bullet-like structure or technical terms are used. The entry is short, but the lack of concrete technical content and stream references makes it more diffuse than 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?
No mention of return values, errors, effect on the Premiere project, required state (open/closed), or side effects. There is no output schema, no annotations, and no context about which sequence or which type the sequence is. Given that zero parameters are available, the object parameter remains unspecified. It is the bare minimum A function marked by the existence of many siblings but no differentiation.
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 a single object with arbitrary properties in the input schema; with 0 parameters, the description is not necessary. However, the schema does not enforce required keys or value types, and the property name in the statement is simply 'string'; effectively the schema says any JS object with arbitrary string keys. No parameter meaning is conveyed by the description, but with zero parameters that is acceptable.
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?
Description 'Premiere Pro expanded operation: close sequence' essentially restates the tool name; it does not specify what 'closing' does (e.g., closes an open sequence project, a timeline, or selected clips), what the end state is, or which sibling operations it competes with.
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 contextual information on when to use this function vs alternatives; there is no guidance for choosing close_sequence over create_sequence, delete_sequence, or get_sequence_settings. The description is a bare verb phrase with no decision factors.
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 side effects, file output, or prerequisites; it only says 'export as project.' It does not mention whether a save location is prompted, whether an existing project is overwritten, or what the result of the operation 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 only one short phrase, but it is mostly vacuous: 'Premiere Pro expanded operation' is filler and 'export as project' repeats the tool name. It is under-specified rather than usefully 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?
With no annotations, no output schema, and no usage details, the description is inadequate for a tool that performs an export operation. An agent cannot determine the input scope, return value, or side effects of calling 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 0 documented parameters, so the baseline for this dimension is 4. The description adds no parameter details, but there are none to add; the schema coverage is effectively 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 reads 'export as project,' which is a direct restatement of the tool name export_as_project. It identifies the domain as Premiere Pro but adds no specification of what exporting as a project entails or how it differs from export_as_fcp_xml, export_aaf, or export_omf.
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 choose this tool over sibling export tools or how it relates to validate_project_for_export, encode_project_item, or start_batch_encode. The description neither states prerequisites nor excludes 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 full disclosure weight. 'Get item info' implies a read-only operation, but it does not disclose what information is returned, what inputs affect the query, whether selection matters, or any failure/edge-case behavior. This is minimal at best.
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 meaningfully concise—it spends words on the filler phrase 'Premiere Pro expanded operation' and then merely restates the tool name. The sentence does not earn its place because it adds no distinguishing 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, an empty parameter list, and an enormous sibling tool list, this description is severely incomplete. An agent cannot determine what 'item' means, what data will be returned, or how this tool differs from get_project_item_info and other retrieval 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 documented parameters, so there is no parameter semantics the description needs to clarify. The baseline for 0-parameter tools is 4; the description does not actively harm this, though it also adds no useful context about how the tool determines its target.
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 item info' restates the tool name without specifying what 'item' refers to (project item, clip, sequence item?). It also doesn't differentiate from sibling tools like get_project_item_info or get_full_clip_info, making the intended resource ambiguous.
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 150+ sibling tools including several info-retrieval tools, the absence of any contextual or exclusionary information leaves the agent unable 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?
No annotations are provided, and the description does not disclose any behavioral effects, such as whether clips get grouped, how the timeline changes, or if there are undo/redo implications. The description just 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?
While very short, this is under-specification rather than conciseness. 'Premiere Pro expanded operation: nest clips' conveys almost nothing beyond the tool name. It lacks structural 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?
Given there is no output schema and no annotations, the description is the only source of context. It fails to explain how clips are nested, what inputs are needed, or what the expected outcome is. Inadequate for a tool with 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?
The tool has no parameters, so the schema is minimal. The baseline for zero parameters is 4, and the description doesn't need to add parameter semantics. It provides no misleading information.
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 'nest clips' which indicates a verb+resource action, but it's vague—'expanded operation' adds no clarity. It doesn't distinguish from siblings like 'unnest_sequence' or 'create_subsequence' beyond the basic action.
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, selection requirements, or scenarios where nesting is appropriate. Completely absent.
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. 'Search' loosely implies a read operation, but the description doesn't state what items are searched, what results look like, or whether any state changes. No side effects or return format 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 short but not concise in a useful way—it is under-specified. It lacks essential details and isn't front-loaded with beneficial information. 'Expanded operation' is unnecessary and contributes no 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 with no annotations, no output schema, and a vague description, this is completely inadequate. It fails to explain search behavior, result handling, or how it differs from sibling tools, making it nearly impossible 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.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The context indicates zero parameters, and the schema coverage is 100%. The description adds nothing about parameters, but with none to explain, the baseline of 4 applies. However, it doesn't clarify how a search can operate without input, which slightly reduces its helpfulness.
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 literally restates the tool name: 'search project items.' It adds no specific verb or resource detail beyond the name, and doesn't distinguish from siblings like list_project_items or find_project_item_by_name. 'Premiere Pro 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 given on when to use this tool versus alternatives. It doesn't mention any use case, exclusions, or alternative tools, leaving the agent to guess which search-like 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?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it discloses nothing — no side effects, no requirement to have the file selected or writable, no note on whether existing XMP data is overwritten, and no return value. The term 'expanded operation' hints at low-level behavior but never explains it.
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?
It is a single short sentence, but this is under-specification rather than conciseness. The opening phrase 'Premiere Pro expanded operation:' is wasted characters that add no value over the tool name, and the remaining text is pure tautology.
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?
In the context of a 240+ sibling tool environment with a clear get/set semantic split, this description is wholly inadequate. There's no mention of return values, relationship to get_xmp_metadata, object it operates on, or error conditions (e.g., missing metadata values). The near-total overlap between name and description means the agent gets nothing beyond the identifier.
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?
Per the rubric, 0 documented parameters earns a baseline of 4. However, this is somewhat generous: the schema is suspiciously empty (only propertyNames/additionalProperties, no actual properties), and a 'set' operation almost certainly requires arguments that are entirely undocumented in both the schema and the description. Neither source provides any 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 'set xmp metadata' is essentially a verbatim restatement of the tool name with no added meaning. The 'Premiere Pro expanded operation:' prefix provides no functional information, and there's no clarification of what XMP metadata is set on (clip, sequence, project) or what the operation does beyond the literal 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 provided on when to use this tool versus closely related siblings like `set_metadata`, `get_xmp_metadata`, `set_project_panel_metadata`, or `add_custom_metadata_field`. There's no mention of prerequisites (e.g., must a file be selected?), workflow positioning, or 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?
There are no annotations; the description infers read-only behavior (get) but doesn't disclose any more behavior: side effects, permissions, return value format, or why it exists. Verifies nothing. It neither contradicts annotations (none).
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?
Very concise, one sentence, no wordiness. It does not explicitly say how to get links, but the text is compact 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?
There is no output schema, no annotation, no mention of what the links point to, no prerequisites. Sibling tools supply context. There are many sibling tools, but little 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?
There are 0 parameters; the schema has 100% coverage. Hence the description doesn't need to fill parameter information. Baseline 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 links' largely restates the tool name. It identifies a resource (clip links) and verb (get) but doesn't say what clip links are, what format, or when this should be used. Sibling tools are not mentioned.
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: no when-to-use, no alternatives, no exclusions. The phrase 'expanded operation' vaguely suggests capability but gives no actionable 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 of explaining behavior. It only states 'get clip speed' without mentioning side effects (if any), required context (e.g., active selection), return format, or error conditions. The read-only nature is implied but not explicitly 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?
The description is extremely short but wastes space with the generic phrase 'Premiere Pro expanded operation' and fails to include any substantive explanation. It is under-specified rather than genuinely concise, since it leaves critical details unaddressed.
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 details, the description is the sole source of information. It fails to explain what 'clip speed' refers to, how the target clip is determined, or what the output represents. Simple as the operation may be, the description is not adequate for an agent to reliably use 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 accepts zero parameters, so there is no parameter semantics to clarify. The schema covers everything vacuously, and the description adds no parameter information, which is acceptable for a no-parameter tool.
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 as retrieving clip speed ('get clip speed'), which is a specific verb and resource. However, 'Premiere Pro expanded operation' adds little and there is no explicit distinction from sibling getters like get_clip_properties, though 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 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 conditions apply, or how it differs from alternatives like set_clip_speed_qe or speed_change. No context or examples are provided, leaving the agent without any 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?
No annotations are provided, so the description carries the full burden of disclosing behavior. It only implies a read operation via the word 'get' but does not state what information is returned, whether any selection is required, whether it reads from the currently selected clip or an effect object, or any potential side effects. No behavioral traits beyond the tool's name are 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?
The description is a single sentence with no structural waste, but it is under-specified rather than appropriately concise. The phrase 'Premiere Pro expanded operation' adds no value and obscures the actual purpose. The description is too terse to be useful, 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 output schema, no parameter documentation, and a rich set of sibling tools, the description is incomplete. It fails to explain what 'effect properties' means, how the effect is identified, what the response looks like, or any context about the current selection. This is insufficient for an agent to 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, and schema coverage is 100%, so the description is not expected to explain parameters. However, the schema itself is oddly permissive (additionalProperties allowed), and the description does not clarify that no arguments are required, leaving slight ambiguity. The 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 essentially restates the tool name: 'get effect properties.' It identifies the action (get) and resource (effect properties) but adds no scope, such as which clip or sequence's properties, how to identify the effect, or what properties are included. 'Expanded operation' is unexplained filler and does not distinguish this from sibling tools like list_clip_effects or get_value_at_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?
The description provides no guidance on when to use this tool instead of alternatives. There is no mention of prerequisites (e.g., a selected clip, an effect instance), no indication of which sibling tools to prefer, and no context about how this fits into a 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?
No annotations are provided, so the description carries the full burden. It implies a read operation ('get') but does not disclose what data is returned, whether any active selection is required, or whether it can fail (e.g., on offline media). This minimal disclosure is insufficient for a tool with no other 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 short and front-loaded, but it is under-specified rather than concise. 'Premiere Pro expanded operation' adds no informational value and merely repeats the tool name. The single sentence does not earn its place, as it contributes no actionable details.
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, no annotations, and a rich set of sibling tools, the description must explain what 'full clip info' returns and when to use it. It does neither. The tool is simple (0 params), but the return value and use cases remain completely unspecified, leaving a significant 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 zero parameters, and the schema reflects that. With no parameters to document, the description does not need to explain parameter semantics. Baseline for 0 params is 4, and the description does not detract from it.
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 full clip info' essentially restates the tool name with the vague modifier 'expanded'. It fails to specify what 'full clip info' includes or how it differs from sibling tools like get_clip_properties or get_project_item_info. This is closer to a tautology than a meaningful purpose 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?
There is no guidance on when to use this tool versus alternatives. The description does not mention any prerequisites (e.g., active project, selected clip), exclusions, or specific scenarios, leaving the agent without contextual decision-making 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?
No annotations were provided, so the description carries the full burden of behavioral disclosure—and it delivers nothing: no read-only confirmation, no side-effect declaration, no error/performance notes, no mention of what happens on missing items. While not contradictory, the phrasing 'expanded operation' is content-free and fails to convey any behavioral traits beyond the tool's own 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 short, but that is under-specification, not crafted conciseness. 'Expanded operation' is filler jargon, and the remaining words restate the tool name. No useful information has been front-loaded because there is no useful information present.
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 getter with no params, no output schema, and no annotations, the description is the sole carrier of meaning—yet it leaves the agent clueless about what 'project item info' contains, how it differs from get_item_info or get_full_project_overview, or when it returns useful results. Given the huge sibling surface area (270+ tools), this is a critical 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 declares 0 parameters and 0 required parameters with 100% schema description coverage (vacuously), so the rubric's baseline for 0 params is 4. The description isn't required to explain parameter semantics it doesn't have, though the odd empty schema (additionalProperties: {}) goes unremarked.
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 item info" is a near-tautology that restates the tool name. The phrase 'expanded operation' is unhelpful jargon, and the description provides no specificity about what the info contains or what a 'project item' is. In a sibling set with get_item_info, get_full_project_overview, get_full_clip_info, and find_project_item_by_name, there is zero 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 when-to-use guidance exists. The description never tells the agent when to choose this getter over the many overlapping siblings (get_item_info, get_full_project_overview, get_bin_contents), nor does it mention prerequisites, ordering, or alternatives. This is only a 2, not a 1, because it isn't actively misleading—it's just empty.
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 says 'get sequence count,' which implies a read-only operation, but does not specify what happens with no sequences, which project scope is used, or whether the count includes nested or sub-sequences.
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 effective: 'Premiere Pro expanded operation' is generic filler, and 'get sequence count' merely repeats the tool name. It is under-specified rather than concise, providing almost no new information beyond the identifier.
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 zero parameters, the description must clearly state what the return value represents. It does not indicate whether the count is for the active project, all open projects, or the active sequence, nor does it mention return type or edge cases, leaving essential context 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 there is no parameter semantics to explain. The schema shows an empty object with no required fields, and the baseline for a no-parameter tool is 4 since the description does not need to compensate for schema 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: get sequence count,' essentially restates the tool name without clarifying what the count represents or which context it operates on. It does not distinguish itself from siblings like list_sequences or get_sequence_structure, leaving the 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 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. Sibling tools such as list_sequences and get_sequence_structure are available, but the description does not mention any selection criteria, 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, and the description only says 'get unused media'. It does not disclose whether the operation is read-only or follows a specific policy, whether it includes only metadata or also physical media bytes, whether it permanently deletes/moves media from bins, or whether it depends on project state/sequence state. The behavior is opaque beyond the verb 'get'.
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?
One sentence, concise and no wasted words. However, it includes no operational detail, qualification like 'bin' vs 'project', or expected output summary. Size is acceptable but under-specification limits the score from being higher.
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 for a 0-parameter tool: it does not explain the return value shape or type, does not name or contrast any sibling/alternative tools, does not mention required media type, project state, or prerequisites. Sibling tools with much richer descriptions (e.g., get_used_media_report, list_project_items) cover overlapping territory, increasing the need for better 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?
The input schema is 100% covered with variable names/string constraints but it declares zero parameters. The description adds essentially no parameter-level meaning, so baseline 3 from complete schema coverage; no credit beyond schema is earned because 'unused media' is not elaborated.
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?
Description 'Premiere Pro expanded operation: get unused media' is essentially a tautology that restates the tool name without specifying what counts as 'unused' (unused in the project? unreferenced clips? media in bins?), what filtering/return behavior to expect, or how the result is structured. It does not distinguish this tool from siblings like get_used_media_report, get_offline_media, or list_project_items beyond the narrow 'unused' 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 on when to call this vs alternatives. It does not name sibling tools, describe whether 'unused' means media not referenced by any sequence/project item, or mention whether a project must be open or any required context (e.g., workspace/sequence loaded).
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 says 'expanded operation: redo.' It doesn't explain whether it redoes the last undone action, supports multiple levels, affects the current sequence, or has side effects. It is not contradictory, but it discloses essentially nothing 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 short and front-loaded, but this is under-specification rather than effective conciseness. The single sentence occupies space without conveying 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 output schema and no annotations, the description must fully explain the operation, but it leaves even basic semantics undefined. In a large sibling set containing undo and multiple_undo, this description is insufficiently 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 is trivially complete. The description adds no parameter information, but none is needed for a parameterless 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 only restates the tool name ('redo') wrapped in the generic phrase 'Premiere Pro expanded operation.' It doesn't specify what action is redone or what resource/state is affected, and it fails to distinguish the tool from siblings like undo or multiple_undo.
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 about when to use redo versus undo, multiple_undo, or other history-related tools. There is no mention of prerequisites such as having performed an undo first or the expected context in which this operation succeeds.
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 provided, so description must bear the burden. It doesn't disclose whether this is a read or write operation, potential side effects, or required setup. 'Expanded operation' is ambiguous and could imply complex behavior, 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but it's under-specified rather than concise. The phrase 'expanded operation' is filler and adds no value. It could be improved with actionable details.
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 large number of sibling tools and no output schema, the description is incomplete. It doesn't clarify what 'anchor point' refers to (e.g., motion anchor point) or how it affects the clip. Adequate for a simple setter, but lacking context in a complex Premiere Pro environment.
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 shows 0 parameters, so there is nothing to describe. The description adds no parameter info because none exist. Given schema description coverage is 100% (vacuously), a baseline of 4 is suggested for 0 params, but the description still lacks clarity about how the anchor point is set (implicitly via selection?). I'll give 3 as no value added.
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 anchor point.' is vague - it does not specify what the tool does beyond setting an anchor point, nor does it distinguish from siblings like set_clip_scale, set_clip_rotation, etc. It uses 'expanded operation' without explaining what that means.
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 vs alternatives. It doesn't mention prerequisites like having a clip selected or a sequence active. The name suggests a clip modification, but no context is 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, and it fails. 'set' implies mutation, but the description never states intended side effects, whether a selected effect is required, whether the operation persists, what happens for invalid property names, or whether it works on audio/video/graphics effects alike. Nearly all behavioral detail is undisclosed.
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?
At eight words, it wastes no words, but brevity here stems from under-specification rather than economy: 'set effect property' is a direct restatement of the tool name with only the generic 'Premiere Pro expanded operation' prefix added. This is closer to a tautology than to efficient, information-dense copy.
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 zero documented parameters, this description is drastically under-specified. The tool clearly accepts a generic JSON payload (per the permissive schema), yet the description gives no hints about the payload shape, how effects/properties are addressed, or how it relates to get_effect_properties. It is inadequate for an agent to use safely.
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%, but only vacuously, since the input schema is an effectively empty permissive object with zero documented properties. The baseline of 3 applies per the high-coverage rule, and the description adds nothing beyond that baseline, offering no example structure like {effectId, property, value}. It neither helps nor hurts an agent's parameter understanding.
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 provides a clear verb+object ('set effect property') scoped to 'Premiere Pro', so an agent knows at a high level what action is being performed. However, 'expanded operation' is opaque internal jargon, and nothing differentiates this from the ~170 sibling tools like set_clip_properties, set_blend_mode, or set_time_interpolation. It never says what an 'effect property' is or how it's identified.
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 for when to prefer this tool over the many alternatives such as get_effect_properties, apply_effect, remove_effect, or batch_apply_effect. There is no when/when-not context and no mention of prerequisites (e.g., must a clip/effect be selected, must get_effect_properties be called first). An agent could not confidently choose this tool from the description 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 full responsibility for disclosing behavior. It only states the action without detailing side effects, state changes, or dependencies (e.g., whether it modifies the active sequence's targeted tracks, if it requires a specific sequence to be loaded, or if it affects clip insertion). This 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence with no wasted words, so it is concise. However, it is under-specified; it lacks the detail needed to be truly useful. Conciseness is more than brevity; it should pack information efficiently, and this sentence provides only a nominal 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 the tool's apparent simplicity, the description is still incomplete. It does not explain what 'target track' refers to (e.g., audio/video, specific index), how the tool selects the target, or any effects on subsequent operations. With no annotations, output schema, or parameter explanations, the description fails to provide enough context for an agent to use 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 tool has 0 parameters, and schema coverage is 100% (trivially). Per rubric, baseline for high coverage is 3. The description does not need to explain parameters since none exist, but it also does not add any context about what the tool operates on, relying entirely on implicit understanding of 'target track'. Thus it meets baseline but adds no extra value.
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 target track' on Premiere Pro, which is a verb+resource. However, it doesn't elaborate on what 'target track' means in the context of Premiere Pro, nor does it distinguish this from the sibling get_target_tracks other than inversion. It's clear but lacks 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 Guidelines1/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, what prerequisites exist (e.g., an active sequence or selected track), or how it differs from alternatives like get_target_tracks or set_all_tracks_targeted. The description is too minimal to offer any 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?
With zero annotations, the description must disclose behavior, side effects, and requirements. 'Premiere Pro expanded operation: slide edit.' reveals nothing about what the tool does, what changes it makes to the timeline, whether it's destructive, or what state it operates on.
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 extremely concise. However, it's concise to the point of being underspecified rather than efficiently 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?
Despite the tool having zero parameters and no output schema, the description provides no operational context. A slide edit in Premiere Pro involves moving a clip while maintaining sync with neighboring clips, trimming the edit point, and adjusting ripple behavior. None of this critical context is conveyed. Furthermore, there's no documentation of prerequisites like having a valid selection, sequence, or an established edit point. It's impossible for an agent to determine when to use this tool or what the expected outcome is from 'expanded operation' alone.
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 completely unconstrained (additionalProperties allowed, no property definitions), so the description adds essentially no parameter guidance. There are no enumerated or documented parameters to clarify.
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: slide edit' identifies the general purpose (slide edit in Premiere Pro) but lacks specificity about what the tool actually does. It doesn't clarify the target (selected clips? playhead position?) or distinguish itself from related trim/edit tools like roll_edit or ripple_edit.
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 roll_edit, lift_selection, or trim_clip. The context of 'expanded operation' is vague and doesn't explain what selection or state is required before invoking.
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 the full burden of disclosing behavior. It only restates that an adjustment layer is added, without explaining side effects, target context, failure conditions, or how the new layer interacts with existing tracks. This is insufficient for a mutating operation with no other metadata.
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 is under-specified rather than usefully concise. 'Premiere Pro expanded operation' adds no concrete information and the remaining phrase merely repeats the tool name; every word is an opportunity to clarify behavior that was not used.
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, no parameters, and no behavioral details, this one-line description is completely inadequate for an agent to predict the tool's behavior. The agent cannot know whether the operation requires an open sequence, where the adjustment layer appears, or what success/failure looks like.
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 documented parameters, so the schema carries no parameter burden and the description is not required to explain parameter meanings. Per the rubric, 0 parameters earns a baseline of 4 even though the description adds no parameter-level detail.
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 identifies a clear action and object ('add adjustment layer'), but it does not specify scope such as where the layer is added (active sequence? playhead? specific track?) or what 'expanded operation' means. It is slightly more informative than a pure tautology, but remains vague about the actual operation 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?
There is no guidance about when to use this tool versus siblings like add_to_timeline, add_tracks, or get_clip_adjustment_layer. It does not mention prerequisites such as an active sequence or selected target track, nor does it provide any 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 provided, the description carries the full burden of behavioral disclosure. It does not state whether closing prompts to save, whether it discards unsaved changes, or whether it affects other open projects. The behavior is opaque, which is risky for a destructive-like 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 extremely short (one sentence), which is concise, but it is under-specified. It is not front-loaded with useful information; it merely restates the tool name. Conciseness is not a virtue when it omits essential context.
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 (no parameters, no output schema), the description could be complete with a single clear sentence. However, it fails to explain the operational context (e.g., what happens to the current project, whether it saves, whether it's reversible). The description is inadequate for a tool that likely has side effects.
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 description coverage is 100% (trivially, since there are no parameters). The description adds no parameter information, but with no parameters, the baseline is 4 as per the rubric. No additional 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: close project.' is vague and tautological. It restates the tool name without specifying what 'close project' entails (e.g., whether it saves, prompts, or discards changes). It does not distinguish from sibling tools like save_project or open_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 alternatives. There is no mention of prerequisites (e.g., an open project) or when closing is appropriate (e.g., before opening another project). The description offers no context for 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?
The description does not disclose any behavioral traits such as read-only nature, potential side effects, or permissions required. The verb 'get' implies read-only but this is not 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (one sentence) but includes redundant phrasing like 'Premiere Pro expanded operation' which adds little value. It is not poorly structured but could be more direct.
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 (no parameters), the description does not provide sufficient context about what the overview includes, what data it returns, or how it fits into workflows. It is too vague to be fully useful.
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, so the description adds no parameter-specific details, but the lack of parameters means the description is not deficient in explaining them. The baseline for zero parameters is appropriately applied.
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 full project overview') and identifies the resource. However, it does not specify what constitutes the 'full' overview, leaving some ambiguity about the 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 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 alternative tools like get_project_info or get_project_item_info. It lacks context about typical 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 burden. It provides no behavioral context beyond 'expanded operation' – unclear whether this is a read operation, whether it returns a large payload, whether it requires an active sequence, or whether it has performance implications. The term 'expanded' suggests more detail than a standard query but that is not explained.
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 (one sentence) but it's not efficient because it wastes words: 'expanded operation' is jargon and doesn't add meaning. It is front-loaded but the single sentence is too sparse to be considered well-structured. It's not bloated, but it also doesn't earn its place by conveying useful information beyond 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?
Given the complexity of the suite (many sibling aggregation tools), this description is incomplete. It doesn't mention what 'full' encompasses, whether it returns tracks, clips, markers, settings, or project-level data. With no output schema and no annotations, the description must compensate, and it doesn't. The agent cannot predict the tool's behavior or output shape.
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 description has little to add. Per the rubric, 0 params = baseline 4. However, the description doesn't clarify any hidden context like whether it operates on the active sequence or requires prior setup. Still, with no parameters, the schema is complete; the description adds nothing but also doesn't need to.
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 says 'Premiere Pro expanded operation: get full sequence info.' It identifies the verb and resource (get sequence info) but the purpose is vague and doesn't differentiate this from the many sibling tools like get_sequence_structure, get_sequence_settings, get_timeline_summary, get_full_project_overview, etc. It's clear it's a 'get' operation but not what specific 'full sequence info' includes or how it differs from similar 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 offers no guidance on when to use this tool versus alternatives. There are multiple sibling tools that aggregate sequence data (get_sequence_structure, get_timeline_summary), but the description provides no exclusions or comparisons. The word 'expanded' hints at 'full' vs a basic version but it's not explicit.
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 provides none: no mention of read-only behavior, output format, sequence selection semantics, failure modes, or side effects. The description merely 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 very short, but it is under-specified rather than usefully concise. 'Premiere Pro expanded operation:' is generic boilerplate, and the remaining text duplicates the tool name without adding meaningful 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 output schema, no annotations, and a vague description, the agent has no way to know what a 'sequence structure' result contains or how it relates to similar sequence-inspection tools. This is inadequate for confident tool selection and result interpretation.
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 schema low-coverage burden to compensate for. With no params to explain, the description cannot add much here, and the no-parameter baseline of 4 is appropriate.
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 names the operation ('get sequence structure') and a clear resource, but 'Premiere Pro expanded operation:' is meaningless filler and the phrase 'sequence structure' is vague. It does not distinguish this tool from closely related siblings like get_full_sequence_info, list_sequence_tracks, or get_timeline_summary.
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. Given the large sibling list with overlapping sequence-inspection tools, the agent is left to guess whether this is the right call for a given task.
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 for behavioral disclosure. It does not state whether the operation is read-only, what output it returns, error conditions, or any side effects. The agent is left without essential information about this tool's runtime 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 concise (one sentence) and not verbose, which is good. However, it is under-specified and does not convey more than the name already implies. It lacks any structuring or additional context that would earn a higher 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?
There is no output schema, no annotations, and a minimal description. The tool might return data about timeline gaps, but nothing is stated about format, timing, or prerequisites. This is severely incomplete for an agent to use effectively.
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 them. The schema is permissive with additionalProperties, but parameter count is 0. Baseline 4 is appropriate since no parameter documentation is needed.
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 'get timeline gaps' which identifies a specific resource (timeline gaps) but does not clarify what constitutes a gap or the scope. It distinguishes from siblings by naming 'gaps' but lacks detail on the actual result or 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 like get_timeline_summary or get_sequence_structure. The phrase 'expanded operation' is vague and does not offer any practical 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 provided, the description carries the full burden of behavioral disclosure but reveals nothing about side effects, return format, auth requirements, or failure modes. The unexplained 'expanded operation' phrase adds confusion rather than transparency, as it's unclear what 'expanded' means in this context.
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, front-loaded sentence that is quick to parse. However, the phrase 'Premier Pro expanded operation' is filler that wastes the limited space and reads like a template remnant rather than earned content; this is under-specification rather than effective 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?
For a zero-parameter tool, the description still fails to convey what happens on invocation—what is returned, what valid inputs (if any) the internal object works on, or when it would return an error. The absence of an output schema makes the missing behavioral disclosure especially damaging in guiding 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 0 parameters and 100% schema description coverage, so there is no parameter ambiguity for the description to resolve—under the rubric, this yields a baseline of 4. No additional parameter semantics are likely 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: inspect dom object' is essentially a verbatim restatement of the tool name, making it tautological. It never clarifies what 'DOM' refers to in the Premiere context, what object is being inspected, or what inspecting yields. The only reason it's not a 1 is that 'inspect' does imply a read/introspection 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 the 200+ siblings. There is no mention of prerequisites, alternatives, or scenarios where inspecting a DOM object is preferred over tools like `get_premiere_state`, `execute_extendscript`, or `get_full_project_overview`.
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 it only repeats the tool name. It fails to disclose what happens with no selection, whether the operation is undoable, or whether it requires an active project/sequence.
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 text is extremely short, but not economically concise—'Premiere Pro' and 'expanded operation' add no value over the name. It is understandable but wastes its only sentences on 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?
For a zero-parameter tool with no output schema, the description still fails to clarify scope or edge behavior. It provides no information about return values, failure modes, or how selection inversion manifests, leaving the agent underinformed.
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, so the baseline of 4 applies. The description need not add parameter information that the empty schema already covers.
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: invert selection' essentially restates the tool name without adding clarity. The phrase 'expanded operation' is vague filler, and the tool's verb-object meaning comes solely from its name, not the description.
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 select_all_clips or link_selection. There is no mention of prerequisites, exclusions, or context in which inverting a selection 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 exist, so the description carries the full burden of behavioral disclosure. It only says 'set anti alias quality' without revealing prerequisites (e.g., open project/sequence), what object's setting is changed, whether it affects rendering or export, or any side effects. This is nearly complete opacity for a mutation-like 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 one short sentence with the generic prefix, making it scannable and not verbose. However, the brevity crosses into under-specification, though that is more a completeness gap than a structural inefficiency.
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 setter tool with no annotations and no output schema, the description is far too thin. It fails to mention the target scope (sequence, project, or export settings), valid values, or behavioral impact, so an agent cannot determine when or how this operation is relevant.
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%, so the description does not need to explain parameter meaning. The baseline for zero-parameter tools is 4, and there is no missing parameter documentation to penalize.
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 verb 'set' and the target 'anti alias quality,' so it is not misleading. However, it merely restates the tool name in sentence form with a generic 'Premiere Pro expanded operation' prefix, adding no detail about what anti-alias quality affects or how it differs from other set_* 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, what context requires it, or which alternative tools might be preferable. With dozens of set_* sibling operations, the absence of usage context leaves the agent without 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?
No annotations are provided, so the description carries the full burden of disclosing behavior. It only states 'set scale width height' without explaining side effects, prerequisites, or what operations are performed 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it sacrifices clarity. It's not a well-structured explanation; it's just a restatement of the name with a generic 'expanded operation' prefix that adds no 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?
Given the lack of output schema and parameter details, the description is inadequate. It doesn't explain what 'scale width height' applies to, making the tool's purpose and usage unclear in the broader context of 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 schema has 0 parameters, and the baseline for such cases is 4. The description adds no additional information about inputs, but since there are none, this is acceptable though not exemplary.
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 scale width height' essentially repeats the tool name without specifying what entity it affects (e.g., clip, sequence). It lacks differentiation from sibling tools like set_clip_scale or set_uniform_scale, making its 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 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 many similar set_* tools in the sibling list, the absence of usage context leaves 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?
The description provides no information about side effects, dependencies, or what happens when the tool is invoked. With no annotations, the description is the only source of behavioral info, and it 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 concise sentence that efficiently conveys the core action without unnecessary words.
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 extremely minimal, lacking any context about output, errors, or expected behavior. Given the empty schema and no annotations, the description does not sufficiently complete the picture for a user or 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 input schema has no parameters, so there is nothing to add meaning to. The description does not introduce parameter semantics, but this is a neutral case 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 clearly states the tool creates bars and tone in Premiere Pro, which is a specific action and resource. It distinguishes from sibling tools by naming a unique operation, though it lacks further 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?
There is no guidance on when to use this tool versus alternatives. The description simply restates the function without any context, prerequisites, or comparison to other 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 for behavioral disclosure, but it only repeats the operation name. It does not state whether an active sequence is required, what marker types are supported, what the return shape is, or whether this is a read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence, but 'Premiere Pro expanded operation:' is unnecessary filler, and the remainder mostly repeats the tool name. It is concise but not information-dense enough to justify its 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 no annotations, no output schema, and no documented parameters, the description is too thin to fully support tool selection and invocation. It fails to explain marker types, return semantics, or relationship to overlapping marker-related 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 has no actual properties (parameter count 0), so the baseline is 4. However, the description's 'by type' implies a filter concept without defining valid marker type values, and the schema's propertyNames with 'type' is ambiguous—leaving the agent without enough information to know what input, if any, is expected.
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 'get sequence markers by type,' which conveys a specific action and resource. However, the phrase 'Premiere Pro expanded operation:' is boilerplate filler, and the description does not distinguish this tool from siblings like list_markers or get_clip_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 such as list_markers or get_clip_markers. There are no prerequisites, exclusions, or context hints beyond the bare operation name.
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 only restates the operation without disclosing side effects, whether a single clip is created from multiple files, UI behavior, or return values. It adds almost 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 extremely short, but this is under-specification rather than effective conciseness. A single vague sentence does not adequately inform an agent about the tool's behavior or 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?
With no annotations, no output schema, and many sibling import-related tools, this description is far too sparse to be contextually complete. It does not explain what an image sequence import entails or how it fits into the broader Premiere Pro workflow.
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 imposes no meaningful parameter requirements. Per baseline for zero-parameter tools, the description need not compensate for missing parameter 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 the core action 'import image sequence' with a clear verb and resource. However, it does not distinguish this from sibling tools like import_media, import_folder, or import_sequences, and '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?
There is no guidance on when to use this tool versus alternatives such as import_media or import_sequences. The intended use case is only implied by the tool 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?
No annotations were provided, so the description carries the full disclosure burden, but it reveals almost nothing: no mention of selection requirements, undo behavior, or whether the operation is destructive. The phrase 'expanded operation' faintly hints this is an internal menu-command passthrough, which offers marginal credit, but consequences remain undisclosed.
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?
Eight words with no filler and the meaningful qualifier ('expanded operation') front-loaded. It's terse and gets to the point, though that terseness borders on under-specification.
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 parameter-less tool with no annotations or output schema, the description is the only source of context, yet it omits critical operational context like whether a selection must exist, whether the command is undoable, and how it diverges from semantically similar operations such as extract_selection. A couple of explanatory sentences would have sufficed.
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 correctly takes zero parameters, making schema coverage trivially 100% and rendering parameter documentation unnecessary. Per the rubric, 0 params earns a baseline of 4; the description has nothing to add and correctly doesn't attempt to.
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 phrase 'lift selection' merely restates the tool name, making this essentially tautological. The only added context is that it's a 'Premiere Pro expanded operation,' implying a direct passthrough to an internal command, but the core action of 'lifting' remains unexplained. It does not distinguish from siblings like extract_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 Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Zero guidance is given on when to invoke this tool versus any of the ~300 siblings. Given overlapping operations like extract_selection, ripple_delete, and remove_selected_clips exist in the sibling list, explicit when-to-use or alternative-naming would be highly valuable but is entirely absent.
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 mentions an 'expanded operation' with no details about destructive effects, output, or side effects. Closing all source clips implies a state-changing operation with no warning.
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?
One compact sentence and acceptable length, but it leaves out key behavioral specifics (e.g., whether this is a destructive close, whether it closes monitors).
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?
No output schema, no annotations, no sibling comparison, and no context about the larger editing workflow. The description alone is too thin for an AI to safely select this among many media-editing operations.
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 no parameter help is required; the schema includes no meaningful descriptive properties.
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 names a specific action and target ('close all source clips') with a verb and object, but it does not distinguish this from sibling tools that also close or remove 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 about when to close source clips vs. using alternatives, expected contexts, or fallback behavior; relies on the tool name.
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 does not disclose any side effects, prerequisites, or postconditions beyond the simple action. With no annotations to supplement, it offers no insight into behavioral 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 extremely concise, consisting of a single sentence that front-loads the main action. There is no fluff or redundant wording, making it optimally sized.
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 largely restates the tool name ('close_source_monitor'). It lacks any additional context about the state of the source monitor, potential effects, or relationship to other tools, leaving the user with little beyond the action itself.
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 parameters, so there is nothing to describe. The description adds no parameter details, but this is not a deficit since the schema is empty and no parameter semantics are required.
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') and the target ('source monitor'), making the tool's purpose evident. It distinguishes from other monitor-related operations, though it does not elaborate on scope or variations.
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, nor any prerequisites or conditions. The description is purely a statement of the action with no contextual usage advice.
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 must carry the full burden of behavioral disclosure. It says only 'create smart bin' and reveals nothing about side effects, permissions, required project state, or what happens to existing selections or bins.
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 'expanded operation' is filler that adds no meaning. It is not bloated, yet it is too minimal to be considered a well-structured, informative 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 Premiere Pro operation that creates a smart bin, the description is far too sparse. It lacks any explanation of what a smart bin is, how it behaves, what inputs or criteria are involved, whether a project must be open, or what the result will be. The sibling list shows many bin-related tools, but this description does not position itself among them.
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 usage. The schema provides full coverage for an empty parameter set, and the baseline for no-parameter tools 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 ('create') and the resource ('smart bin'), so the core purpose is identifiable. However, the phrase 'expanded operation' is vague and does not explain what distinguishes a smart bin from a regular bin or from the sibling create_bin 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 about when to use this tool versus alternatives like create_bin, nor any mention of prerequisites such as an open project or an existing bin structure. The description provides no context for selecting this tool over its 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 says 'get next edit point,' which implies a read operation but discloses nothing about what is returned, whether the playhead moves, which sequence is queried, or how edge cases (no next edit point) are handled. This falls short of minimal 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 short, but it does not earn its place: 'Premiere Pro expanded operation' is filler, and 'get next edit point' merely repeats the tool name. It is under-specified rather than effectively concise, and it lacks any useful structure or additional 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 params, no output schema, and no annotations, the description needed to clarify context (which sequence, which edit point, relative to what) and return semantics. It does neither. Compared to other timeline inspection tools, this description is incomplete and leaves an agent guessing about expected behavior and output.
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 declared parameters, so the baseline for this dimension is 4. The description does not add parameter-specific meaning, but no parameters exist to document. It could have clarified implicit context like the active sequence or playhead, but the absence of parameters means the schema imposes no parameter burden.
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 clear verb and resource ('get next edit point'), but it is essentially a restatement of the tool name plus the boilerplate 'Premiere Pro expanded operation.' It lacks critical context such as what 'next' is relative to (playhead? selected clip?) and how it differs from siblings like get_clip_at_playhead or move_playhead_to_edit. This is a vague purpose rather than a fully distinguishing one.
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 the active sequence, playhead position, timeline context, or any exclusions. With dozens of related timeline and edit-point tools among siblings, the lack of usage criteria is a clear gap.
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 provides no behavioral disclosure beyond restating the tool's name. It does not mention what version is returned (Premiere Pro app version, project version, API version), the return format, or whether any side effects occur. With no annotations, the description carries the full burden and fails to add any meaningful 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 only one sentence, but it is under-specified rather than concise. The phrase 'Premiere Pro expanded operation' is redundant filler, and the core message is just a repetition of the tool name. It lacks the informative brevity that earns points.
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 zero-parameter tool, the description still fails to clarify what 'version info' refers to. It does not state whether the result is a string, object, or what fields it contains. Given no output schema, this ambiguity leaves the agent guessing about 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 correctly reflects that with an empty object. The description doesn't need to explain parameter semantics, and the 100% schema coverage ensures no ambiguity. This meets the baseline 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 identifies the action as retrieving version information, with a specific verb and resource. However, it doesn't differentiate this from other getters like get_premiere_state or get_capabilities, and the 'expanded operation' prefix adds noise.
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 many sibling tools that fetch state or info, the absence of any contextual hints or exclusions leaves the agent without criteria for 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?
No annotations exist, so the description carries the full disclosure burden for what is a mutating operation. It fails to state how the track is identified for renaming, whether it applies to audio or video tracks, what side effects occur (e.g., breaking references), or what success looks like. The description adds no behavioral insight 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 short but under-specified rather than concise. Roughly half the text—'Premiere Pro expanded operation:'—is empty boilerplate that doesn't earn its place, leaving only two meaningful words. This is brevity through omission, not efficient 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?
For a mutating tool with no annotations and no output schema, the description needed to compensate—it does not. It omits what a track is (audio/video), how the target is selected, and how the caller observes results. While the operation is conceptually simple, the total lack of contextual scaffolding leaves the description barely 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?
With 0 declared parameters and 100% schema coverage, the schema leaves nothing to explain. Per baseline for zero-parameter tools, the description is not obligated to add parameter detail, even though it offers no hint about how a caller would indicate which track to rename.
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 phrase 'rename track' provides a clear verb+resource, so the basic action is understandable. However, it essentially restates the tool name with no additional detail about scope, variants, or how it differs from track-management siblings like delete_track or add_track. The boilerplate prefix 'Premiere Pro expanded operation:' adds no semantic 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, no prerequisites (e.g., must a track exist? must a sequence be open?), and no exclusions. Given the huge sibling list includes related track operations, this absence of direction is a meaningful 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?
With no annotations provided, the description carries full burden. It only says 'clear item in out' which implies a mutation (clearing), but doesn't disclose preconditions, side effects (e.g., does it clear in/out on the source monitor or timeline item?), or whether it requires a selected item. The term 'expanded operation' is vague and 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but it's under-specified rather than concise. It's a single sentence that reads like a stub. It doesn't front-load any useful information beyond the tool name, so while it's compact, it doesn't earn its place by adding 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 simplicity (0 params) and no output schema, a complete description could be short, but this one lacks essential context: what 'item' refers to (project item vs sequence clip), what 'in out' points mean (source in/out vs timeline in/out), and any preconditions. Without distinguishable features, an agent might confuse it with clear_sequence_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?
The tool has 0 parameters, so the schema is trivially complete. The description doesn't need to explain parameters, and the baseline for 0 parameters is 4 per rubric. There is no missing parameter documentation.
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 is extremely sparse: 'Premiere Pro expanded operation: clear item in out.' It does state a specific action (clear item in/out points) and identifies the resource (item), but it's phrased as a categorical label rather than a clear functional statement. The verb 'clear' is present, but the description reads like a title or breadcrumb, not an explanation of what the tool does. It does not distinguish itself from similar 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?
No guidance on when to use this tool vs alternatives. It doesn't mention context such as selecting an item first, or when clearing in/out points is appropriate. Sibling tools like set_item_in_out and clear_sequence_in_out exist, but no comparison or exclusion is 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 the full burden for behavioral disclosure. It indicates a read-style 'get' operation but does not explain what paths are included, whether the result is scoped to the current project, size/performance implications, or the return shape. No behavioral traits beyond the operation name are disclosed.
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 ends after the core operation, which is reasonably concise. However, the opening phrase 'Premiere Pro expanded operation:' is boilerplate filler, and the remaining text largely restates the tool name rather than adding useful structure or additional semantic 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?
The tool is simple (no parameters, no nested objects), but it has no annotations and no output schema. The description does not fill in the missing return-value or scope information, nor does it explain how this getter differs from the many closely related search/list tools in the sibling list.
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 little to explain; the schema and context signals confirm this. The description does not need to add parameter details, and the no-parameter baseline of 4 is appropriate.
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 'get all project paths', giving a clear verb and resource, but 'project paths' is ambiguous and it does not differentiate from siblings like get_used_media_report or find_items_by_media_path. The prefix 'Premiere Pro expanded operation' adds no meaningful specificity, so the purpose is only vaguely 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 given about when to use this tool instead of related tools such as list_project_items, get_full_project_overview, or find_items_by_media_path. The description contains no 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, the description carries the full burden of behavioral disclosure, but it only repeats the concept of 'link selection'. It does not mention side effects, what gets linked, whether the operation is reversible, or any required conditions.
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 'Premiere Pro expanded operation' is filler that adds little beyond the tool's name and surrounding context. Conciseness is good, but the space is not used to add meaningful 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 mutating action tool with no annotations, no output schema, and a potentially ambiguous link operation, the description is insufficient. It does not explain what selection linking does, how it differs from related tools, or what the expected result 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 tool has zero parameters, so the input schema covers everything by being effectively empty. The description does not need to explain parameter semantics, and the baseline for no parameters is appropriate.
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 ('link') and resource ('selection'), so it is not a pure tautology. However, 'expanded operation' is vague and does not clarify what linking a selection entails, nor does it distinguish this from sibling tools like link_audio_video or 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 given about when to use this tool versus alternatives such as link_audio_video or unlink_selection. The description does not state prerequisites like having a selection or what kinds of items can be linked.
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 does not explain units (e.g., degrees), value range, whether rotation is applied to the selected clip, or what side effects occur.
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 it is under-specification rather than conciseness. The phrase 'expanded operation' is filler and the sentence provides barely more than 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?
The tool is part of a large family of clip setters (scale, position, opacity, etc.), yet the description does not clarify how rotation is specified, what clip is affected, or what state is required. Without annotations or an output schema, this minimal description is 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 has zero defined parameters, so there are no parameter semantics to explain. The baseline of 4 for zero-parameter tools applies; the description adds nothing about parameters but none 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 identifies the verb ('set') and resource ('clip rotation'), distinguishing it from sibling tools like set_clip_position and set_clip_scale. However, the phrase 'expanded operation' is vague and adds no specific 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, nor any mention of prerequisites such as selecting a clip. The description implies its own use case but provides no context 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 offers no behavioral disclosure. It doesn't state whether this is a mutation, whether it requires a selected sequence, what happens if the sequence is locked, or any side effects. For a setter with zero annotation coverage, 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 a single sentence, efficient and front-loaded with the operation name. It avoids redundancy but could add a bit more useful detail without becoming verbose. The structure is clean.
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 is a mutation (setter) with no annotations, no output schema, and 0 parameters, the description must explain what action it performs and any preconditions. It fails to mention prerequisites like an open project or selected sequence, and it doesn't state what happens if no sequence exists. The completeness is severely lacking.
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, as correctly reflected in the schema. The description doesn't need to explain parameters, so it doesn't mislead. However, it doesn't explain what input the operation expects (e.g., does it use the current selected sequence and a ratio value?), but with no params, 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 'set' plus the target resource 'sequence pixel aspect ratio' with 'Premiere Pro expanded operation' context, which distinguishes it from sibling tools like set_sequence_frame_rate. However, it lacks detail on what values can be set or the effect of the operation, making it only slightly above baseline.
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 set_sequence_settings or set_override_pixel_aspect_ratio. It simply says 'expanded operation' without explaining what that means or when it should be invoked, leaving the agent without clear 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 provided, so the description must disclose behavioral traits. It doesn't explain whether this operation is destructive (deleting duplicates), requires user confirmation, what criteria define duplicates, or what the impact on project references is. The verb 'consolidates' is vague and could imply copying or merging without deletion.
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?
Single sentence, minimal waste. Would benefit from clarifying the operational scope (e.g., deletes duplicates or relinks) but no unnecessary 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 zero-parameter tool that performs a potentially complex operation, the description lacks critical information about the consolidation logic (criteria for duplicates), results (deleted items? logs?), and whether it's reversible. The existence of get_duplicate_media suggests there is a detection step that could be mentioned.
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 100% (empty schema). Since no parameters exist, the description is not expected to add parameter semantics. Baseline for 0 params is 4, and the description doesn't introduce inconsistencies.
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 that the tool consolidates duplicate media items, a clear action on a specific resource. However, it doesn't differentiate from the sibling tool consolidate_and_transfer, which likely handles similar operations with additional transfer functionality.
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 consolidate_and_transfer or get_duplicate_media. The context of consolidation (e.g., for project cleanup, saving space) is implied but 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, so the description must carry the burden of disclosing behavior. It states 'delete' implying destructive action, but does not detail irreversible effects, impact on performance, or whether it applies to the entire project or selected sequences. The 'expanded operation' phrase contributes 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 only one sentence, but it is under-specified. It includes the filler 'expanded operation' and lacks operational details. While brevity is valued, this is so short that it fails to convey essential usage context, making it incomplete rather than 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 simplicity of the tool (0 params, no output schema), a short description could suffice, but it fails to explain what preview files are, what the deletion affects, or any consequences. The description is incomplete for an agent to safely invoke this destructive operation without additional 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, so there is nothing to explain. The baseline for 0 parameters is 4, and the description correctly does not attempt to describe parameters. It adds no extra meaning, but none is required.
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 preview files'. It is specific to a resource (preview files) and distinguishes from other delete tools like delete_bin or delete_sequence. However, the phrase 'expanded operation' is vague and adds no clarity, and the scope (which project or sequence) is 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, prerequisites, or conditions. The description does not mention when deleting preview files is appropriate or if there are any side effects to consider.
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 is the sole source of behavioral information. It merely repeats the tool name without disclosing side effects, destructiveness, or what 'range' refers to. The phrase 'Premiere Pro expanded operation' adds 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 short but wastes space on 'Premiere Pro expanded operation', which adds no substantive value. The rest essentially restates the tool name. This is under-specification rather than efficient 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?
With no annotations, no output schema, and no parameter details, the description must explain what a keyframe range is, how it is determined, and what prerequisites exist. It only states the basic action, leaving the tool's operation 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 parameters, and the description need not explain any. With 0 parameters, the baseline is 4, and the schema already reflects the parameter count, so the description adding no parameter detail 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 states the action 'remove keyframe range' clearly and distinguishes from the sibling tool 'remove_keyframe' by specifying 'range'. However, the phrase 'expanded operation' is vague and does not clarify what 'expanded' entails, slightly reducing 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 the sibling 'remove_keyframe' or any other alternative. The description lacks context about prerequisites, selection requirements, or conditions under which this tool should be preferred.
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, but it only says 'set scratch disk path' without explaining side effects, persistence, required project state, or error behavior. This is insufficient for an operation that mutates project settings.
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 with minimal fluff, but 'Premiere Pro expanded operation:' is an unnecessary prefix that adds no value. It could be cut down to simply 'Set scratch disk path.'
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 setter with no annotations, output schema, or parameter details, the description is incomplete. It doesn't specify return values, failure modes, or how this interacts with sibling tools like `get_project_scratch_disks`, leaving critical gaps in understanding.
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 0 parameters with 100% schema coverage, so the baseline of 4 applies. The description doesn't need to explain parameters that don't 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 phrase 'set scratch disk path' provides a clear verb and resource, but the prefix 'Premiere Pro expanded operation:' is vague and unhelpful. It doesn't distinguish this tool from the sibling `set_project_scratch_disk`, so it misses the opportunity to differentiate.
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 `set_project_scratch_disk` or `get_project_scratch_disks`. There is no mention of context, prerequisites, or scenarios where this tool should be preferred.
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 says 'stop playback' without detailing any side effects, such as whether it sets the playhead position, releases resources, or has any impact on the currently active sequence. The phrase 'expanded operation' is vague and not explained.
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?
A single concise sentence, front-loaded with 'Stop playback'. However, the phrase 'expanded operation' adds no information and could be removed; the description is minimal but not overlong.
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 a simple tool, the description is minimal. It completely lacks context about which playback target (timeline, source monitor) is affected, and whether this applies to the active sequence or all playback. Given the sibling tools play_timeline/play_source_monitor, the description should specify the 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 description coverage is 100% (an empty object). The description doesn't need to explain parameters. Baseline 4 is appropriate since 0 params means no semantics to add.
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 stops playback in Premiere Pro, which is a clear verb+resource. However, it does not distinguish among the related sibling tools play_timeline, play_source_monitor, and stop_playback, nor does it specify which playback target (timeline vs. source monitor) is stopped.
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 play_timeline or play_source_monitor. It does not clarify whether it stops all playback or a specific monitor, nor mention any prerequisites (e.g., playback must be active).
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 burden of behavioral disclosure. It only states that a track is added, without explaining any side effects, whether the operation is undoable, what happens with existing tracks, or what success/failure 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the essential action and resource. Every word earns its place, with no filler or redundancy.
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 too thin. It fails to mention the meaning of an omitted position, whether the tool returns anything, or potential error conditions. The schema covers parameters but not 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?
The schema covers all parameters with descriptions, so the baseline is 3. The description adds 'video or audio' which aligns with the trackType enum but adds no new meaning beyond the schema. Position semantics are left to the schema's enum and description.
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 new video or audio track') and the target resource ('to the sequence'), making the tool's basic purpose unambiguous. However, it does not explicitly differentiate from the sibling tool 'add_tracks' beyond the singular/plural name 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?
The description provides no guidance on when to use this tool versus alternatives such as 'add_tracks', 'delete_track', or 'rename_track'. There is no mention of prerequisites, default behavior when 'position' is omitted, 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?
With no annotations provided, the description carries the full burden for behavioral disclosure. It merely states 'adjusts volume', implying a mutation, but does not reveal whether the change is absolute or relative, whether it affects only selected clips or all, or any side effects such as clipping or undo behavior. Critical details are missing for a modifying 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 redundant wording. It is front-loaded and directly conveys the core action and target, achieving maximum conciseness without lexical waste.
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 (2 parameters, no output schema), the description is minimal but incomplete in context. It fails to address usage guidance or behavioral nuances, especially since sibling tools like 'set_clip_volume' exist that could cause confusion. The schema covers parameters, but the description does not provide enough context to fully differentiate the tool or anticipate edge cases.
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 both parameters (clipId and level) with descriptions, achieving 100% coverage. The tool description adds no additional meaning beyond the schema; it does not explain the level values, units (though the schema mentions dB), or relationships between parameters. Baseline 3 is appropriate since the schema already documents the parameters adequately.
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 adjusts audio clip volume/gain on the timeline, which is specific and includes the resource. However, it does not explicitly differentiate itself from the sibling tool 'set_clip_volume', which appears to serve a similar purpose, limiting its clarity in distinguishing among alternatives.
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 'set_clip_volume' or 'add_audio_keyframes'. The description lacks any context about suitable scenarios, prerequisites, or conflict with other audio adjustment tools, 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.
- 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 an audio effect is applied, but does not disclose whether this adds to or replaces existing effects, whether parameters are optional, whether the effect name must come from list_available_audio_effects, or whether the operation is undoable.
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 concisely states the core action and target, 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.
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, no output schema, a nested parameters object, and a large sibling list, this description is insufficiently complete. It does not explain how to discover valid effect names, what the parameters object should contain, what happens on success, or how this differs from similar effect-applying 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 already provides descriptions for all parameters, so the baseline is 3. The description adds no additional meaning beyond the schema's clipId, effectName, and parameters definitions, and it does not clarify the structure or accepted keys for the nested parameters 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 clearly identifies the verb ('Applies'), the resource ('audio effect'), and the target ('a clip'). It differentiates from related siblings like list_available_audio_effects and apply_audio_effect_to_all_clips by indicating a single clip, though it does not explicitly contrast with the generic apply_effect.
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 versus alternatives such as apply_effect, batch_apply_effect, or apply_audio_effect_to_all_clips. The description implies the basic use case but provides 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.
- 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 disclosing behavior, but it only states 'batch apply effect' and adds the vague 'expanded operation'. It doesn't explain whether it operates on selected clips, whether it requires an effect name parameter, or what happens to existing effects. No safety or side-effect information 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and very short, with no wasted words. However, the phrase 'expanded operation' is ambiguous and could be removed. Overall, it's concise but not maximally 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?
The tool has no output schema, no annotations, and an empty input schema. The description must compensate for this lack of structured information, but it only offers a vague label. For a batch operation, more detail is needed about how the effect is specified and which items are affected, making it highly incomplete.
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 defines zero properties (parameter count 0), so schema coverage is effectively 100%. The description adds no parameter information—it doesn't even mention that an effect must be specified or how targets are chosen. This meets the baseline but offers no extra meaning.
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 says 'batch apply effect', which clearly identifies the action as applying an effect in batch, distinguishing it from the sibling tool 'apply_effect' by the batch aspect. However, it doesn't elaborate on what type of effect or which clips are targeted, making it clear but not fully 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?
There is no guidance on when to use this tool versus alternatives. The phrase 'expanded operation' hints that it extends 'apply_effect' but never states the specific scenario (e.g., applying an effect to multiple clips). No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 behavior disclosure. It does not explain what the tool returns, whether it has side effects, what constitutes an 'adjustment layer' in this context, or any prerequisites. The phrase 'expanded operation' is opaque and adds no behavioral clarity.
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 (one sentence), which is concise, but the phrase 'Premiere Pro expanded operation' is filler that does not add value. It is not as tight as it could be, as it wastes words without informing the 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?
Given no output schema, no annotations, and a vague description, the tool is under-specified. The agent cannot determine what the return value is, what conditions are required, or how it relates to other clip operations. The description is insufficient for a complete understanding of the tool's behavior.
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 per the rubric the baseline is 4. The schema allows additional properties but none are documented; however, since no parameters exist, the description does not need to add parameter semantics 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 action ('get clip adjustment layer') with a specific resource, but includes the vague qualifier 'expanded operation' which adds no concrete meaning. It distinguishes from 'add_adjustment_layer' by being a getter, but does not explicitly differentiate.
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, when not to use it, or alternatives. It simply states the operation without any context on appropriate invocation 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 provided, so the description carries the full burden. It states it 'gets' a value, implying a read operation, but doesn't disclose any behavioral traits such as whether it requires the project item to exist, what happens if the item has no color label (returns null or default?), or if it has side effects. The description is minimal and doesn't add 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, concise sentence that is front-loaded with the action. It is appropriately sized for a simple getter tool. No wasted words, but it could be slightly more informative without becoming verbose.
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 (one parameter, no output schema), the description is minimal but adequate for a basic getter. However, it lacks context about the expected return value (e.g., an integer index, possibly -1 for none) and any prerequisites. With no annotations and no output schema, the description should provide more detail to be 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 schema has 100% coverage for the single parameter 'projectItemId' with description 'The ID of the project item'. The description doesn't add any additional meaning beyond what the schema provides. Since schema coverage is high, the baseline is 3, and the description doesn't compensate with extra details like format or examples.
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: 'Gets the color label index of a project item.' It uses a specific verb ('Gets') and resource ('color label index of a project item'). It distinguishes from the sibling tool 'set_color_label' which sets the label, and from 'get_clip_properties' which might return broader properties. However, it doesn't explicitly mention the return type or the range of the index, which could be useful.
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 that it's a read-only operation, nor does it suggest when to use it (e.g., before setting a color label, or to check the current label). With many sibling tools like 'get_project_item_info' or 'get_item_info', the lack of context makes it harder for an agent to know if this is the right 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 full burden for behavioral disclosure. It only says 'gets' without explaining return format, error handling, or whether it returns timecode or frames. It does not disclose what happens when the sequenceId is invalid or whether the work area might be disabled.
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 is front-loaded with the key action and resource. This is appropriately sized for a simple getter.
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 simplicity of the tool and lack of output schema, the description still feels incomplete. It does not clarify what 'work area' means, what format the in/out points are returned in, or how this differs from get_sequence_in_out_points. For a user deciding among many sibling tools, this lacks sufficient 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?
The schema already fully describes the single parameter (sequenceId as 'The ID of the sequence') with 100% coverage. The description adds no extra meaning about the parameter or its expected format beyond what the schema provides, so the baseline 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 clearly states it gets the work area in/out points for a sequence, using a specific verb and resource. It distinguishes itself from siblings like set_work_area and is_work_area_enabled, though it does not explicitly contrast with get_sequence_in_out_points, which might be confused as similar.
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, when it is appropriate, or how it differs from related tools like get_sequence_in_out_points or set_work_area.
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, and it fails to deliver. The text merely restates the tool name without revealing side effects (is this destructive to the source clip?), prerequisites, or how the target track is determined given zero parameters. The label 'expanded operation' hints at hidden behavior that is never disclosed.
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 at one sentence and gets to the point quickly. However, the leading 'Premiere Pro expanded operation:' prefix is boilerplate that wastes precious real estate without adding information, and the somewhat cryptic 'expanded operation' phrasing detracts from the otherwise efficient 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?
With no annotations, empty schema, and no output schema, the description was the only vehicle for contextual information, and it is entirely insufficient. It never clarifies how a 0-parameter tool successfully targets a track, what state it depends on, or how it relates to the 'move_clip' sibling. The generic prefix 'Premiere Pro expanded operation' appears to be copy-pasted shared text rather than tool-specific guidance.
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?
Per the rubric, 0 parameters yields a baseline score of 4. The schema is an empty object and the parameter count is 0, so the description was not required to elaborate on parameter details. A minor deduction would be possible for not clarifying how the track is selected (selection-based vs. playhead-based), but the 0-param baseline of 4 stands.
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?
'move clip to track' uses a specific verb and resource, and the basic action is understandable. However, it does not distinguish itself from sibling tool 'move_clip', and the phrase 'expanded operation' is vague jargon that doesn't explain what makes this variant different. This is clear but lacks sibling differentiation, matching the score-4 definition.
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 'move_clip', 'set_target_track', or 'overwrite_clip'. There are no exclusions, prerequisites, or contextual hints about when 'expanded operation' is preferred, fitting the 'no guidance' benchmark.
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 'move items to bin', which is a terse statement of intent. It does not mention side effects (e.g., whether the move is destructive to original positioning, whether a specific bin is always used, permissions, or return values). The word 'expanded' hints at additional behavior but is not specific.
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. It front-loads the key action ('move items to bin') with no wasted words. However, its brevity borders on under-specification; while concise, it leaves out important context, so it earns a slight penalty for not earning its place in terms of 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?
Given no annotations, no output schema, and a very minimal input schema, the description is the sole source of information. It fails to clarify scope (which bin, which items), prerequisites, or any behavioral nuances. The existence of a very similar sibling tool ('move_item_to_bin') increases the need for differentiation, which is absent. The description is incomplete for the agent to use confidently.
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 zero parameters and the description adds no parameter-level detail. Since schema coverage is trivially high (100% because no params), the baseline is 3. The description does not clarify whether an implicit item selection is used or if the operation affects all items, but no params exist to elaborate.
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 'move' and resource 'items' to 'bin', making the purpose clear. It distinguishes from 'move_item_to_bin' by implying multiple items, though it does not explicitly say 'multiple' or specify which items (selected, all, etc.). The phrase 'expanded operation' is vague but does not mislead.
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 vs. alternatives. The sibling 'move_item_to_bin' could be a candidate, but no exclusions or context are given. The description only states what the tool does, not when or why to choose 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 carries the full burden. It does not disclose any behavioral traits such as whether the operation is reversible, whether it validates the target bin, or what side effects (e.g., changes to item metadata) might occur.
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 extraneous words, front-loaded with the primary action and resource. 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?
Given the simplicity of a single-item move, the description is minimal but lacks important context such as what happens if the target bin is invalid, whether the move is undoable, or how it differs from the plural variant. It does not compensate for missing annotations.
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 with 100% coverage, so the baseline is 3. The description does not add any extra meaning beyond what the schema already provides, as it only repeats the concept of moving to a bin.
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 specifies the action (move) and the resource (project item) and the target (bin). However, it does not differentiate from the sibling 'move_items_to_bin' (plural) and 'move_clip' tools, 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 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 'move_items_to_bin' or 'move_clip'. No context about prerequisites or scenarios is 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 disclosing side effects, but it only states the action. It doesn't explain whether the removal is a ripple delete, whether it affects audio/video linked clips, whether it's undoable, or if there are safety confirmations. 'Expanded operation' is vague 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and easy to read but includes redundant padding ('Premiere Pro expanded operation') that doesn't earn its place. The core message could be conveyed in fewer words 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?
For a destructive operation, this description is under-specified. It fails to mention the scope (timeline vs project), ripple behavior, selection requirements, or undo possibilities. Given the lack of annotations and output schema, an agent would lack confidence in when and how to invoke 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 zero parameters, so there is no additional meaning to add beyond the schema. The baseline of 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 uses a specific verb 'remove' and resource 'selected clips,' making the core operation clear. However, it does not differentiate from sibling tools like remove_from_timeline or ripple_delete, and the phrase 'expanded operation' adds ambiguity rather than 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 ripple_delete, lift_selection, or remove_from_timeline. It also doesn't mention prerequisites (e.g., clips must be selected) or whether this operates on the timeline or project panel.
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 burden. It states 'Saves' but doesn't disclose what happens to the original project (copy vs. rename), whether the original is closed or replaced, or if there are any side effects like requiring a confirmed overwrite. This is a mutation with minimal 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that conveys the core action efficiently. No fluff or repetition—perfect length for the information provided.
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 only minimal parameter documentation. The description omits critical context like whether the original project is preserved, if the save operation replaces the current one, or what happens on errors. For a state-changing tool, this is insufficient.
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 descriptions for both parameters (name and location). The description matches the schema ('new name and location') but adds no extra meaning about constraints, formats, or edge cases. Baseline 3 is appropriate when schema fully documents the 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 ('Saves') and resource ('current project') with a clear outcome (new name and location). It distinguishes from siblings like save_project and export_as_project primarily through the 'new name and location' clause, though it doesn't explicitly contrast with save_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 on when to use this tool versus alternatives like save_project or export_as_project. The description doesn't mention prerequisites, typical scenarios, or when to prefer this over similar operations.
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. The description does not disclose side effects or technical requirements; the operation simply assert that it changes a setting, but no clues as to whether it requires the project, or whether it is reversible.
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?
Very concise, one sentence, but has a filler 'expanded operation' and 'Premiere Pro'— not harmful. It's 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?
The tool is a simple setter with no output schema; but the input schema implies key/value metadata without description. There are no details about where override can be used, pixel aspect ratio? clip? H mm. The compression/depth is not enough.
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?
Zero parameters, and schema coverage is 100%; however, the schema with propertyNames is weird because there are no positional parameters, and it accepts arbitrary additionalProperties. The description offers no explanation for that apparent schema shape. Baseline 3 due to high schema coverage.
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 has a specific verb+object ('set override pixel aspect ratio') and is contextually distinct; however it lacks the target context (clip/sequence/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 on when to use this vs alternatives; no exclusions or alternatives listed; the phrase 'expanded operation' is unclear.
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 is the only source of behavioral disclosure; it merely restates the operation without mentioning side effects, persistence, or dependencies. The write nature of 'set' is implied but not expanded.
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 prefix 'Premiere Pro expanded operation:' adds no value and the remaining text largely repeats the tool name. It is not overly verbose, but it does not use its brevity to deliver extra insight.
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 setter with no annotations and no output schema, the description is too thin: it does not say what value or path will be applied, what is required before calling, or what observable change occurs. A richer sentence is needed to make this usable.
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 indicates zero declared parameters, so there is little for the description to add to the schema. The permissive additionalProperties behavior is not explained, but the no-parameter 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 names a concrete action and resource ('set project scratch disk'), so the tool's objective is clear. It does not differentiate this from sibling set_scratch_disk_path, and 'expanded operation' is 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 about when to use this tool instead of related siblings such as set_scratch_disk_path or get_project_scratch_disks. No project-state or prerequisite context is 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?
No annotations are provided, so the description must carry the full burden. It indicates a mutation ('sets') but doesn't disclose any behavioral nuances such as whether this affects the timeline, whether it requires a sequence to be open, or if it clears previous settings. There is no mention of potential side effects or validation (e.g., inPoint must be less than outPoint). The description is extremely terse.
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 short, clear sentence that is front-loaded and efficient. There is no fluff, but it is so minimal that it could be considered under-specified, which is why it doesn't reach 5. It earns its place but doesn't add extra helpful 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 tool is a setter operation with no annotations and no output schema. Given the complexity (3 required params), the description should provide more context about the effect, any constraints (e.g., in/out ordering), and relation to sequence state. It is not complete enough for a mutation tool that potentially affects timeline data.
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 parameters with descriptions (100% coverage): sequenceId, inPoint, outPoint. The description adds no additional semantic value beyond what the schema provides. Since schema coverage is high, baseline of 3 is appropriate; the description doesn't compensate or enhance.
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 work area in/out points for a sequence' clearly states the action (sets) and the target resource (work area in/out points for a sequence). It distinguishes from siblings like 'clear_sequence_in_out' and 'set_sequence_in_out_points' by focusing on work area specifically, though it doesn't explicitly differentiate from 'set_sequence_in_out_points' which could be confused. The purpose is clear but not fully distinguishing from similar 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. For example, it doesn't clarify how this differs from 'set_sequence_in_out_points' or 'clear_sequence_in_out', nor does it mention any prerequisites like needing an active sequence. The description is minimal and provides 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.
- 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, but it only states the basic effect without details on side effects (e.g., duration changes, audio pitch impact) or reversibility. It does not mention that the operation modifies clip duration or that pitch can be preserved via a parameter. This leaves a significant 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no filler words. It is appropriately sized for a simple operation and front-loads the primary purpose. 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?
For a tool with no annotations or output schema, the description is too minimal to fully address operational context. It omits important aspects like the impact on audio (despite the maintainAudio parameter), the fact that speed changes affect clip duration, or any constraints on speed values. A user would need to infer these from the schema, which is incomplete without additional 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?
The input schema covers all parameters with clear descriptions (e.g., 'Speed multiplier (0.1 = 10% speed, 2.0 = 200% speed)'), giving a high schema coverage of 100%. The tool description adds no extra meaning beyond the schema, so it meets the baseline but does not exceed it. Examples or default values in the description would have elevated the 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 identifies the action ('Changes') and the target ('playback speed of a clip'), making it easy to understand what the tool does. It distinguishes the operation from similar tools like 'set_clip_speed_qe' by using the explicit phrase 'playback speed.' However, it could be slightly more specific about the context (e.g., timeline vs. source clip), preventing a perfect score.
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 or exclusions. The description is limited to a single declarative sentence, providing no explicit context about scenarios where this tool is preferable to others. No alternatives or when-not-to-use scenarios 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 must explain the mutation's side effects. It says 'splits a clip' but doesn't disclose whether the original clip is preserved, whether the timeline is modified, if it's undoable, or if there are side effects on the project (e.g., new clip created). For a destructive/edit operation, this is insufficient 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately states the action and key parameter. No fluff or redundancy. It could add a bit more context but is 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?
This is a destructive/mutating operation (splitting clips creates new clips and potentially removes the original), yet there are no annotations to indicate safety or side effects. The description doesn't mention whether the original clip is preserved, how the timeline is affected, or if there are any restrictions (e.g., clip must be in a sequence). Given no annotations and no output schema, the description should carry more weight, but it doesn't disclose these behaviors.
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 for both parameters (clipId and splitTime) with descriptive text. The description adds little beyond the schema, just reiterating 'at a specific time point,' which doesn't add meaningful new details. 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 verb (splits) and the resource (a clip) at a specific time point)SkipThe purpose is clear and distinguishes from sibling tools like 'trim_clip' or 'ripple_delete' which imply different operations. However, 'split' could be interpreted as creating two clips vs. cutting, but overall it's sufficiently 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 on when to use this tool versus alternatives like 'razor_all_tracks' or 'trim_clip'. It doesn't specify prerequisites (e.g., clip must be in timeline) or mention that this creates two separate clips with handles, which is useful context for an agent deciding between split and trim.
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 behavior, but it only states the action. It doesn't reveal what 'expanded' means, whether it modifies existing clips, requires a selection, or has side effects. The operational implications are entirely undisclosed.
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, front-loaded sentence with no filler. It is concise and easy to parse, though it could benefit from a few clarifying details without becoming verbose.
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 creating a sequence from clips (selection, arrangement, settings), the description is far too minimal. It does not explain what inputs are expected, how clips are chosen, or what the resulting sequence looks like. No annotations or output schema compensate for this 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?
Since there are zero parameters, the schema fully covers parameter semantics (there are none). The description doesn't need to add parameter details, so the baseline of 4 applies. It adds no unnecessary info but provides a basic scaffold.
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 'Premiere Pro expanded operation: create sequence from clips' clearly states the primary action (create sequence from clips). It uses a specific verb and resource, but the vague 'expanded operation' phrase and lack of distinction from sibling tools like 'create_sequence' and 'create_sequence_from_preset' prevent 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 instead of alternatives. It doesn't mention prerequisites, context (e.g., needing selected clips), or exclusions, despite the wide range of sibling creation 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?
There are no annotations, so the description must disclose side effects and context. It only labels itself 'expanded operation' and says it moves the playhead; it doesn't say whether it is read-only, whether it requires an active sequence, or how it chooses the edit point (next/previous/nearest).
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 operative phrase is clear, but the 'Premiere Pro expanded operation:' prefix is filler and does not add information. Still, it is front-loaded and not bloated.
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 zero-parameter tool, the description is the only specification of behavior, yet it leaves the meaning of 'edit' and the tool's operating context (active sequence, direction) ambiguous. A one-line phrase is not enough to confidently invoke the operation 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 imposes no parameter burden. The 0-parameter baseline applies; the description correctly contains no parameter syntax 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 concrete verb ('move') and identifies the resource ('playhead') and target ('edit'), giving a general sense of the operation. However, it never clarifies what 'edit' means (edit point, in/out point, selected cut), and it does not differentiate the tool from close siblings such as set_playhead_position or get_next_edit_point.
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 when-to-use, prerequisites, or exclusions are provided. It does not mention active sequence/selection or any alternative tools, so an agent cannot decide between this and set_playhead_position/match_frame.
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. 'Remove effect by name' doesn't explain whether this is destructive, applies to one effect or all with the same name, requires a selected clip, or works on the current sequence. This is minimal 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence and gets to the point quickly. However, the leading 'Premiere Pro expanded operation:' is boilerplate that adds no value and wastes 5 words—arguably padding that could be cut for greater 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 zero-parameter tool, the missing piece is how the 'name' is provided—workspace selection, active item, current selection? This is a meaningful gap that could confuse an agent. There's no mention of how this relates to 'remove_effect' or what happens with duplicate effect names. The tool is under-specified for its apparent capability.
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?
This is a zero-parameter tool, so the rubric sets a baseline of 4. Description isn't required to explain parameter details since there are none, and the name-based selection implies the effect name comes from context/state rather than 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 ('remove effect') and adds the key differentiator 'by name,' which distinguishes it from siblings like 'remove_effect' and 'remove_all_effects.' The phrase 'Premiere Pro expanded operation' is vague filler but doesn't obscure 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 on when to use this tool vs. the sibling tools 'remove_effect' or 'remove_all_effects.' The choice between these is left entirely to inference from the name, with no mention of scoping (selected clip, current sequence) 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?
With no annotations provided, the description carries full responsibility for disclosing side effects, scope (e.g., project panel vs timeline), and failure modes. 'Rename clip' is terse and leaves ambiguous what 'clip' refers to, whether it alters source files, or requires an active selection. No useful behavioral detail is added 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 extremely short and free of fluff. The phrase 'Premiere Pro expanded operation' adds a bit of noise and is not immediately informative, but the core 'rename clip' is front-loaded and efficient. It earns a 4 for conciseness, with slight deduction for the unnecessary prefix.
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 position among ~250 siblings and the absence of output schema or annotations, the description is inadequate for an agent to use it correctly. It fails to specify the operating context (e.g., selected clip, bin), behavior when no clip is selected, or relation to similar tools. A more complete description would clarify its unique use case relative to 'rename_project_item'.
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 confirms an empty property set. Per the rubric, 0 params yields a baseline of 4. The description does not need to explain parameters because none exist, though it might have clarified how the target clip is identified (e.g., via 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 'rename clip' clearly states the action (rename) and the resource (clip). It is specific enough for basic understanding, but does not differentiate from siblings like 'rename_project_item' or 'batch_rename_clips'—no distinguishing context is provided.
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. The sibling list includes 'rename_project_item', 'batch_rename_clips', and 'rename_track', but the description offers no criteria for choosing this tool over those. There is no mention of prerequisites, selection requirements, or scope.
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 full responsibility for disclosing behavioral traits. It only states the action, without explaining that selection is applied to the active timeline, whether the previous selection is replaced, or what happens if no sequence is active. This is a significant gap for a mutation-like 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 only one short line, making it efficient and front-loaded. However, 'expanded operation' is filler that adds no meaningful information; trimming it would make the sentence cleaner.
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 (0 params, no output schema), but the description lacks essential context about what scope 'all clips' refers to. Given the many sibling selection tools and the absence of annotations, the description is too minimal to fully guide an agent without guesswork.
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 zero parameters, so the schema imposes no burden. The description adds no parameter details because there are none to describe; baseline 4 is appropriate since the tool's operation is fully defined by its name and description.
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 and resource clearly: 'select all clips.' It differentiates from siblings like select_clips_by_name and select_clips_in_range by indicating a broad, unfiltered selection. The phrase 'expanded operation' adds ambiguity 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 for when to use this tool versus alternatives such as select_clips_by_name or select_disabled_clips. There is no mention of scope (e.g., active sequence vs. bin) or contextual prerequisites, leaving the agent to infer 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, the description must disclose behavioral traits on its own, but it only repeats the tool's name without explaining what 'color' refers to (label color, lumetri, etc.), whether it operates on the timeline or bin, or if a selection is required. It adds no behavioral 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words or filler. It is front-loaded and easy to scan, appropriate 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 there are no annotations or output schema, and the tool is one of many selection tools, the description is incomplete. It fails to explain what 'color' means, how the selection is performed, or any side effects. The lack of detail makes it insufficient for an agent to know how to invoke it correctly without further 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, so the baseline is 4. The description does not need to explain parameters, and it doesn't mislead. However, it also doesn't clarify how the color is determined (e.g., from selected clips or a property), which is not a parameter issue but a missing explanation.
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 ('select clips') and the specific criterion ('by color'), distinguishing it from sibling tools like select_clips_by_name and select_all_clips. The verb-resource pair is specific and unambiguous enough to convey the core function.
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, nor any exclusions or prerequisites. The description offers no context for when 'select by color' would be appropriate compared to other selection 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 disclosure. It only states the selection target and does not disclose whether the existing selection is replaced or added to, how 'disabled' clips are determined, or what conditions must be met for the operation to succeed.
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 readable in a single sentence. The phrase 'Premiere Pro expanded operation:' is filler that repeats domain context and adds little value, but the overall length is appropriately minimal.
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 selection-mutating operation with no annotations and no output schema, the description is too thin. It fails to explain selection semantics, prerequisites, or what 'disabled' means in context, especially given the large sibling list containing many selection-related 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 input schema fully covers inputs and the baseline for 0-parameter tools is appropriate. The description adds no parameter-specific detail, but none 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 uses a specific verb ('select') and a specific resource ('disabled clips'), making the operation's intent clear. However, the prefix 'Premiere Pro expanded operation' is vague and does not clarify what 'expanded' means, and it does not meaningfully differentiate from sibling selection tools beyond the target state.
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 select_all_clips, select_clips_in_range, or set_clip_selection. It does not mention whether an active sequence is required or how this selection relates to other selection 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?
The description reveals no behavioral details such as side effects, permissions required, or whether the operation is reversible. With no annotations to supplement, 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 with no redundant words. It is well-structured and directly to the point.
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 setter with no parameters, the description is moderately complete, but it lacks any context about when or why to use this tool, which may be important given the large set of sibling tools.
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?
The input schema has no parameters, so there is nothing for the description to explain. The description 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.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'set graphics white luminance'. It is specific and unambiguous about what the tool does, though it does not differentiate 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 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, nor any prerequisites or conditions. The description is a bare statement 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?
No annotations are present, so the description carries the full behavioral disclosure burden. It communicates that the operation 'sets' something but says nothing about whether it affects the active sequence, whether the change is reversible, or what preconditions are required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence and front-loads the operation without rambling. The phrase 'Premiere Pro expanded operation' is somewhat boilerplate, but it does not waste significant space.
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 omits important context such as what display format values are accepted, whether it applies to the active sequence, and how it relates to sequence settings. With no annotations and no output schema, this reads more like a stub than a complete tool 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?
With zero declared parameters, the description's lack of parameter detail is less problematic, matching the zero-parameter baseline. However, the schema's permissive additionalProperties and the absence of any statement about expected arguments leave slight 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 names a specific verb ('set') and resource ('sequence display format'), making the core action clear. It does not explicitly differentiate from broader setters like set_sequence_settings, but the target resource is distinctive enough to orient the agent.
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_sequence_settings or get_sequence_settings. The description simply restates the operation and provides no context for choosing it 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description does not state whether the keyframe creation is idempotent, what happens if a keyframe already exists at the given time (overwrite vs add), whether the clip must be on a track with keyframing enabled for the parameter, or what time format is expected. It also doesn't explain whether the component must already exist on the clip or if this creates it. This lack of behavioral detail is a significant gap for an editing operation that could have 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 a single concise sentence that communicates the core purpose without fluff. It is front-loaded with the action verb and clearly identifies the target. It could arguably be more detailed, but for its brevity it does not waste 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?
With 5 required parameters and no annotations or output schema, the description leaves important context unclear. It doesn't explain behavior like whether adding a keyframe at the same time overwrites an existing keyframe, whether the parameter must already have keyframing enabled, or what units/format the value uses beyond schema hints. The description is minimal and relies entirely on parameter names for meaning, offering no additional context about edge cases or expected usage patterns. For an operation with meaningful complexity (keyframes in animation), this is a real 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?
Schema description coverage is 100% – all 5 parameters have descriptions in the schema. The description adds minimal value beyond the schema: it clarifies that 'componentName' and 'paramName' refer to display names, which the schema already states. The description doesn't explain parameter semantics like value units, time format expectations, or the relationship between paramName and componentName, but the schema's coverage is strong so the description need not duplicate it. Baseline 3 is appropriate given the good schema coverage.
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 keyframe to a clip component parameter at a specific time.' It identifies the verb (adds), the object (keyframe), and the target (clip component parameter at a specific time). It is specific enough to distinguish from siblings like remove_keyframe_range and set_value_at_time, though it doesn't explicitly mention keyframe interpolation or easing which might be set elsewhere.
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 a clear sense of what the tool does but provides no guidance on when to use it versus alternatives like set_clip_position, set_clip_scale, or set_value_at_time. There is no mention of prerequisites (e.g., the clip must have a component with the named parameter), what happens if the parameter doesn't exist, or how this differs from setting a property without keyframing. Context is implied by the name and description 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only restates the operation and does not disclose whether both in and out are cleared, whether the action is undoable, whether it can be a no-op, or what the resulting sequence state is.
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 wastes little space, but the 'Premiere Pro expanded operation:' prefix is filler that does not add substantive meaning. There is no redundancy, yet the phrasing feels templated rather than intentionally structured.
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 zero-parameter clear operation, the description is minimally viable: an agent can infer the action from the tool name and sibling context. However, with no annotations and no output schema, the description leaves behavioral and contextual gaps that make it only barely 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 tool has zero parameters, so there is no parameter burden for the description to explain. 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 names a specific action ('clear') and resource ('sequence in out'), and the tool name reinforces the intent. It is distinguishable from siblings like set_sequence_in_out_points, get_sequence_in_out_points, and clear_item_in_out, though the phrase 'expanded operation' adds little and the effect could be stated more explicitly.
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 about when to use this tool versus set_sequence_in_out_points or get_sequence_in_out_points. There is no mention of whether it targets the active sequence, how it interacts with existing in/out points, or when this clear should be preferred.
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 'Premiere Pro expanded operation: copy effects between clips,' which adds little beyond the tool name. It does not reveal whether the copy is a full duplication, whether target effects are overwritten, or whether any permissions or sequence context are required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It communicates the core operation efficiently, and every word contributes to understanding the tool's 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 the tool has no parameters and no output schema, the description should provide essential context about how the operation works. It leaves ambiguity around what 'between clips' means (e.g., source/target selection), whether all effects are copied, and whether this replaces or appends effects on the destination clip. This is insufficient for an agent to invoke the tool reliably without further 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?
The tool has zero parameters, so the schema is trivially covered. Per guidelines, this scenario gets a baseline score of 4. The description does not need to explain parameter details, and it does not introduce any conflicting parameter information.
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: 'copy effects between clips.' This is a specific verb+resource combination that distinguishes it from sibling tools like apply_effect (which adds new effects) and copy_effect_values (which copies specific property values). However, it does not explicitly differentiate from these related operations, 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?
No usage guidance is provided. There is no mention of when to use this tool versus alternatives such as copy_effect_values, apply_effect, or batch_apply_effect. The description does not state prerequisites (e.g., selected source and target clips) or whether it replaces existing effects on the target clip.
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. The description only states the action and purpose but does not disclose side effects (e.g., whether the bin is created at the root or requires a parent), error conditions, or any constraints. For a creation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/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 purpose. It contains no fluff, but it could be slightly more informative without becoming verbose. It earns its place but doesn't go beyond the minimum.
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 (2 params, no output schema), the description is somewhat adequate, but it lacks context about the parent bin behavior, default location, or any prerequisites. With no annotations and no output schema, the description should provide more behavioral context to be 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 already documents both parameters (name and parentBinName). The description adds minimal value beyond the schema, only implying the bin is created in the project panel. The baseline of 3 is appropriate since the schema handles parameter 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 clearly states the tool creates a new bin (folder) in the project panel to organize media. It uses a specific verb ('creates') and resource ('bin'), and the parenthetical clarifies the domain. It doesn't explicitly distinguish from sibling tools like create_smart_bin or delete_bin, but the action is distinct enough.
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 (organizing media in the project panel) but does not explicitly state when to use this tool versus alternatives like create_smart_bin or import_folder. No exclusions or alternative tool mentions are provided, so the guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 merely states the action and omits details about side effects, state changes, prerequisites, or reversibility, offering minimal transparency beyond the action itself.
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 immediately states the purpose. Every word earns its place with no redundant information or fluff.
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, the schema fully documents inputs and the action is straightforward. However, given the lack of annotations and output schema, the description could have added context about expected results or prerequisites, leaving it only minimally 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 describes both parameters ('clipId' and 'enabled') completely, so the description adds no extra semantic value. Baseline 3 applies because the schema covers all parameter meaning.
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 with a specific action verb ('Enables or disables') and resource ('a clip on the timeline'). It is distinct from many sibling clip operations, though it doesn't explicitly differentiate itself from the similar batch_enable_disable 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?
The description provides no guidance on when to use this tool versus alternatives like batch_enable_disable or other clip mutations. It only states what it does without any context for 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?
No annotations are provided, so the description carries the full burden. It doesn't disclose any behavioral traits such as whether the export is blocking, whether it overwrites existing files, or any side effects. The description is minimal and doesn't add context beyond the basic 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 sentence, concise and to the point. It front-loads the purpose without unnecessary detail. It earns its place with no waste.
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 4 parameters and no output schema, the description is quite minimal. It doesn't explain the return value, error conditions, or any prerequisites like whether the sequence must be open. For a tool that writes a file, more context about file handling would be helpful.
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 all parameters. The description adds no additional meaning beyond what the schema provides. 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 exports a single frame from a sequence as an image file, which is specific and distinguishes it from related tools like capture_frame or export_sequence. However, it doesn't explicitly differentiate from capture_frame, which might be a sibling with similar functionality.
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 exporting a frame at a specific time, but it doesn't provide explicit guidance on when to use this tool versus alternatives like capture_frame or export_sequence. No exclusions or alternative tool mentions 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 provided, the description carries the full transparency burden but only states the core purpose. It fails to mention the dominant behavioral trait—that .epr presets control codec/quality/resolution—or any side effects/requirements of the render pipeline, which is a significant disclosure gap for a 10-parameter 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?
Two short sentences, front-loaded with the action verb. The only blemish is that "This is for creating the final video" largely restates "exports a sequence to a video file," a minor redundancy, but overall it remains tight.
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 complex tool with 10 parameters, no output schema, and many sibling export/encode/render tools, two sentences are insufficient. The description omits crucial context about preset resolution, blocking/long-running behavior, and how it relates to encode_project_item or add_to_render_queue, leaving the rich sibling list's distinctions unaddressed.
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?
With 100% schema description coverage, the baseline of 3 applies; the rich param docs in the schema handle semantics. The description adds no param-level meaning (and doesn't need to given the schema's thorough coverage of presets, deprecations, and overwrite behavior).
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?
"Renders and exports a sequence to a video file" provides a specific verb plus resource, and "creating the final video" implies finished output vs. the interchange/frame exports (export_as_fcp_xml, export_frame) among siblings. It's clear and differentiated at a high level, though it never explicitly names a sibling like encode_project_item to contrast against.
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?
"This is for creating the final video" implies intended use and subtly distinguishes from frame/XML exports, but there's no explicit guidance on when not to use this tool or which sibling to prefer (e.g., add_to_render_queue, encode_file). The usage context is only implied through the purpose statement, 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 provided, the full burden of behavioral disclosure falls on the description, and it only partially delivers. It confirms the operation is an import into the current project and enumerates supported types, but it doesn't state what happens on duplicate imports, whether bins are auto-created, what happens if the file doesn't exist, what is returned, or what prerequisites exist. For a file-system-mutating operation, these are meaningful omissions.
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 front-loaded sentence with the verb 'Imports' leading, followed by the object and destination. The '(video, audio, image)' parenthetical is efficient scope clarification with zero wasted words. Every element earns its place and the structure mirrors good writing practice — no fluff, no redundancy with the schema.
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 2-parameter tool with full schema coverage and no output schema, the description plus schema covers the what and where adequately — the schema documents both parameters well, and the description closes the question of scope and types. However, no annotations exist to cover behavioral risk, and the description is silent on error conditions, return values, and preconditions. It's the minimum viable description 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.
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 correctly 3; both filePath (absolute path) and binName (bin or root) carry complete JSON Schema descriptions. The description text adds no parameter-level meaning beyond the schema — it doesn't even hint that binName controls bin targeting — but since the schema is fully self-sufficient, the description's silence causes no information loss.
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 'imports' with a concrete resource 'a media file (video, audio, image)' and a destination scope ('into the current Premiere Pro project'), which is clear and well-scoped. However, differentiation from the massive sibling list of import_* tools (import_folder, import_sequences, import_mogrt, import_fcp_xml, import_edl, import_image_sequence) is only implicit via the file-type parenthetical; no explicit sibling is named for disambiguation, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 the many overlapping alternatives in the import_* family or when not to use it. There are no exclusions, no alternative tool names, and no mentions of prerequisites such as an open project, despite 'current' implying one is needed. The agent is given no framework for selecting among import_media, import_folder, import_sequences, import_image_sequence, or import_mogrt.
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 action without any side effects. It doesn't mention whether it requires an active sequence, whether it toggles playback, or what happens if no timeline is open. The phrase 'expanded operation' adds 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with no wasted words, but the phrase 'Premiere Pro expanded operation' is generic and could be omitted. It is front-loaded with the core verb and object, making it easy to scan.
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 simplicity (no params, no output schema), the description is minimally adequate, but it leaves ambiguity about preconditions and behavior. It doesn't state if it starts from current playhead or requires an active sequence, which could matter for agents deciding between play_timeline and play_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?
The tool has zero parameters and the input schema is empty, so there is nothing to explain. The instruction sets a baseline of 4 for 0-param tools, and the description doesn't need to add anything. It correctly stays silent on 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 tool plays the timeline, distinguishing it from sibling tools like play_source_monitor which targets the source monitor. It uses a specific verb (play) and resource (timeline), so it's not a tautology. However, it doesn't elaborate on the scope (e.g., from current playhead) beyond the action 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 vs alternatives such as play_source_monitor or stop_playback. The description doesn't mention prerequisites (e.g., an open sequence) or context like whether it starts or toggles playback. No exclusions or alternatives are noted.
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 and does not mention side effects, whether the original clip is removed, or if any settings are affected. For a mutation tool, this is a significant 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short, front-loaded sentence that efficiently conveys the core action with zero filler. It is appropriately concise 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?
The tool is relatively simple with three parameters and no output schema. The description provides the essential action and all params are covered by the schema, but it lacks behavioral context such as effects of replacement or required state of the timeline, and it does not clarify differences from similar 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 input schema covers 100% of parameters with descriptions, so baseline is 3. The description itself adds no additional parameter meaning beyond the schema, but the schema fully documents clipId, preserveEffects, and newProjectItemId.
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 'Replaces' and the resource 'clip on the timeline' with 'another media item', making the purpose specific. However, it does not differentiate from sibling tools like replace_clip_media or overwrite_clip, which could perform similar actions.
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 gives no context about prerequisites, such as needing a valid clipId or newProjectItemId, or when this operation is preferable to other timeline editing 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 'Sets the color label,' implying a write operation but nothing about side effects, error behavior, reversibility, or any required permissions. It is far too terse to convey behavioral nuances.
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, front-loaded sentence with zero waste. It is appropriately concise for a simple setter operation, though it could be slightly more descriptive without becoming verbose. The structure is clean and direct.
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 2 simple parameters, no output schema, and no annotations, the description fails to cover essential context. It does not explain what happens if the projectItemId is invalid, whether the operation is idempotent, or any prerequisites. The minimalism leaves significant gaps for an agent that might need to handle errors or edge cases.
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 for both parameters (colorIndex with a detailed enumeration and projectItemId with a clear purpose). The description adds no additional semantic context beyond what the schema already offers, 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 verb and resource: 'Sets the color label on a project item.' This is specific, directly distinguishes from siblings like get_color_label (retrieval) and set_color_value (likely a different property), and leaves no ambiguity about 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 on when to use this tool versus alternatives. It does not mention any preconditions, such as the need for the project item to exist, nor does it differentiate from related operations like get_color_label or select_clips_by_color. The description gives no context for appropriate usage.
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 says 'Sets' and lists the fields, but does not explain whether unspecified settings are preserved or reset, whether values must fall within a valid range, whether changes are reversible, or what happens when called with only the required projectItemId.
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. Every phrase contributes: the action, the resource type, the specific settings, and the target scope.
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 setter with full schema coverage, the description is minimally adequate. However, it lacks behavioral context around the effect on existing interpretation settings, which would help an agent reason about side effects when calling it.
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 three parameters with 100% coverage, so the baseline is 3. The description adds no new meaning beyond repeating the field names; it does not clarify units, accepted ranges, or how frameRate and pixelAspectRatio relate to each other.
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 'Sets' and clearly identifies the resource as 'footage interpretation settings' for 'a project item', naming the two fields involved. It is distinct from the read counterpart `get_footage_interpretation`, though it does not explicitly call out alternatives.
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 related sibling tools like `set_override_frame_rate`, `set_override_pixel_aspect_ratio`, or `set_sequence_frame_rate`. The description implies a context only through the phrase 'for a project item', but does not state exclusions or preferences.
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 behavioral traits. It only says 'sets a metadata value' but does not explain whether it overwrites an existing key, what happens if the key is invalid, whether the operation is reversible, or any error conditions. The mutation side effects are implied but not detailed, leaving the agent to guess.
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 uses the standard 'Sets [resource] on [object]' structure. It is front-loaded with the verb and resource, contains no filler, and earns its place. Ideal length for a simple setter.
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 simplicity of the tool (3 string params, no nested objects), the description is adequate but minimal. It does not mention how the metadata key is defined, whether values are limited to strings (though schema implies), or what the return value is (no output schema). With no annotations, the description could have provided more context about side effects or use cases, but the tool is straightforward enough that the current level might be marginally 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 input schema has 100% description coverage, so each parameter (key, value, projectItemId) is already documented. The description adds no additional meaning beyond that—it merely restates that it sets a value. Since the schema handles parameter documentation, a baseline score of 3 is appropriate; no extra context is provided.
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 (project metadata value on a project item). It is specific enough to distinguish from similar tools like get_metadata, but it does not explicitly differentiate from set_project_panel_metadata or add_custom_metadata_field, which also deal with metadata but in different contexts. The verb and resource are 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?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, whether keys must already exist, or how to obtain projectItemId. The description gives no indication of when this tool is appropriate or when another metadata-related tool (e.g., add_custom_metadata_field, set_project_panel_metadata) should be used instead.
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 'Adds a sequence' without revealing side effects like whether rendering starts immediately, if overwrites are allowed, or if it blocks execution. Key behaviors implied by schema parameters (startImmediately, allowOverwrite, removeOnCompletion) are not mentioned, leaving the agent unaware of default behaviors.
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 or redundancy. It is front-loaded and efficiently captures the core action without unnecessary details.
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 (8 parameters, integration with AME) and lack of output schema, the description is incomplete. It does not explain what happens after adding, how to monitor or cancel, or if there are dependencies on other tools. The minimal one-liner is insufficient for an agent to fully understand the operation's context and side effects.
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 all 8 parameters. The description adds no parameter-level meaning beyond the schema; it does not explain how parameters interact (e.g., presetName vs presetPath) or provide usage context. Baseline 3 is appropriate because the schema handles parameter rationale.
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 a sequence to the Adobe Media Encoder render queue.' It uses a specific verb and resource, distinguishing it from sibling tools like get_render_queue_status, export_sequence, or start_batch_encode by focusing on the queue addition.
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 export_sequence or encode_project_item. It does not mention prerequisites (e.g., having a sequence open, AME connection) or conditions for use, leaving the agent without context on choosing this over similar 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 must carry full transparency burden. It describes adding a transition which modifies the timeline between two clips, but does not disclose potential effects such as whether it replaces an existing transition, whether both clips need to be selected, or any timeline restriction.
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 directly states the action, object, and position; no repetition or filler; 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?
All four required parameters are specified with types and descriptions, covering fully the inputs for the operation. No output schema exists, but the description's expected timeline modification is clear enough; not penalizing heavily.
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% and each parameter includes a clear description (IDs, duration in seconds, and transition name). Description adds no additional semantics beyond the schema for transitionName (example Cross Dissolve). Baseline 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?
Description states a specific verb ('Adds') and resource ('transition') and identifies the location ('between two adjacent clips on the timeline'), fairly distinguishing this from sibling tools that list available transitions. However, it doesn't explicitly name alternatives when a specific transition is unavailable.
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 implies when this tool is used (adding a transition between adjacent clips) but lacks explicit alternatives or exclusion guidance, such as checking available transitions first via list_available_transitions.
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 states the action without addressing reversibility, impact on existing color grading, default intensity, or required permissions. 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?
A single, front-loaded sentence that is immediately clear. No repetition or 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?
For a simple operation, the description is minimal but lacks important context such as whether the LUT replaces existing color adjustments, the default intensity if omitted, and any side effects. No output schema exists, so the description should have provided more behavioral detail.
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 parameter descriptions (clipId, lutPath, intensity). The description adds no extra meaning 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 a specific verb ('Applies') and resource ('Look-Up Table (LUT) to a clip'), with a clear purpose ('for color grading'). It distinguishes itself from broader siblings like 'color_correct' by naming the exact 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 on when to use this tool versus alternatives such as 'color_correct' or 'apply_effect'. The description does not provide context about suitable scenarios, 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 disclosing behavior. It mentions AI-powered motion tracking but does not clarify whether the original sequence is modified or a new sequence is created (the optional newName parameter suggests a copy, but this is not stated). There is no mention of permissions, side effects, reversibility, or what happens to the original. The description is too shallow to convey the operational behavior of the 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 front-loads the essential action. There is no redundant phrasing or filler. Every word contributes to explaining the tool's purpose, making it highly concise and efficiently 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 complexity (5 parameters, AI operation, no output schema, no annotations), the description is severely incomplete. It fails to explain the output format, whether the operation is destructive, what the motionPreset options imply, or any prerequisites (e.g., valid sequence ID). The lack of an output schema makes the description's silence on return values especially problematic. The tool requires richer context 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.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so every parameter is documented in the input schema. The description adds no additional parameter context beyond what is already in the schema. Per the rubric, when schema coverage is high, a baseline of 3 is appropriate. The description does not enrich the meaning of any parameter, but it does not need to because the schema already provides adequate 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 action (reframes a sequence), the target resource (sequence), and the specific purpose (new aspect ratio) with the method (AI-powered motion tracking). This distinguishes it from the many other sequence-related tools in the sibling list. The verb and object are explicit, and 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 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, no prerequisites, and no exclusions. It simply states what it does without any context on appropriate scenarios or what to check before invoking. There is no mention of alternatives or when not to use it, 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.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fails to disclose key behavioral aspects such as whether the tool imports media, creates a new sequence, or modifies the project. It only explains the purpose and the optional polish philosophy, leaving side effects and requirements unstated. No contradictions with annotations since none 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?
Two sentences, front-loaded purpose, and no redundant filler. Both sentences earn their 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 (12 parameters, nested clipPlan structure) and absence of annotations/output schema, the description is too brief. It doesn't explain what a successful build looks like, whether the project is mutated, or how missing assets are handled.
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%, and the description does not add any parameter-specific guidance beyond mentioning clipPlan control and MOGRT overlay. It repeats concept names already present in the schema, so it stays at the baseline for 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 builds a branded ad assembly from real media assets, with optional MOGRT overlay and explicit clipPlan control. This distinguishes it from sibling tools like assemble_product_spot by highlighting unique features, though it doesn't explicitly name alternatives.
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 building a branded ad with optional MOGRT or when explicit clipPlan control is desired, but it neither explicitly states when to choose this tool over alternatives like assemble_product_spot nor provides 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?
With no annotations provided, the description must fully disclose behavioral traits. It only states the action without mentioning side effects, permissions, return value, or what happens to the original item. It does not indicate whether the operation is reversible or any special constraints. This is minimal transparency beyond the action itself.
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, concise and to the point. It conveys the essential purpose without any redundant or filler content. Every word serves a 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?
For a creation tool with 7 parameters (4 required) and no output schema or annotations, the description is thin. It does not explain return values, error conditions, prerequisites like valid project item, or implications of optional parameters. The overall context is under-specified for an agent to fully understand the tool's behavior and potential side effects.
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 the schema already documents all 7 parameters. The description adds a slight semantic layer by stating 'with specified in/out points,' which clarifies the role of startTime and endTime. However, it does not elaborate on optional parameters like takeAudio, takeVideo, or hasHardBoundaries, which are only described in the schema. Since coverage is high, 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's function: 'Creates a subclip from a project item with specified in/out points.' It uses a specific verb ('creates') and resource ('subclip'), and distinguishes itself from siblings like create_subsequence and set_item_in_out by specifying the output is a subclip and the input is a project item with 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 Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. It does not mention scenarios or exclusions. The description implies usage through context (creating a subclip) but does not differentiate from create_subsequence or other related tools. Lack of alternatives or conditional criteria leaves the agent without clear 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?
No annotations exist, so the description bears full burden. It fails to disclose side effects such as permanence, impacts on sequences, or undo options. The phrase 'expanded operation' is vague and does not explain behavior beyond the basic 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 concise sentence with no redundancy. It conveys the essential verb and object 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?
The description lacks critical context for a destructive operation. It does not clarify what 'multiple project items' entails, how they are selected, or any consequences. No output schema is provided, but the description does not compensate for the minimal information.
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 empty, so there are no parameters to describe. The description adds no parameter-related meaning, and the baseline for high schema coverage (or absence of parameters) is 3. No contradiction or additional value is provided.
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 (delete) and the resource (project items) with scope (multiple). It distinguishes from related tools like 'delete_project_item' (singular) and 'delete_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. It does not mention batch scenarios, prerequisites, or comparisons with like operations (e.g., delete_project_item).
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 detailing side effects (e.g., irreversibility, impact on media files, or whether undo is possible). The short sentence adds little beyond the tool's name and does not clarify safety or consequences.
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 core functionality without verbosity. It is efficiently structured and front-loaded with the main verb and object.
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 simplicity of the tool, the description is too bare. It does not mention whether deletion is permanent, whether it affects underlying media files, or any prerequisites (e.g., sequence must exist). Given the lack of annotations and output schema, this minimal description leaves important operational details ambiguous 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 input schema fully covers the single parameter 'sequenceId' with a description, so the schema provides the necessary semantics. The tool description adds no additional parameter-oriented information, but the schema coverage meets the baseline, resulting in a score 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 clearly states the action ('Deletes') and the resource ('a sequence from the project'). It is specific enough to distinguish from sibling tools like delete_track or delete_project_item, which target different entities.
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 delete_project_item or delete_track. It does not mention conditions, exclusions, or prerequisites, 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 the full burden of disclosing behavior. It only says 'deselect all clips' without mentioning whether this affects only the active sequence, all sequences, or the current selection context. There is no indication of whether the operation is reversible, if it requires specific permissions, or if it has any side effects on other project state. This is minimal 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 with no filler or redundancy. It is front-loaded and immediately communicates the core action. For a tool with no parameters and a straightforward operation, this level of conciseness is appropriate 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?
Given the simplicity of the tool (no parameters, no output schema), the description is minimally sufficient. However, it lacks any context about the scope of the operation (e.g., active sequence vs. whole project) and does not mention potential side effects or related operations. The phrase 'expanded operation' hints at being part of a larger set but does not explain. Overall, 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.
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's parameter coverage is 100% (vacuously true), and the description adds no parameter information beyond what the input schema already indicates (empty object). No additional meaning is 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.
Purpose4/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. It identifies the resource (clips) and the operation (deselect all). However, it does not differentiate from sibling tools like select_all_clips or select_clips_by_name, which are related but opposite operations. The phrase 'expanded operation' is vague and does not add 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 select_all_clips or invert_selection. The description does not mention any prerequisites, side effects, or typical use cases. It merely states what it does without context, leaving the agent to infer when it might be 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 carries the full burden. It only states the basic purpose and includes default values in the schema, but does not disclose side effects (e.g., whether it overwrites existing files, whether it requires specific sequence states, or whether it affects the current project state). The description adds little beyond the schema's parameter defaults.
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, clear sentence that conveys the core purpose efficiently. It is appropriately sized and front-loaded with the key information. 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 that this is a straightforward export tool with a complete schema (100% coverage) and no output schema, the description is minimally adequate. It tells the agent what it does, but lacks details about potential prerequisites (e.g., must the sequence be open? what happens on failure?) and does not mention any limitations. It is complete for basic use but not thorough for a tool with 6 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?
Schema description coverage is 100%, so parameters are well-documented in the schema. The description adds no additional parameter semantics beyond what the schema provides. Baseline 3 is appropriate; it doesn't compensate for anything but also doesn't need to.
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 exports a sequence as an AAF file for interchange with other editing/audio applications. It identifies the verb (export), the resource (sequence), and the output format (AAF). It distinguishes from siblings like export_as_fcp_xml and export_omf because it specifically mentions AAF, though it doesn't name those alternatives explicitly.
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 this tool (when needing AAF interchange) but does not explicitly contrast with similar export tools like export_omf or export_as_fcp_xml. There are no exclusions or alternative suggestions, so it's adequate but lacks explicit 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 provided, the description carries full responsibility for behavioral disclosure. It simply states the export action but does not reveal important behaviors such as whether existing files are overwritten, required permissions, FCP XML version compatibility, or what happens on failure. This lack of detail leaves 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 sentence with the verb placed first ('Exports') and no unnecessary words. It is as concise as possible while conveying the essential 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 that there are no annotations and no output schema, the description is too minimal to be contextually complete. It does not mention return values, overwrite behavior, error handling, or FCP XML version details, which are relevant for an export operation. The parameter schema helps but is insufficient to fully understand the tool's 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?
The input schema already provides complete descriptions for both parameters (sequenceId and outputPath), achieving 100% coverage. The tool description adds no extra semantic meaning beyond what the schema offers, 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 action: 'Exports a sequence as Final Cut Pro XML.' The verb 'Exports' and the resource 'sequence' explicitly define the tool's purpose, and the format 'Final Cut Pro XML' distinguishes it from sibling export tools like export_aaf, export_omf, and 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 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 comparing with AAF/OMF exports, import functionality, or any preconditions. The only implied usage is from the format name, but no explicit context or exclusions 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 provided, the description carries the full burden of behavioral disclosure. It indicates a read operation ('Gets') but doesn't mention return format, what happens when no clip exists at the position, error handling, or any side effects. This is a minimal but incomplete disclosure for a tool with no supplementary metadata.
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, front-loaded sentence with zero wasted words. It effectively communicates the core functionality without redundancies.
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 minimal description leaves significant gaps. It doesn't explain the return value structure, null behavior, or how it relates to the broader timeline context (e.g., selected track vs specified track). More detail is needed for an agent to use this reliably without additional queries.
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 description coverage is 100%, so the baseline is 3. The description 'at a specific time position on a track' loosely maps to the time, trackType, and trackIndex parameters but adds no new information beyond what 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 clearly states the action (gets), the resource (clip), and the scope (at a specific time position on a track). It distinguishes itself from sibling tool get_clip_at_playhead by explicitly mentioning 'specific time position' rather than relying on playhead 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 like get_clip_at_playhead, get_playhead_position, or timeline inspection tools. The description implies usage context but gives no explicit when-to-use 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 of behavioral disclosure. The verb 'Gets' implies a read-only operation, but the description does not state return shape, ordering, interpolation details, or behavior when no keyframes 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?
A single, front-loaded sentence with no filler. Every word contributes to the meaning, making it an appropriately concise definition.
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 clarify what 'gets all keyframes' returns (e.g., list of keyframe times/values). It also does not explain the clip-component-parameter relationship or edge cases, leaving the agent under-informed.
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%, and property descriptions already define clipId, componentName, and paramName. The description adds the relational context that keyframes belong to a parameter within a clip component, which is marginal value 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') with a clear resource ('all keyframes') and target scope ('for a clip component parameter'). This clearly distinguishes it from sibling keyframe tools like add_keyframe or remove_keyframe.
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, get_effect_properties, or get_keyframe_interpolation. The context is implied but no exclusions or alternative tool names 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?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'Gets comprehensive information' but does not specify whether the operation is read-only, if it might be slow, or what happens if no project is open. It lacks transparency about side effects or edge cases.
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, direct sentence that efficiently conveys the tool's purpose. There is no unnecessary wording, and the core information is front-loaded.
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 parameters and no output schema, the description is adequate for a simple read operation. However, it does not elaborate on what 'settings' and 'status' include, and it does not clarify the scope (e.g., active project only). With many similar sibling tools, a bit more context would improve usability.
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 instructions the baseline is 4. The schema is empty, so there is nothing to compensate for. The description adds minimal value here since 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 action (gets) and resource (current project), and specifies the information returned (name, path, settings, status). However, it does not differentiate from similar siblings like get_full_project_overview or get_premiere_state, which could cause 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 the many similar information-retrieval siblings. The description states what it does but not when it is the preferred choice, nor does it mention exclusions or prerequisites (e.g., requiring an open project).
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 disclose side effects but only states 'imports,' which implies a mutation. It does not mention whether existing clips are shifted, if the template replaces anything, or failure modes. Minimal 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, focused sentence with no redundant information. It is front-loaded with the core action and destination, making it perfectly concise for a simple import 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?
For a tool that modifies a sequence, the description lacks crucial behavioral context (e.g., track placement behavior, effect on existing clips, error handling). No output schema or annotations exist to compensate. It is too sparse 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 coverage is 100% with clear parameter descriptions. The description adds no extra meaning beyond the schema, so a baseline score of 3 is appropriate—adequate but not enriching.
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 ('.mogrt file'), and the destination ('into a sequence'). It distinguishes from the sibling tool 'import_mogrt_from_library' by specifying file path import, 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?
No guidance on when to use this tool versus alternatives like 'import_mogrt_from_library' or 'import_media'. It lacks preconditions (e.g., open sequence, track availability) and exclusion criteria, leaving usage context unclear.
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 merely repeats the basic functionality without mentioning side effects, prerequisites (e.g., open sequence), required permissions, or what happens to the sequence after import. The description does not disclose whether this is a mutating operation or what the outcome 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 11 words, making it extremely concise and front-loaded. There is no redundant information or 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?
Despite having 6 parameters (4 required), no output schema, and no annotations, the description is minimal. It does not explain return values, error behavior, or typical usage context. For a tool with moderate complexity, this is insufficient for an agent to invoke it correctly without additional inference.
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% coverage, providing descriptions for all 6 parameters. The description adds no additional meaning beyond that, which meets the baseline but does not enhance parameter 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 clearly states the specific action ('Imports a Motion Graphics Template') and the resource ('from a Creative Cloud Library'), which distinguishes it from the sibling tool 'import_mogrt' that likely handles local file imports. This is a specific verb+resource pairing with clear 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?
The description offers no explicit guidance on when to use this tool versus alternatives. It does not mention the sibling 'import_mogrt' or clarify that this is the correct choice for CC Library imports specifically. Usage is only implied by the tool's name and description.
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 behavioral details are provided beyond the basic function, such as whether it is read-only, requires permissions, or has 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 concise sentence with no 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?
For a simple listing tool, the description adequately conveys the purpose, though it does not specify the return format or any prerequisites.
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 add parameter semantics; 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.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all available audio transitions in Premiere Pro, which is specific and distinguishes it from other list tools such as list_available_audio_effects.
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, or any context for its application.
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 must disclose side effects and safety. It does not mention whether attaching a proxy modifies the project item, whether the operation is reversible, or any error or permission considerations. Only the action names are given, leaving behavioral characteristics undefined.
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, compact sentence that directly lists the capabilities. It is front-loaded and contains no filler or redundant 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?
The tool is a multi-action mutation endpoint (attach modifies state) with no output schema and no annotations. The description fails to explain what each action returns, prerequisite conditions, or possible side effects. Such minimal coverage is inadequate given the 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 input schema already provides descriptions for all three parameters, including the special condition for proxyPath. The tool description adds no additional semantic meaning beyond what the schema states, so it meets the baseline of 3 but does not enhance 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 explicitly states the three actions (check, attach, get_path) and the target resource (project item). It uses specific verbs and distinguishes the tool's scope from other proxy-related tools like has_proxy and detach_proxy by covering all three 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?
No guidance is provided on when to use this tool versus alternative proxy tools (has_proxy, detach_proxy) or how to choose among the three actions. The description only lists capabilities without contextual hints about 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?
With no annotations provided, the description carries the full burden. It mentions 'offline or moved media file' but does not disclose potential side effects, such as whether the operation modifies project metadata permanently, requires certain permissions, or if it can affect multiple clips. The description adds minimal behavioral context beyond the action itself.
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 that gets straight to the point. It is front-loaded and avoids unnecessary details, making it easy for an agent to parse quickly. However, it could benefit from a bit more context without losing brevity.
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 only two required parameters and a high schema coverage, the description is mostly sufficient. However, since there are no annotations or output schema, the description could have explained what the operation does in terms of return values or success/failure behavior. Given the simplicity, it is adequate but not exceptional.
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 itself does not add additional meaning beyond what the schema provides; it just says 'Relinks... to a new file path,' which aligns with the parameter names and descriptions. 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 verb 'Relinks' and the resource 'offline or moved media file' to a new file path. It distinguishes from sibling tools like 'refresh_media' and 'link_selection' by specifying the action of relinking to a new path, though it doesn't explicitly name alternatives.
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 a media file is offline or moved, providing context. However, it doesn't explicitly state when not to use it or mention alternatives like 'refresh_media' or 'check_offline_media' for handling offline media, leaving room for ambiguity.
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 only states the operation without disclosing any behavioral traits like whether it affects aspect ratio, whether it is destructive, or if it requires a selected clip. This is insufficient for an agent to understand 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 concise sentence with no filler. It is front-loaded with the core action and is appropriately sized for the simplicity of 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?
For a zero-parameter, no-annotation tool, the description is minimal but misses essential context such as what the operation applies to (e.g., selected clip, sequence) and any prerequisites. Given the sibling tools, this ambiguity could confuse an agent about the target object.
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 to explain. The schema coverage is 100% (no properties). Per the instruction, the baseline for 0 params is 4, as no additional 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 clearly states the operation: 'set scale to frame size.' It uses a specific verb and resource, distinguishing it from generic scale tools like set_clip_scale. However, it does not explicitly mention what object it applies to (e.g., selected clip), but the intent is clear from 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 provided on when to use this tool versus alternatives such as set_clip_scale or set_scale_width_height. The description only states the action without any context on prerequisites, selection 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.
- 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 restates the action ('Performs an undo operation') without explaining scope, side effects, whether it is destructive, or how many steps it undoes. 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, front-loaded sentence with no filler or redundant information. It is appropriately concise for a zero-parameter 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?
For a zero-parameter tool with no output schema, the description is minimally adequate but lacks behavioral context such as whether undo works one step at a time or what happens when there is nothing to undo. It is complete enough for basic invocation but not fully informative.
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 an empty input schema, so there is nothing for the description to document. The baseline score of 4 applies because no parameter information 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 tool performs an undo operation in Premiere Pro, using a specific verb and resource. However, it does not explicitly differentiate itself from sibling tools like redo or multiple_undo, 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?
The description provides no guidance on when to use undo versus redo or multiple_undo, and it mentions no exclusions or alternative recommendations. The usage context is only implied by the tool name and the phrase 'performs an undo operation.'
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. While it mentions that the sequence need not be active, it does not disclose potential side effects, whether the marker replaces existing markers, what happens with invalid input, or whether the operation is undoable. For a mutating operation, this lack of behavioral context 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, comprising two short sentences that convey the primary purpose and a key usage detail. There is zero wasted text, and the most important information (what the tool does) is presented first.
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 a simple mutation with a well-documented schema (100% coverage), no output schema, and no nested objects. The description communicates the core operation and the non-active-sequence flexibility. However, for a mutating tool with no annotations, the lack of response/return value behavior and edge-case handling makes it slightly under-specified, though it remains adequate for a straightforward 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 has 100% description coverage, so the schema already documents all parameters thoroughly. The description adds no parameter-specific information beyond the schema. Per the rubric, with high schema coverage, 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's function: 'Adds a marker to the specified sequence for navigation or notes.' It uses a specific verb ('adds'), identifies the resource ('marker' and 'sequence'), and mentions the purpose ('for navigation or notes'). This distinguishes it from siblings like delete_marker, update_marker, list_markers, and add_marker_to_project_item, though it doesn't explicitly name these alternatives.
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 notes that 'The sequence does not have to be the active one,' which is a useful usage hint. However, it does not provide explicit guidance on when to use this tool versus alternatives like add_marker_to_project_item or set_sequence_markers, nor does it mention any prerequisites or restrictions beyond the sequence not needing to be active.
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 only adds that the sequence need not be active; it does not state that deletion is irreversible, whether permissions are needed, what happens if the marker does not exist, or whether the marker is a sequence marker rather than a clip/project marker. 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core purpose and includes one valuable clarifying detail. Every word contributes meaning and there is 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?
The tool is simple, has only two fully described parameters, and no output schema, so the description does not need to explain return values. However, for a delete operation with no annotations, it would benefit from stating whether the deletion is permanent or undoable and clarifying that it applies to sequence markers. 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?
The input schema provides complete descriptions for both required parameters, including the meaning of sequenceId and markerId. The tool description adds no parameter-level detail 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.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the verb ('Deletes') and resource ('a marker from the specified sequence'), and adds a useful scope clarification that the sequence need not be active. However, it does not explicitly distinguish sequence markers from clip markers or project-item markers, and sibling tools like list_markers or update_marker are not referenced.
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 'The sequence does not have to be the active one' provides some context for when this tool can be used, implying it accepts any valid sequence ID. There is no explicit guidance on when to prefer this over alternatives or when not to use it, so usage direction remains mostly 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 provided, the description must carry the burden of disclosing behavior. It states it 'searches' but does not mention whether it returns multiple matches, the return format, or any non-destructive guarantee. The schema already mentions case-insensitive partial matching, so the description adds little 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, two sentences, and directly conveys the tool's purpose with no redundant or filler content. It is front-loaded with the main action and then adds a practical usage note.
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 low-complexity search tool with two well-described parameters and no output schema, the description provides a minimal but acceptable picture. It could improve by mentioning that multiple matches may be returned or how results are structured, but given the simple nature, it is adequate though 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 schema covers 100% of parameters with descriptions ('The name to search for (case-insensitive partial match)' and 'Filter by item type'), so the baseline is 3. The description's mention of 'media files, sequences, or bins' loosely hints at the 'type' parameter but does not add explicit semantic detail 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 searches for project items by name, which is a specific verb and resource. It also lists example item types (media files, sequences, bins), adding useful context. However, it does not explicitly differentiate from sibling tools like 'search_project_items' or 'find_items_by_media_path', though the focus on name is distinct.
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 says it is 'useful for finding media files, sequences, or bins,' which implies a common use case but does not provide explicit guidance on when to choose this tool over alternatives. No exclusions or alternative tool references are given, so it falls short of strong usage 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 provided, the description carries the full burden of behavioral disclosure. It correctly implies a read-only operation via 'gets', but gives no details about return format, potential failure modes, or how the two metadata types are combined. This is adequate but minimal for a simple getter.
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 every word earning its place. It is appropriately concise 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?
This is a low-complexity tool with one well-documented parameter, but the absence of an output schema and annotations means the description should clarify what 'project metadata' and 'XMP metadata' mean in practical terms and what the caller receives. It does not, and it leaves ambiguity against similarly named sibling 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 coverage is 100% for the single parameter, and its description ('The ID of the project item') already conveys the meaning. The tool description only restates this concept ('for a project item') without adding format, scope, or usage details, so it adds no value 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 gets two specific types of metadata for a project item, using a concrete verb and resource. However, it does not differentiate itself from sibling tools like get_xmp_metadata or get_project_item_info, which likely overlap in functionality.
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 get_xmp_metadata, get_project_item_info, or get_xmp_metadata. There is no mention of 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The phrase 'Gets the settings' implies a safe read operation, and the parenthetical examples hint at what the response contains. However, with no annotations, the description fails to disclose whether all settings are returned or only explicitly set ones, and it offers no error or edge-case context. It is not misleading, but it adds only minimal 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no filler; every word contributes value. The parenthetical examples are helpful and do not inflate the length.
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?
This is nearly complete for a one-parameter getter with a fully documented schema. However, the vague 'etc.' and lack of specification about whether settings are defaults or only explicitly set values leave some ambiguity, especially given the existence of overlapping siblings like get_sequence_structure.
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 documents sequenceId ('The ID of the sequence') and schema coverage is 100%, so the baseline of 3 applies. The description adds nothing beyond what the schema already conveys, but it also doesn't need to, given the parameter is self-explanatory.
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 ('Gets') and identifies the resource ('settings for a sequence') with clear examples ('resolution, framerate'), which makes the tool's purpose obvious. However, it does not explicitly contrast with similar getters like get_sequence_structure or get_full_sequence_info, so it doesn't earn 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?
No when-to-use guidance, prerequisites, or alternatives are provided. An agent cannot easily distinguish this tool from siblings such as get_sequence_structure or get_sequence_in_out_points based on the description alone; it only restates the operation without adding 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?
No annotations are provided, and the description does not disclose behavior such as read-only access, failure scenarios, or return count semantics; the description simply restates the tool's 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?
Single one-line description with no filler; every word carries weight.
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 count operation, the context is sufficient even without an output schema or richer behavioral detail, though return type is left implicit.
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's 'propertyNames' oddity is irrelevant; there is no parameter uncertainty and no need for description compensation.
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 states 'Premiere Pro expanded operation: get total clip count' with a specific verb (get) and resource (total clip count), but does not differentiate from sibling tools and uses the vague phrase 'expanded 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 given on when to choose this tool over list/get_clip_count alternatives; no exclusions or recommended contexts.
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 'Imports sequences'. It does not mention whether this is a destructive action, if it overwrites existing sequences, requires the source project to be open or closed, or if it links or copies the sequences. For a mutation tool, this lack of safety or side-effect information 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with zero wasted words. It fully fits the purpose and is front-loaded with the key verb and resource, making it efficient for an agent to quickly understand.
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 simplicity of the tool (2 params, clear schema, no output schema), the description is minimal but covers the essential action. However, the lack of behavioral transparency (e.g., side effects, prerequisites) means the agent may not fully understand the consequences of invoking it, leaving the description only partially 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% (both projectPath and sequenceIds have descriptions), so the baseline is 3. The description adds no extra context, such as how to obtain sequence IDs (e.g., via list_sequences) or the expected format of the project path, so it does not improve upon the schema. It is merely adequate.
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 (imports) and the target (sequences from another project file), making its purpose unambiguous. It distinguishes itself from sibling tools like import_media or import_fcp_xml by specifying 'from another Premiere Pro project file', though it does not elaborate on the scope or side effects.
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 it (when needing to bring sequences from an external .prproj file) but does not explicitly mention alternatives or when not to use it. There is a sibling tool 'import_sequences' that could be confused with this one, and no guidance is given to differentiate them, leaving the agent to infer 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It confirms the read-only, listing nature and names returned fields, but it's vague about 'basic properties' and omits edge-case behavior (empty project, no open document, performance on large projects).
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, front-loaded sentence with zero filler words. It states the action, scope, and result in one concise breath.
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 0-parameter listing tool, the description covers the essentials: scope ('all sequences in current project') and return shape (IDs, names, basic properties). The primary gap is the undefined 'basic properties' term, which matters more because there's no output schema to compensate.
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, the schema carries no semantics, so per the rubric the baseline is 4. The description appropriately spends its space explaining the return value instead, which is the only useful thing it could add.
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-scope structure ('Lists all sequences in the current Premiere Pro project') and specifies the return payload (IDs, names, basic properties). It distinguishes itself from list_project_items naturally, though 'basic properties' is undefined and it doesn't explicitly disambiguate from get_sequence_structure/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?
No guidance is given on when to use this tool vs. the many siblings such as list_sequence_tracks, get_full_sequence_info, or get_sequence_structure. There are no exclusions, prerequisites, or alternative suggestions — a missed opportunity given the crowded sibling space.
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. It states the action but omits important context such as reversibility, effect on playback, interaction with clip-level mute settings, or whether any permissions or sequence state are required. It does not contradict annotations since none exist, but it provides minimal 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is direct and to the point, with no filler. It effectively front-loads the purpose and 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.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool with a clear action and well-documented parameters, the description is adequate but lacks additional context such as the effect on the timeline (e.g., whether it applies to all clips, interaction with solo states), or the expected return value. Given no output schema and no annotations, a bit more explanation would improve completeness, but it is not severely deficient.
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 description coverage is 100%, with each parameter already described clearly. The tool description adds no additional meaning or usage nuances beyond what the schema provides. This meets the baseline for high schema coverage, but no extra value is added.
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 ('Mutes or unmutes') and the target resource ('an entire audio track'), with sufficient specificity to distinguish it from sibling tools like set_clip_volume or lock_track. It also implies the scope (whole track, not individual 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 alternatives like set_clip_volume or adjust_audio_levels, nor any prerequisites or exclusions. The description only states what it does, not when it should be the chosen 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, so the description carries the full burden. It simply says 'play source monitor' without disclosing behavioral aspects: Does it start playback toggling or just initiate? Does it require an open source clip? Does it affect the playhead position? No mention of side effects, preconditions, or what actions it performs beyond the verb 'play'.
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: 'Premiere Pro expanded operation: play source monitor.' It front-loads the product context and states the verb. While sparse, it is not verbose or wasteful. However, given the lack of additional content, it might border on under-specification, but for a zero-parameter tool, this is acceptable.
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, no annotations, and no parameters, so the description is the sole source of context. For a playback operation, an agent needs to know whether this toggles playback or initializes it, and whether it requires an active source monitor. The description fails to provide this context that would be found in richer sibling descriptions like get_source_monitor_info.
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 there is nothing to add. The description correctly indicates no parameters are needed for this action, which is sufficient. A baseline 4 is appropriate given the tool requires no input.
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: 'play source monitor' in Premiere Pro. It identifies the tool as an expanded operation for playing the source monitor, which aligns with sibling tools like play_timeline and get_source_monitor_info. However, it could better distinguish itself from similar playback tools by specifying what 'source monitor' means in this context.
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 tool implies usage context (playing the source monitor), but lacks explicit guidance on when to use it versus alternatives like play_timeline or stop_playback. No when-not-to-use or alternative tool references are provided, which would help an agent choose correctly among the many sibling playback controls.
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 only says 'Sets Motion properties' – a terse mutation statement. It does not mention side effects, prerequisites (e.g., clip must exist), reversibility, or any special handling like coordinate conversion (which is only in the schema, not description). 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, front-loaded with the action and resource, and contains zero filler. Every word 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?
For a setter with comprehensive schema and no output schema, the description is adequate but sparse. It does not mention how properties interact, whether position conversion is automatic (though schema does), or any prerequisites. Given the presence of many sibling tools and the lack of annotations, a more complete description would add context about when to use this combined setter versus individual ones.
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 detailed descriptions for clipId and each nested property (position even includes effect controls panel conversion context). The description merely lists property names without adding new semantics, so it meets the baseline but does not exceed 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 verb 'Sets' and the resource 'Motion properties of a clip' with explicit property list (opacity, scale, rotation, position). It differentiates from sibling tools like set_clip_opacity, set_clip_scale, etc., which target individual properties, making this the combined setter.
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 individual property setters (e.g., set_clip_opacity, set_clip_scale). The description implies multiple properties but never explicitly says 'use this for setting multiple properties at once' or mentions alternatives. No exclusions or prerequisites 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 says stabilization is applied but does not indicate whether this is destructive, reversible, whether it modifies the original clip or creates a new one, or what side effects occur. This is a significant 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no filler, but it is arguably too terse given the lack of annotations. It earns its place but leaves out important context.
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 3 parameters, no output schema, and no annotations, the one-line description is not sufficient. An agent cannot fully determine side effects, success criteria, or whether the operation is safe/reversible. This is materially under-specified.
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 extra meaning beyond the schema; the enum values 'warp' and 'subspace' are listed but their practical difference is not explained, and 'smoothness' has a range but no behavioral guidance.
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 ('applies') with a clear resource ('video stabilization' on a clip) and states the intended effect ('reduce camera shake'). This distinguishes it from sibling clip tools that perform other transformations.
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 'to reduce camera shake' implies the use case but does not explicitly state when to use this tool versus alternatives or when not to use it. No sibling tool covers stabilization, so the guidance 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.
- 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 of behavioral disclosure. It describes the multi-step process (generates stills, creates sequence, lays out shots, adds dissolves, applies scale animation), which gives some transparency about what happens. However, it doesn't disclose side effects like whether it modifies existing sequences, requires specific project state, or is destructive to existing timeline content. The description is moderately transparent but lacks depth on potential impacts.
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 efficiently lists the key steps and the style outcome. It's front-loaded with the main action and provides enough detail without being verbose. It earns its place by conveying the full workflow in one sentence, though it could be slightly more structured with separators for readability.
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 optional parameter and no output schema, so the description is the primary source of information. It covers the main workflow steps and the intended style, but it doesn't mention prerequisites (e.g., existing media assets, project state), what happens to existing sequences, or how the user can control the process beyond naming. For a complex multi-step tool, this is adequate but not 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% for the single parameter 'sequenceName', which is well-documented with a default value. The description doesn't add much beyond the schema, but since the schema already covers the parameter fully, a baseline of 3 is appropriate. The description's mention of 'creates a sequence' implies the sequenceName parameter is used for naming, but no additional semantics are provided.
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: it generates demo stills, creates a sequence, lays out shots, adds dissolves, and applies scale animation. It uses specific verbs and resources, and the 'polished minimalist ad-style demo' qualifier adds context. However, it doesn't explicitly distinguish itself from sibling tools like 'assemble_product_spot' or 'build_brand_spot_from_mogrt_and_assets', which may have overlapping functionality.
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 creating a motion graphics demo, but it doesn't explicitly state when to use this tool versus alternatives like 'assemble_product_spot' or 'build_brand_spot_from_mogrt_and_assets'. There are no exclusions or alternative tool mentions, so the guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 states it applies adjustments but doesn't disclose whether adjustments are cumulative, reversible, or affect the original clip destructively. The term 'basic' hints at scope but lacks detail on range 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, clear sentence that is front-loaded and efficient. No unnecessary words, but it's so brief it might border on under-specification for a tool with 9 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?
With no output schema and no annotations, the description should provide more context. It explains the core purpose but not the effect of adjustments on the clip, whether it's non-destructive, or typical use cases. For a tool with 9 parameters, a richer description would improve 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 covers 100% of parameters with descriptions, so the baseline is 3. The description adds minimal meaning beyond the schema, only clarifying it's 'basic' correction. It doesn't explain interplay between parameters or prioritize any.
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 ('Applies basic color correction adjustments') and the resource ('a video clip'). It distinguishes itself from sibling tools by focusing on color correction, but it doesn't explicitly differentiate from other effect tools like 'apply_lut' or 'set_color_value', making it slightly less clear in a crowded context.
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 this tool (for basic color correction) but provides no explicit guidance on when not to use it or alternatives. Siblings like 'set_color_value' or 'apply_lut' might be more appropriate for specific adjustments, but no such guidance is 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?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only states the action without revealing side effects, such as whether the original sequence is modified, what happens if no in/out points are set, or the nature of the created subsequence.
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 unnecessary words. It is front-loaded with the primary action and resource.
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?
While the tool has only 2 parameters and no output schema, the description omits critical context such as prerequisites (e.g., in/out points must be set), what the subsequence is used for, or what the tool returns after creation. It is too terse for a creation operation without annotations.
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 both parameters are already documented. The description adds no extra meaning about sequenceId or ignoreTrackTargeting, but it doesn't need to since the schema covers them.
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 from the in/out points of a sequence.' It specifies the resource (subsequence) and the source (in/out points), distinguishing it from siblings like create_sequence or create_sequence_from_clips.
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 requirement of in/out points being set on the sequence, but provides no explicit guidance on when to use this tool versus alternatives, 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?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It mentions 'optionally adds cuts or markers' implying modification, but does not disclose potential blocking behavior (e.g., the allowUnsafeSynchronous parameter warns about long blocking in schema, but description omits this), or any safety/reversibility concerns. This is a significant gap for a tool that may modify the timeline.
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 states the tool's function. It is front-loaded and contains no fluff, earning a perfect 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 tool operates on 'selected clips' and has parameters with safety implications (allowUnsafeSynchronous), the description is incomplete. It does not explain how selection is determined, what the action parameter does in detail, or warn about potential long-running operations. Without an output schema or annotations, the description should provide more behavioral context, but it remains minimal.
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 little beyond the schema—it references 'optionally adds cuts or markers' which aligns with the action parameter, but does not enrich understanding of sensitivity or other parameters. Since the schema already documents all parameters, no additional compensation is needed, but no extra value is added either.
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: 'Detects scene changes in selected clips and optionally adds cuts or markers.' It uses a specific verb (detects) and resource (scene changes in selected clips), and distinguishes it from sibling tools like detect_silence. The mention of optional cuts/markers further clarifies 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when scene change detection is needed but provides no explicit guidance on when to use this tool versus alternatives like detect_silence or scene_edit_detection, nor any exclusions or prerequisites. It lacks clear when-to-use/when-not-to-use 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, placing the full burden on the description. The phrase 'Duplicates a clip' implies a mutation but does not disclose side effects, return values, or whether the original is modified. This lack of behavioral context 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, focused sentence that is immediately understandable. It is appropriately sized and front-loads the core action without any fluff.
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 (2 params, no output schema), the description could still be more informative. It omits any mention of what happens after duplication (e.g., selection, return value) and does not mention the default placement behavior of the duplicate, which is left entirely to the schema. The description is minimally adequate but not contextually 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% (both clipId and offset have detailed descriptions). Per the rubric, this yields a baseline of 3. The tool description adds no extra parameter context 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 'Duplicates' and a clear resource 'a clip', with scope 'on the timeline'. This clearly distinguishes it from siblings like 'duplicate_sequence' or 'copy_effects_between_clips'.
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 usage is implied by the clear purpose; an agent knows when to invoke it. However, there is no explicit guidance on alternatives, exclusions, or prerequisites, so it falls at the baseline for implied usage.
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 carry full behavioral transparency. It only states 'Gets the in and out points' with no mention of side effects, error conditions, or return behavior. It implies a read-only operation but does not explicitly state 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?
One clear, front-loaded sentence that communicates the core functionality with no unnecessary words. Perfectly concise.
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 low complexity (single parameter, no output schema), the description is sufficient for a basic understanding. It clearly states what is retrieved, though it doesn't specify the output format or any constraints. The lack of output schema means the description could have elaborated on return values, but for a simple getter, it is adequate.
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 'sequenceId' is fully described in the schema ('The ID of the sequence'), and the description adds no additional context about the parameter beyond that. Since schema coverage is 100%, the baseline is 3; no further credit is warranted.
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: 'Gets the in and out points of a sequence timeline.' It uses a specific verb ('Gets') and resource ('in and out points of a sequence'), and distinguishes from sibling tools like 'set_sequence_in_out_points' by being the getter.
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, what prerequisites exist, or how it differs from alternatives like 'clear_sequence_in_out' or 'get_playhead_position'. The agent gets no help in tool 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?
There are no annotations, so the description must carry the burden of behavioral disclosure. It clearly states the primary effect (reverses playback), which is a mutation, and hints at audio pitch handling via the parameter description. However, it does not mention whether this operation is destructive/hard to undo, if it affects the source file, or if it applies to a sequence clip or project item, leaving potential ambiguities.
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 states the purpose without any redundant information. Every word earns its place, and it is front-loaded with the action.
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 two simple parameters, an output schema absence, and sibling tools that are similar (like speed_change), the description is minimally complete but lacks important context. It does not explain the effect on the timeline, whether it works on project items or sequence clips, or any side effects. More detail would help an agent select it correctly, but for a simple operation, it's acceptable.
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 provides descriptions for both parameters, but the description adds no additional semantic context beyond what the schema says. However, since the schema coverage is 100%, the baseline is 3, and the parameter `maintainAudioPitch` is well-documented in the schema, so the description doesn't add much. The tool description does not elaborate on how these parameters behave in practice, but the schema is sufficient, so a slight improvement over baseline is warranted because the 'maintainAudioPitch' parameter is clearly explained in the schema and the description mentions it implicitly.
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 (reverses) and the resource (clip), and the verb 'reverses' distinguishes it from siblings like 'speed_change' and 'set_clip_speed' which are about speed, not direction. However, it doesn't explicitly mention the specific aspect of reversal (playback direction) beyond the name, but it's clear enough for a user familiar with video editing.
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 'speed_change' or 'set_clip_speed'. The description only says what it does, not when it is appropriate. For example, it does not clarify that this affects playback direction and might be used for creative effects, nor does it mention any prerequisites like having a clip selected or in a sequence.
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 burden. It states the update operation and the non-active sequence constraint, but does not disclose side effects, whether the update is reversible, or any permission requirements. It adds some context 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, two sentences, and front-loaded with the main action. It avoids unnecessary detail 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?
Given the tool has 5 parameters and no output schema, the description is adequate but not rich. It covers the core update action and the non-active sequence nuance, but does not explain return values or error conditions. It is sufficient for a simple update tool but 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 already documents all parameters. The description adds minimal extra meaning beyond the schema, but it does clarify that the sequence does not need to be active, which relates to sequenceId. 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 tool updates an existing marker's properties in a specified sequence, which is a specific verb+resource. It distinguishes from siblings like add_marker, delete_marker, and list_markers by focusing on updating existing 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 mentions the sequence does not have to be the active one, which provides some usage context. However, it does not explicitly state when to use this tool versus alternatives like add_marker or list_markers, nor does it mention any prerequisites or conditions.
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 behavioral traits. It only states the basic action without any details on side effects (e.g., whether existing keyframes are replaced or appended), prerequisites (like valid clipId or audio track), error conditions, or idempotency. 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, tightly written sentence with no filler or redundancy. Every word contributes to conveying the purpose succinctly.
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 only 2 parameters and no output schema, the description is adequate but not rich. It explains the core functionality but lacks details on behavior such as how keyframes combine with existing ones or any constraints. Given no annotations, more behavioral context would be expected for full 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?
Parameter descriptions in the schema already cover the meaning of clipId and keyframes with time/level. The description adds the context of 'audio levels' and 'dynamic volume changes', clarifying that keyframes apply to volume, which is a slight enhancement beyond the schema. However, it does not add syntax or specific usage details beyond what the schema 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 clearly states the action (adds keyframes), the target (audio levels), and the purpose (dynamic volume changes). It is specific enough to distinguish from sibling tools like set_clip_volume (static volume) and add_keyframe (generic keyframe addition), providing a clear verb+resource+scope.
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 dynamic volume changes are needed, but does not explicitly state when to use this tool versus alternatives like set_clip_volume for static volume or add_keyframe for other properties. No exclusions or alternative names are mentioned, leaving it to the agent to infer the appropriate 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?
The description claims behavior ('one ExtendScript pass', 'top-level success is true ONLY when...') that cannot be verified by the AI agent at runtime&DATA. These are unverifiable implementation details that could mislead planning, and the behavioral claims about partial failures are valuable but are presented without any annotation-backed guarantee. Since annotations are absent, the description carries the full burden but provides insufficient detail about actual runtime side effects, error behavior, or idempotency concerns.
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?
Despite a long wall-of-text format, every sentence adds a necessary fact about batch semantics, performance, or error handling. The information is front-loaded with the core action, and the detail about partial failures and return values is all essential. Highly efficient for the complexity.
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 description reads as a single run-on block with heavy inline parentheticals. It front-loads purpose but mixes performance claims, comparison to `add_to_timeline`, per-clip parameter details, and result semantics into one unwieldy paragraph without any structure (no bullets, no sections). It is far above the 2000-character threshold and hints at important edge cases (per-clip results) that are not clearly explained.
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% -- all parameters (`time`, `linkAudio`, etc.) already have descriptions in the JSON schema. The description adds context about per-clip `sourceInPoint/sourceOutPoint` and notes the clips array maps to overwrite behavior, but this is minimal added value over the schema, so a 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's purpose: to place many clips onto a sequence in a single batch operation stolen from `add_to_timeline` but faster. It distinguishes itself from `add_to_timeline` by explicitly naming it as the equivalent per-clip operation, and the context (
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?
It explicitly states when to use this tool ('rebuilding a whole edit') and contrasts it with `add_to_timeline`, naming the alternative. The performance note ('~50x faster') further clarifies when the batch tool is preferable over sequential single-clip calls.
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?
It mentions verification of parameter readbacks and identification of the created component, which provides some behavioral detail. However, it omits side effects such as undo behavior, error cases, or project mutation semantics.
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 without unnecessary fluff, but it lacks structured formatting such as bullet points or examples, and does not reference the schema fields.
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?
Without annotations, the description provides moderate context about the tool's behavior but misses prerequisites, side effects, and typical use cases. It also does not cross-reference related 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?
Parameter descriptions are minimal: 'The ID of the clip' and 'The name of the effect' are clear, but the 'parameters' object lacks structure or examples, and the exact keys and value types are not specified.
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 (applies a visual or audio effect) and the specific outcomes (identifies the exact newly created component and verifies parameter readbacks), distinguishing it from simpler apply-effect 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 usage (applying an effect to a clip) but does not explicitly mention when to choose alternative tools like batch_apply_effect or list_available_effects, nor does it specify limitations.
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 must fully disclose behavioral traits. It explains the core functionality but does not clarify side effects (e.g., whether it modifies the project), performance considerations, or auth requirements. For a read-only check tool, minimal extra context is available; the description is not misleading 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, concise sentence that conveys the purpose without any fluff. It is appropriately sized for the tool's simplicity and gets straight to the point.
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 no parameters and no output schema, the description adequately covers the essential behavior. It states what is checked and what is returned. It could add a note about the nature of 'offline' but is otherwise complete for the tool's 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 no parameters (0 params, empty schema). According to the rubric, with 0 params the baseline score is 4. The description correctly makes no param references since none exist, so it fully covers parameter semantics by virtue of having 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 clearly states the tool's function: checking all project items and returning those that are offline (missing media). It specifies the verb (checks/returns) and the resource (project items). However, it does not explicitly distinguish itself from similar sibling tools like 'get_offline_media', 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 such as 'get_offline_media' or 'get_unused_media'. The description only states what it does without any context on use cases, preconditions, or exclusions.
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 behavioral disclosure. It states the creation action but doesn't mention side effects such as whether existing projects are closed, whether any default templates apply, or if the project is opened after creation. This is 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, concise sentence that is front-loaded with the key action ('Creates a new Adobe Premiere Pro project') followed by usage context. There is zero waste – every word 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 tool is relatively simple with only two required parameters and no nested objects or output schema. The description is sufficient for understanding the basic function, but for a mutation tool with no annotations, it could benefit from explaining typical consequences (e.g., does it automatically open the project? Are there any prerequisites?). It is minimally 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%, meaning the schema already explains both 'name' and 'location'. The description adds no extra semantic meaning; it only reiterates the purpose. The baseline of 3 applies because the schema covers everything, and description doesn't need to add much, but also doesn't add anything 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 creates a new Adobe Premiere Pro project, which is a specific and unambiguous action. It distinguishes from sibling tools like 'open_project' and 'save_project', but doesn't explicitly contrast with them, preventing a perfect score.
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?
It implies use when starting a new project from scratch, which is clear enough. However, it doesn't explicitly mention when not to use it or mention alternatives like 'open_project' or 'create_sequence', leaving some ambiguity for agents considering related tools.
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 burden. It discloses that factory preset enumeration is not claimed complete, which is a useful limitation. However, it does not describe what happens if no presets are found, whether it scans recursively, or any permission requirements. The description adds some value 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 two sentences, front-loaded with the main purpose, and includes a caveat about factory presets. Every sentence adds value with no redundancy.
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 with one optional parameter and no output schema. The description covers the main purpose and a limitation, but could benefit from stating what the return value looks like (e.g., list of preset paths) and whether it scans subdirectories. Given the simplicity, it is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100% for the single parameter 'directories', which is well-documented as optional absolute directories to scan instead of defaults. The description adds context by mentioning 'tests and advanced setups', which is helpful but not extensive. Baseline 3 is appropriate since the schema already covers the parameter.
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 discovers readable user Adobe Media Encoder .epr presets from local AME preset folders. It specifies the resource (user AME preset folders) and the action (discovers readable .epr presets). It distinguishes from siblings by focusing on presets, which is unique among the listed 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 usage for discovering presets but does not explicitly state when to use this tool versus alternatives. It mentions the optional directories parameter for tests and advanced setups, which gives some context, but no explicit 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It states the tool 'Gets' settings, implying a read-only operation, which is clear. However, it doesn't disclose what happens if the projectItemId is invalid, whether the tool returns all settings or a subset, or any side effects (though 'Gets' suggests none). The description is adequate but minimal—it doesn't add rich behavioral context beyond the obvious read nature.
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 ('Gets the footage interpretation settings') and includes a parenthetical list of example settings for clarity. Zero wasted words, perfectly 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 is simple (1 parameter, no output schema, no nested objects), and the description covers the core purpose. However, it doesn't mention what the return value looks like (since there's no output schema), nor does it clarify whether the settings are returned as a structured object or a formatted string. For a getter tool, some indication of the return format would improve completeness, but the simplicity of the tool keeps this at a 3.
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% (the single parameter projectItemId is described as 'The ID of the project item'). The description adds the context that the parameter refers to a project item and that the tool retrieves interpretation settings for it, but it doesn't add new meaning beyond what the schema already provides. Baseline 3 is appropriate since the schema fully documents the parameter.
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 retrieves footage interpretation settings (frame rate, pixel aspect ratio, field type, etc.) for a project item. It uses a specific verb ('Gets') and resource ('footage interpretation settings'), and the parenthetical examples add useful specificity. It doesn't explicitly distinguish from sibling tools like set_footage_interpretation, but the get/set pairing is implicit and the purpose 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: it's a read operation for retrieving settings, and the sibling set_footage_interpretation suggests the counterpart. However, there's no explicit guidance on when to use this vs alternatives, no prerequisites (e.g., must have a valid project item), and no mention of when this would be useful (e.g., before modifying settings). The context is implied but not stated.
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 must carry transparency. It clearly implies a read-only operation ('Gets') but does not disclose return format, whether it includes hidden clips, or if it depends on active state. This is minimal but not misleading, adequate for a simple getter.
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 with no superfluous words. It is perfectly concise and front-loaded with the action.
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 getter with one parameter and no output schema, the description is minimal but sufficient to understand the core behavior. However, it lacks context about how selection is defined (e.g., does it include clips on all tracks?) and how the result is returned. Given the low complexity, it's barely adequate.
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% for the single parameter (sequenceId), and the description adds no additional semantic information beyond what the schema provides. Baseline of 3 applies because the schema already documents the 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 clearly states the tool retrieves all currently selected clips within a specified sequence, using a specific verb ('Gets') and resource ('selected clips') with scope ('in the specified sequence'). This distinguishes it from sibling tools like select_clips_by_name or get_clip_at_playhead.
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 vs alternatives. It does not mention exclusions or contexts (e.g., 'use this after making a selection' or 'prefer this over get_clip_at_playhead for multiple clips'). The purpose is implied but no explicit usage direction is 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 present, the description carries the full burden of behavioral disclosure. It merely says 'lists' which implies read-only, but doesn't mention performance characteristics, whether effects are returned in any specific order, or whether availability depends on current selection/context. For a read-only list operation this is minimal but could be more explicit about what 'video effects' includes (vs audio/transitions).
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 verb and resource. No fluff. Extremely concise.
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 list tool, the description covers the core purpose. However, it doesn't distinguish from list_available_transitions or clarify whether it returns names only or includes metadata, and there's no output schema. The material being complete enough for a standard list, but lacks distinction from 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?
There are zero parameters, so no parameter semantics to explain. The baseline for 0 params is high – nothing needed. Score 4 because the dimension is trivially 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 states a specific verb ('lists') and resource ('available video effects in Premiere Pro'). This is clearly distinguished from sibling tools like list_available_transitions and list_available_audio_effects, which explicitly cover different effect categories.
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 its siblings. Given the cluster of similar tools (list_available_transitions, list_clip_effects, list_available_audio_effects), the description should at least clarify that this covers video effects specifically, but it relies on the user inferring 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 carries the full burden of behavioral disclosure. It only states the action without mentioning side effects, reversibility, error behavior (e.g., if the keyframe doesn't exist), or whether it affects other keyframes. This is a 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 sentence that is front-loaded with the key action and target, with zero wasted words. It is perfectly 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 is fairly simple with 4 required parameters and no output schema. The description covers the fundamental purpose but omits important context such as exact behavior for duplicate timestamps, error handling, or whether the operation is destructive. Given the presence of similar tools, a brief note on scope (single keyframe vs range) would enhance 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?
Schema coverage is 100%, so the description does not need to restate parameter definitions. It adds marginal value by framing the operation as 'from a clip component parameter', which clarifies the relationships among clipId, componentName, and paramName, but this is already implied by 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 action (removes), the target (keyframe from a clip component parameter), and the condition (at a specific time). It is specific enough to distinguish from siblings like remove_keyframe_range (which removes a range) and add_keyframe.
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 does not explicitly contrast with alternative tools like remove_keyframe_range or specify edge-case conditions. No exclusions or when-not guidance is provided, leaving the agent to infer these from sibling names.
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 provided, so the description carries the full burden. It only states the action (rename) and the context (duplicate_sequence). It does not disclose potential side effects, whether it mutates only the panel or also affects references, whether it requires the project item to exist or be unlocked, or any error conditions. Given the mutation nature, key behavioral info like scope and side effects is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste. The first sentence defines the action, the second provides usage context. Perfectly 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?
For a simple rename tool with 2 params and no output schema, the description is mostly complete. It explains the purpose and the specific context. However, it doesn't mention error conditions, whether the rename is persistent, or any naming constraints (e.g., forbidden characters). Slightly thin for a mutation tool, but acceptable given the low param count.
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 both parameters are clearly described ('newName' and 'projectItemId'). The description adds context about the type (sequence, bin, clip) but doesn't add meaning beyond the schema. Baseline 3 is appropriate as the schema already documents both parameters effectively.
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 it renames a project item (sequence, bin, clip) by setting its name. The purpose is specific and distinct from siblings like rename_bin, rename_track, batch_rename_clips, and delete_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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: 'Use this when duplicate_sequence does not propagate the new name to the project panel.' This clearly differentiates it from rename_bin or batch_rename_clips, though it could mention when not to use it, but the conditional context is strong.
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 to declare safety or side effects, the description carries full responsibility but only says 'sets' without revealing behavior like partial updates, clearing behavior, playhead interaction, or errors. This leaves too much ambiguity for an operations 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, clear sentence that front-loads the primary verb and target, with no wasted words. It is concise while covering the essence of the 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?
For a simple setter with three parameters and no output schema, the description is adequate but incomplete. It does not explain what happens when only one point is provided, nor does it address sequence state requirements or relationship to related 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 already documents all 100% of parameters, so the baseline of 3 applies. The description does not add meaning beyond the schema, nor does it clarify interactions between inPoint and outPoint, so 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 sets in and/or out points on a sequence timeline, using a specific verb and resource. It distinguishes itself from sibling tools like get_sequence_in_out_points and clear_sequence_in_out by its 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 the tool is for setting in/out points on a sequence, but it never explicitly discusses when to choose this over alternatives such as set_source_in_out or set_item_in_out. No 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.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions adjusting points and shortening but does not disclose side effects, reversibility, or how it handles conflicting parameters (duration vs outPoint). Minimal 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?
Single sentence, clear and to the point with no unnecessary fluff. Well-structured for quick understanding.
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?
Tool is simple with 1 required param and schema covers all fields. However, the description does not mention the alternative duration parameter or any constraints (e.g., cannot combine duration with outPoint). Lacks sufficient context for full understanding without schema inspection.
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 parameters are well documented. The description adds no additional meaning beyond what the schema provides, such as clarifying the relationship between duration and outPoint. 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?
Description clearly states it adjusts in/out points to shorten a clip, with a specific verb and resource. It distinguishes from trim-related siblings by focusing on the direct trim operation.
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 shortening a clip but offers no explicit guidance on when to use this vs alternatives like roll_edit or slip_edit. There are no exclusions 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?
There are no annotations provided, so the description must disclose behavioral traits. It mentions it is an 'expanded operation' but does not explain what 'expanded' means—does it add more marker types? Does it have side effects on the project? Does it require the project to be open? No behavioral details are given beyond the basic action, leaving the agent with little understanding of the tool's effects or requirements.
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, very brief and to the point. However, it includes the unnecessary word 'expanded' which lacks clarity, and it doesn't fully utilize the space to provide useful context. It is concise but not optimally structured for informative content.
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 almost minimal. It provides the basic purpose but lacks any details on what the operation entails, such as whether the marker is added to the item's marker list, if it affects the timeline, or what the result looks like. For a tool with no structured metadata, the description should at least indicate what 'expanded' means. It's adequate but not complete enough to fully inform the 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 input schema has zero parameters (0 count, 0 required), and the description coverage is 100% (since there are no parameters to cover). With no parameters, the baseline is 4, and the description does not add anything that contradicts that. The description's mention of 'expanded operation' is vague but does not detract, so the parameter semantics are effectively neutral as there are no parameters to explain.
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 action ('add marker') and the target resource ('project item'), clearly distinguishing it from sibling tools like 'add_marker' and 'add_marker_to_sequence' (though the latter isn't in the list, it's clear from the name). The verb 'add' is specific and the resource 'project item' is unambiguous, making the purpose highly clear.
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 no explicit guidance on when to use this tool versus alternatives. However, the tool name itself clearly indicates the target (project item), and the presence of sibling tools like 'add_marker' and 'add_marker_to_sequence' implies a context where this tool is for adding markers to project items specifically. Still, without explicit exclusions or alternative references, the usage 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 carry the full behavioral burden. It states the bulk mutation scope but does not disclose whether existing transitions are overwritten, whether clips are trimmed to make handles, whether audio tracks are supported, or what happens on failure. These are significant side effects for a bulk timeline 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 two sentences, front-loaded with the action and scope, and contains no filler. It conveys the operation and use case 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?
For a bulk mutation with no annotations and no output schema, the description is too thin. It doesn't explain return behavior, overwrite/conflict handling, or whether it applies to video/audio/graphics tracks, leaving the agent uncertain about important preconditions and consequences.
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 every parameter has a clear description (e.g., 'duration in seconds', 'video track index (0-based)'). The tool description adds only an example transition name ('Cross Dissolve'), so it provides no meaningful extra parameter semantics 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?
'Adds a transition to all clip boundaries on a track' uses a specific verb and resource, clearly differentiating it from single-boundary tools like add_transition. The phrase 'all clip boundaries' and 'between every clip' make the batch scope 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 states it is 'useful for quickly adding cross dissolves or other transitions between every clip,' which implies the intended batch scenario. It doesn't explicitly exclude single-boundary use or mention add_transition as an alternative, but the context is clear enough.
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 it 'gets information' which implies a read-only operation, but it doesn't disclose what specific information is returned, whether it requires an active sequence to exist, or any error conditions. It's a simple read operation, but the description is minimal and doesn't add much behavioral context beyond the basic 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 sentence, concise and to the point. It front-loads the purpose clearly with no wasted words. It is appropriately sized for a simple getter tool with no 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?
Given the tool's simplicity (no parameters, no output schema), the description is adequate but minimal. It doesn't specify what 'information' is returned, which could be important for an agent to know if it needs specific sequence details. However, with no output schema and no annotations, the description could be more explicit about the type of information (e.g., name, duration, settings). It's complete enough for a basic getter but lacks 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 coverage is 100% (empty properties). The description doesn't need to explain parameters since there are none. The baseline for zero parameters is 4, and the description doesn't add any parameter-related information, which is fine. It correctly implies no inputs 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 tool's purpose: to get information about the currently active sequence. It uses a specific verb ('gets') and resource ('active sequence'), which is clear. However, it doesn't explicitly distinguish from sibling tools like get_sequence_structure or get_full_sequence_info, which might also provide sequence information, so it loses a point for not differentiating.
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 information about the active sequence, but it doesn't provide explicit guidance on when to use this tool versus alternatives like get_sequence_structure or get_full_sequence_info. There is no mention of when not to use it or what specific information it returns compared to other sequence-related tools.
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 behavioral disclosure. It states the primary action (import all media files) but omits details about default behavior for recursive import, whether a new bin is created when binName is omitted, handling of unsupported files, or side effects on existing assets. It is accurate 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 sentence that is direct and to the point. It clearly conveys the tool's purpose without extraneous information. No unnecessary words or filler; it is perfectly front-loaded with the core 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?
This is a relatively simple operation, and the description adequately captures the main purpose. However, with no output schema and no annotations, it could benefit from mentioning default behaviors (e.g., whether recursion is on by default) or typical error conditions. For a straightforward tool, the description is sufficient, though not exhaustive.
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 100% of parameter descriptions, providing clear meaning for folderPath, binName, and recursive. The description adds no additional context about how the parameters affect behavior, such as the default when binName is not specified or the default value of recursive. Since schema documentation is complete, 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 imports all media files from a folder into the current project. It specifies the action (import), the resource (folder), and the destination (current project), effectively distinguishing it from other import tools like import_media or import_sequences, which focus on individual files or specific sequence imports.
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 scenarios where using import_media or other import methods would be more appropriate, nor does it state any prerequisites (e.g., project open, path validity). Users must infer usage from the name and description 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?
No annotations are provided, so the description carries the burden. It states it 'lists' something, which implies a read-only operation, but it doesn't explicitly state that it does not modify anything, nor does it describe the format of the list or any potential side effects. Since it's a simple listing operation, the description is adequate but minimal.
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 fully conveys the purpose and scope. There is zero wasted text, and it is front-loaded with the key verb. Perfectly sized for the simplicity of the 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 simplicity (no parameters, no output schema), the description is mostly complete. However, it does not mention what the list contains (e.g., transition names, categories, whether they are available for both video and audio tracks), and it doesn't hint at how the list might be used with other tools. For a simple listing tool, this is acceptable but could slightly improve by mentioning typical usage.
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 fully complete (100% coverage). The description adds no parameter information because none is needed. With zero parameters, the baseline is 4, and the description accurately implies no inputs are required.
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 'Lists all available video transitions in Premiere Pro' clearly states the verb (lists) and the resource (available video transitions) and the domain (Premiere Pro). It distinguishes from siblings by specifying 'video' transitions, differentiating from 'list_available_audio_transitions' and 'list_available_effects'. Clear and 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 clarifies what it lists but provides no guidance on when to use it versus alternatives. For example, it doesn't mention that transitions are typically applied via 'add_transition' or 'add_transition_to_clip', or that the output list might be used to choose a transition name. However, the purpose is straightforward and the use case is implied for choosing a transition type.
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 core behavior (setting the playhead) but does not disclose any side effects (e.g., impact on selection or playback state) or potential errors (e.g., invalid sequenceId). For a simple setter, this is adequate but minimal; it adds little 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, clear sentence that directly states the function. No redundant words or unnecessary details. Perfectly concise.
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 (2 params, no output schema), the description is sufficient to understand the tool's action. It does not explain edge cases like invalid times or sequence states, but for a basic setter, this is complete enough. Could mention if the sequence must be open, but not critical.
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 both parameters (sequenceId and time) with 100% coverage. The description adds no additional meaning about how these parameters interact (e.g., time units, playhead behavior). Since schema coverage is high, 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 ('Sets the playhead position') with a specific resource ('playhead (CTI)') and location ('in the specified sequence'). It distinguishes from siblings like get_playhead_position (read) and move_playhead_to_edit (different movement logic) by the explicit 'position' and 'specified sequence' phrasing.
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 move_playhead_to_edit or get_playhead_position. It does not mention exclusions, prerequisites, or fallback tools. With a large sibling set, this 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.
- Behavior3/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. It states 'gets' indicating a read operation, but does not explicitly disclose side effects, permissions, or return format. For a simple getter, this is minimal but acceptable; however, it leaves ambiguity about error conditions and result 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?
The description is a single, focused sentence that clearly communicates the tool's purpose with no unnecessary words. It is front-loaded and efficient, containing all essential information without verbosity.
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 output schema, the description should clarify the return value format, but it only says 'position' without specifying units (seconds, frames, timecode). This ambiguity could hinder an agent's interpretation. Additionally, it doesn't mention requirements like an open sequence, though it is implied.
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 single parameter (sequenceId) with a description, and the tool description merely restates 'specified sequence' without adding additional meaning. Since schema coverage is 100%, baseline is 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 clearly states the action (gets), the resource (playhead/CTI position), and the scope (specified sequence). It effectively distinguishes from siblings like set_playhead_position and other position-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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for reading the playhead position but does not explicitly state when to use this tool versus alternatives or any exclusions. There is no mention of prerequisites (e.g., open sequence) or 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 carries the full burden. It does not mention side effects (e.g., closing the current project, prompting to save unsaved changes), potential errors (e.g., invalid path, permission issues), or whether the project becomes the active project.
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 unnecessary words or repetition. It is tightly written and immediately understandable.
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 simplicity of the operation and lack of an output schema, the description is adequate but not rich. It does not explain what happens on success (e.g., the project becomes active) or failure (e.g., error behavior), which could be important 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 already fully describes the 'path' parameter, and the description only repeats that it is a file path. No additional detail is added about expected format, validity, or constraints, but the coverage is complete.
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 (opens) and the resource (an existing Adobe Premiere Pro project) with a specific detail (from a file path). It is distinct from sibling tools like create_project and save_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 implies when to use: when wanting to open an existing project from disk. It does not explicitly contrast with create_project or save_project, but the context of sibling tools makes the intended use clear.
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 burden. It mentions the 'linkAudio' parameter's behavior (removes auto-linked audio) and the insertMode options, which adds transparency. However, it does not disclose potential side effects like overwriting existing clips, shifting content, or whether the operation is reversible. The description is not contradictory to any annotations (none 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 sentence that is clear and front-loaded with the core action. It does not waste words, but it could benefit from a brief note on when to use it (e.g., 'Use for single clip insertion; for batch operations, see add_to_timeline_batch'). Overall, it is concise and structured well.
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 complexity (8 parameters, 4 required) and no output schema, the description is adequate but not complete. It explains the main purpose and key parameters but lacks guidance on error conditions, return values, or interaction with other tools. The description covers the essentials but leaves room for more detail on edge cases like invalid track indices or time conflicts.
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%, so the schema already documents all parameters. The description adds value by explaining the 'linkAudio' parameter's purpose (removing silent PCM audio) and the 'sourceInPoint'/'sourceOutPoint' semantics (replicating Source monitor marks). This goes beyond the schema's basic descriptions, providing practical context for parameter usage.
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 a media clip from the project panel to a sequence timeline at a specific track and time.' It specifies the resource (media clip), the destination (sequence timeline), and the placement parameters (track and time). This distinguishes it from siblings like add_to_timeline_batch, remove_from_timeline, and 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for placing clips on a timeline but does not explicitly state when to use this tool versus alternatives like add_to_timeline_batch or insert_from_source. It lacks guidance on prerequisites (e.g., sequence must exist, project item must be valid) or when to prefer other insertion methods.
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 full burden of behavioral disclosure. It clearly states that the tool mutates the link state, which is helpful, but it does not disclose edge-case behavior (e.g., what happens if the clip is already linked, or if there's no matching audio/video component). It's a straightforward but minimal 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?
A single, compact sentence that conveys the complete operation in 10 words. Every word earns its place, and the dual-action nature (link/unlink) is front-loaded. Zero verbosity; the definition of concise.
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 with 100% schema coverage and no output schema, the description covers the essential information. It could be enhanced by elaborating on linkage edge cases (e.g., what happens with unlinked or video-only clips), but the current offering is adequate and complete for 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?
Schema description coverage is 100%—both clipId ('The ID of the clip') and linked ('Whether to link (true) or unlink (false)') are well-documented in the schema. The description doesn't add or need to add parameter-level detail, 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 uses a specific, unambiguous verb pair ('links or unlinks') with a clear resource ('audio and video components of a clip'). It fully explains the tool's dual functionality and leaves no doubt about what operation is performed, clearly distinguishing 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when this tool is used—when a user wants to toggle the link state of a clip's audio/video components. However, it provides no explicit guidance on when NOT to use it, prerequisites (e.g., whether the clip must be a linked pair), or differentiation from related siblings like link_selection/unlink_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 full burden for behavioral disclosure. 'Lists' implies a read-only operation, which is reasonably self-evident, but it doesn't explicitly state that it doesn't modify anything or clarify the return format (e.g., names only, categories). For a simple query tool, 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 sentence that fully states the tool's purpose without any filler. Every word contributes to clarity, and it's front-loaded with the verb. Zero waste.
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 sufficient. It clearly communicates the function and scope. The only minor gap is not specifying whether the list includes all types of audio effects (e.g., built-in, third-party, or both), but that's likely implied by 'all available'.
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 baseline for 0 parameters is 4. The description correctly notes it lists effects but doesn't need to describe parameters since there are none. Schema coverage is complete (though trivially).
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 (lists) and the resource (all available audio effects in Premiere Pro). It distinguishes itself from siblings like list_available_effects and list_available_audio_transitions by specifying audio 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 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 that list_available_effects might include audio effects or that this tool is the audio-specific subset. No exclusions or alternative tool names are cited.
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 must carry the transparency burden. It clearly implies a read-only enumeration scoped to the current project. However, it does not disclose details like whether the result includes nested bins, performance implications for large projects, or whether it returns offline media, leaving some behavioral uncertainty.
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, 22 words, front-loaded with the primary action and followed by a purpose statement. 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 low-complexity tool with two optional boolean parameters and no output schema, the description covers purpose and usage context. The schema covers parameters, and the description adds the 'discover available media' workflow context. Could mention hierarchy or exclusion behavior, but this 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 description coverage is 100%, with both `includeBins` and `includeMetadata` already documented in the schema. The description does not add parameter-level detail, but the baseline of 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.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb+resource+scope ('Lists all media items, bins, and assets in the current Premiere Pro project'), which distinguishes it from sequence- or track-specific list tools. However, it does not explicitly name sibling alternatives like list_sequences or get_bin_contents, preventing a 5. The usage hint adds value.
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?
Explicit when to use: 'Use this to discover available media before performing operations.' This gives clear context for when the tool is appropriate. However, it does not explicitly state when not to use it or name specific alternatives, so it stops 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?
No annotations are provided, so the description must convey what the tool does and any side effects. It states it lists tracks and their properties, implying a read-only operation, but it does not disclose whether it includes hidden tracks, the order of tracks, or if it requires the sequence to be loaded. The absence of annotations raises the burden, and the description only partially meets 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, concise sentence that conveys the core purpose without extraneous details. It is front-loaded with the main action and object, making it efficient for an agent 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?
The tool is relatively simple (one parameter, no output schema) and the description covers its purpose adequately. It does not describe the return structure, but since no output schema exists, the description could mention that it returns a list of tracks with properties and clips, which it does. For a list operation, this 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?
The schema description coverage is 100%, with the 'sequenceId' parameter fully explained (GUID, source fields, and usage context). The description does not add extra parameter semantics, but given complete schema coverage, baseline 3 is appropriate; it does not harm by omitting redundant information.
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 lists all video and audio tracks in a specific sequence and includes their properties and clips. It uses a specific verb ('Lists') and resource ('video and audio tracks'), effectively distinguishing it from sibling tools like list_sequences (which lists sequences) and get_track_info (which likely targets a single track).
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?
While the description implies use when you need track-level details for a specific sequence, it does not explicitly state when to use it versus alternatives such as get_sequence_structure or get_timeline_summary. The context is clear but lacks exclusions or explicit alternative guidance, which is common among the sibling tools.
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 discloses a behavioral trait (operating on non-active sequences) but does not mention side effects, error conditions, or other effects beyond the lock/unlock action. Given no annotations, this is moderate 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 two concise sentences with no redundancy. It is appropriately sized and front-loaded with the core purpose.
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 adequately covers the main functionality and includes a useful contextual note about non-active sequences. It lacks details on return values or errors, but for a simple operation, 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 schema descriptions are clear and cover 100% of parameters. The description adds no extra meaning beyond what is already in the schema, 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 clearly states the action (lock/unlock) and its purpose (prevent/allow editing). It also adds the additional context that the sequence need not be active, enhancing clarity.
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 locking/unlocking tracks) but does not explicitly distinguish it from alternative tools or provide usage conditions beyond the stated purpose.
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 transparency burden. It clearly discloses that the tool cuts across multiple tracks and defaults to all tracks if no arrays are given, but does not mention undo behavior, locked tracks, or potential error cases.
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 concise sentences front-load the core action and the critical default behavior. Every word earns its place with no 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?
Given a well-documented schema and a straightforward operation, the description adequately covers the core behavior and defaults. It lacks return value and error handling, but for a mutating cut command that is acceptable; could mention undo or prerequisite sequence 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?
The input schema already documents all four parameters with individual descriptions, so the description adds limited new semantic value. The line about no track arrays defaulting to all tracks complements but mainly restates what the schema already implies per-parameter.
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 ('Cuts') and resource ('multiple tracks in a sequence') with a precise condition ('at an absolute timeline time'). It differentiates from siblings like razor_all_tracks by noting optional track arrays and the default to 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context about default behavior when track arrays are omitted, but does not explicitly compare with alternatives like razor_all_tracks or split_clip. Usage is implied rather than directly stated as 'use this when...'.
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 the tool creates a timeline but does not mention side effects like whether it modifies the current project, creates a new sequence, or requires specific permissions. This is a gap for an agent.
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 concise sentences, no redundancy. It efficiently conveys the key purpose and the two modes of 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?
The description is brief and lacks details about what happens after execution (e.g., whether a new sequence is created, if it returns a reference, or if it modifies existing project state). Given the tool's complexity, more context might be needed for an agent to use 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 schema already provides descriptions for all parameters (100% coverage). The description adds context about template defaults vs. explicit clipPlan, but it does not significantly enhance understanding of individual parameters 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's purpose: building a production-oriented promo timeline from media assets. It distinguishes itself from sibling tools by mentioning the explicit clipPlan for LLM-directed control, which is unique to this tool.
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 explains when to use this tool (when building a promo timeline) and mentions the choice between template defaults and an explicit clipPlan, giving clear guidance on how to leverage the tool. It does not explicitly state when not to use it, but the context is sufficient.
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 transparency burden. It discloses one behavioral nuance (sequenceId needed for non-active sequences) but does not mention whether removal is destructive/undoable, how deleteMode affects the timeline, or what happens to the source clip.
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 concise sentences with the main purpose front-loaded and a single high-value conditional detail. No filler or repetition of schema data.
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 adequately covers the core operation and key sequenceId case, but with no output schema and no annotations, it leaves gaps around expected return behavior and differentiation from sibling removal tools. Minor gaps prevent a higher score.
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 tracing clipId origin to list_sequence_tracks and clarifying when sequenceId is required, which goes beyond the schema's generic 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 action ('Removes a clip from the timeline') with a specific resource and scope. It distinguishes itself from sibling tools like remove_selected_clips or ripple_delete by targeting a clip by ID.
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?
Provides a specific usage condition for sequenceId ('Pass sequenceId when the clip ID came from list_sequence_tracks for a non-active sequence'), but does not explicitly discuss when to use this tool versus alternative removal tools or 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 burden. It discloses a mutation action ('Saves'), but lacks explicit details about overwriting the existing file, prerequisites beyond an active project, or error behavior. The description is not misleading but could be more 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, front-loaded sentence with no superfluous text. It clearly and efficiently communicates the core action.
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 minimal. It does not differentiate from save_project_as or mention any behavioral nuances (e.g., file overwrite, return value). More context would improve completeness, but the core purpose is sufficiently clear.
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 covers this. The description adds no parameter-specific details because there are none, which aligns with the baseline of 4 for a 0-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 tool saves the currently active Premiere Pro project, using a specific verb ('Saves') and resource ('currently active Adobe Premiere Pro project'). It distinguishes from siblings like save_project_as by specifying 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 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 you need to save the active project—but does not explicitly provide alternatives or exclusions. It does not mention save_project_as or other related tools for saving under a different name/location.
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; it usefully discloses that the call applies to all audio clips, executes in one ExtendScript call, and returns per-clip results. However, it does not say whether the effect is added or replaces existing effects, whether it is undoable, or how partial failures are reported.
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 short sentences that front-load the purpose with 'Bulk:' and avoid filler. Every phrase contributes: scope, behavior, return shape, and rationale for using the 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?
For a three-parameter batch tool with no output schema, the description tells the agent the key operational facts: all clips are affected, results are per clip, and the main use case is bulk calibration or effects chains. The schema covers parameter semantics, though a note on add-vs-replace behavior would make it 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 documents all parameters at 100% coverage, including examples for effectName, normalization for parameters, and the active-sequence requirement for sequenceId. The description adds no additional parameter-level guidance, so it stays at the baseline.
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 'Bulk:' and states it applies a single audio effect to ALL audio clips of a sequence in one ExtendScript call, clearly distinguishing it from single-clip apply_audio_effect or other batch tools. The verb and scope are 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It says to use this when 'calibrating or applying same chain' and emphasizes saving N MCP roundtrips, which indicates a bulk same-effect scenario. It does not explicitly name alternatives like apply_audio_effect or state when not to use it, so it has clear context but not exhaustive exclusions.
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 describes the action (creates a caption track) and the source (imported caption file), but it does not mention potential side effects, such as overwriting existing caption tracks, or any required permissions. It adds some context (the file must be imported first) 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, concise sentence with no wasted words. It front-loads the purpose and includes a key detail (pass the SRT project item ID directly) that helps avoid misuse.
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 moderate complexity (4 params, none required beyond the two IDs), the description is quite complete: it explains the input format (imported caption file), provides default behavior for startTime and captionFormat, and states the action clearly. Without an output schema, it could mention what the function returns, but the description suffices for the core task.
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 all parameters well. The description adds value by clarifying the source parameter ('SRT project item ID') and mentioning the default for startTime and captionFormat, but since the schema covers everything, the description goes slightly beyond a 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 clearly states the tool's purpose: creating a caption track on a sequence from an imported caption/subtitle file. It specifies the resource (sequence and project item) and distinguishes it from siblings like read_sequence_captions by focusing on creation.
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 usage: it mentions the prerequisite of importing a .srt via import_media and tells the user to pass the SRT project item ID directly. It does not explicitly say when not to use it, but the context is clear, and it points to a specific prerequisite tool.
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 mentions the sequence need not be active, which is a behavioral trait. However, it does not disclose any other details like return format or potential errors. For a simple read-only list, this is adequate but minimal.
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, with no wasted words. It front-loads the core purpose and includes an essential condition. Perfectly structured for quick understanding.
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 one parameter and no output schema. The description covers the essential purpose and a key constraint. It does not explain return values, but for a list operation it's implicitly clear. Slightly more detail could be added to distinguish from marker-type-specific tools, but it's not necessary.
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 high coverage (100%) for the single parameter sequenceId, including its origin and type. The description adds no extra semantic value for the parameter beyond what schema states, 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 clearly states it lists all markers in a specified sequence, using a specific verb and resource. It distinguishes from siblings like list_sequences and get_sequence_markers_by_type by noting it returns all markers without filtering.
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 a key usage condition (sequence does not need to be active) but does not explicitly mention alternatives or when to prefer this over similar tools like get_sequence_markers_by_type or get_clip_markers. The note about non-active sequence gives context, but no 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 must carry the behavioral burden. It discloses the source of refresh (disk) but does not mention side effects, failure modes (e.g., file missing), or whether edits/proxies are affected. This is a basic disclosure but insufficient for a mutation tool without annotations.
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 with no fluff, efficiently conveying the core action and source. It is appropriately 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 one parameter, no output schema, and no annotations, the description is mostly complete. However, it could mention behavior when the file is missing or if it affects existing metadata, which would add robustness. Still, it adequately covers the essential purpose.
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%, and the sole parameter 'projectItemId' is adequately described in the schema. The description adds no new parameter-level detail, 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: 'Refreshes the media for a project item, reloading it from disk.' It specifies the verb (refresh) and the target (project item), and distinguishes from siblings like import_media or relink_media by the reload-from-disk intent.
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 usage: when media may be out of sync with the disk or needs reloading. It does not explicitly name alternatives or exclusions, but the context is clear enough that an agent can infer when to use it. However, it could have explicitly pointed to relink_media or check_offline_media for alternative scenarios.
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?
Discloses that it does not return live render queue telemetry but returns guidance for Adobe Media Encoder, which goes beyond the empty annotations and no 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?
Two sentences, front-loaded with the main purpose and contextual caveat, no 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?
Adequately describes the tool's behavior and limitations for its complexity; no output schema exists but none is strongly needed for a binary availability check.
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?
No parameters exist and the schema is empty with high coverage; no name/description compensation 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?
States clearly it reports whether render queue monitoring is available, and adds the caveat that it currently returns Adobe Media Encoder guidance rather than live telemetry. This distinguishes its current behavior from a direct queue status query.
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?
Gives context that this is an availability check and notes the Adobe Media Encoder behavior, but does not explicitly state when to use this tool over alternatives or name alternative tools.
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 and does well: it discloses the return format (per-clip result array with `applied` map and `success` flag), defines success strictly (true only when EVERY property was found and set), and notes that missing properties are reported rather than silently ignored. It doesn't cover side-effects like overwriting existing properties, but the transparency level is above average.
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 two sentences, front-loaded with the primary purpose and speed advantage. The second sentence is dense but conveys critical behavioral details about return values and error handling, earning its place. No fluff or repetition.
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 batch operation with nested input and no output schema, the description sufficiently covers return behavior, success semantics, and error reporting. It could mention prerequisites like clips having the Motion effect, but that's implicit. It also stands out against a large sibling list by clearly differentiating itself.
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 100% of parameters with detailed descriptions, including the exact pixel-based position semantics and normalization. The description reinforces the property names but adds no new meaning beyond the schema. Per rubric, a baseline 3 is appropriate when schema coverage is complete.
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 applies Motion properties (opacity/scale/rotation/position) to multiple clips in a single round-trip, distinguishing it from the singular set_clip_properties sibling. The verb 'Applies' with specific resource and scope, plus the ~50x speed comparison, makes 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?
It clarifies when to use this batch tool vs the singular alternative ('~50x faster than one set_clip_properties call per clip') and provides a concrete use case ('per-speaker framing across a whole rebuilt edit'). It doesn't explicitly list exclusions or other alternatives like individual setter tools, but the 'MANY clips' emphasis implies single-clip usage should go elsewhere.
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 side effects. It mentions building a curve and computing keyframes, which implies modifying the clip's audio keyframes, but it does not explicitly state that the tool will add or modify keyframes on the clip, nor does it mention any potential destructive actions, permissions, or other behavioral impacts.
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 that efficiently convey the tool's purpose, behavior, and key timing convention. It avoids unnecessary detail and is well-structured for quick understanding.
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 explains the core functionality and input interpretation well, but it does not mention what the tool returns or any error conditions (e.g., what happens if duckingWindows are invalid). Since there is no output schema, a brief note on return behavior would improve completeness, but the current description covers essential usage context.
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?
All 6 parameters are fully described in the schema (100% coverage), and the description adds crucial context such as times being clip-source-time absolute and the meaning of empty duckingWindows. The parameter meanings are clear and unambiguous.
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: it builds a ducking curve by wrapping add_audio_keyframes, specifying the inputs (base level + ducking windows) and the output (keyframes). It also distinguishes itself from the manual '8 keyframes per video' pattern, 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates it is a high-level wrapper for add_audio_keyframes and replaces a manual pattern, giving some context on when to use it. However, it does not explicitly state when to use this instead of directly using add_audio_keyframes or other alternatives, nor does it mention any exclusions or conditions.
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?
The description discloses a key behavioral trait: the tool may return 'accepted_unverified' meaning the command was accepted but not verified, and instructs not to retry automatically. This is valuable context beyond what annotations would provide (though no annotations are given). It adds specificity about result interpretation and retry logic.
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 with zero wasted words. The first sentence is a clear declaration of purpose, and the second provides essential behavioral guidance. Well-structured 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 mutation tool with 4 parameters and no annotations or output schema, the description covers the key behavioral nuance (accepted_unverified status) and clearly states what the tool does. It doesn't describe the return format beyond the status mention, but for a single-clip operation this is sufficient. The gap is not specifying prerequisites (e.g., clip must be on a track) but that may be implicit.
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 has descriptions for all four parameters with 100% coverage. The description adds minimal parameter-related meaning beyond the schema, but it does mention the valid values for position ('start' or 'end') implicitly. With full schema coverage, 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's purpose: adding a transition to the beginning or end of a single clip. It distinguishes from the sibling tool 'add_transition' (which likely handles multiple clips or different context) by specifying 'to a single clip', and also distinguishes from 'add_to_timeline' and 'batch_add_transitions'.
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 usage: the tool is for adding transitions to a single clip, and mentions checking status/verified in the result. However, it doesn't explicitly state when not to use it or name alternative tools for other scenarios (e.g., batch_add_transitions for multiple clips). It provides clear context but lacks explicit exclusions.
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?
There are no annotations provided, so the description carries the full burden for behavioral disclosure. It explains the tool's side effects: reusing an existing Crop effect, adding one if absent, and that omitted parameters keep current/default values. It does not detail whether the operation is reversible or if any rendering/updates affect the timeline, but these are 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 concise and front-loaded: it states the purpose and key behavior in two sentences, with zero waste. It efficiently covers the reuse/add behavior and parameter omission handling.
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 7 parameters (all schema-described), no output schema, and no annotations, the description provides the necessary behavioral context: the effect reuse, addition, and default handling. It is complete enough for an agent to select and invoke the tool correctly, though it lacks a note on error handling or available effect prerequisites.
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 detailed descriptions for each parameter (top, left, right, bottom, zoom, edgeFeather, clipId), so the schema already provides full meaning. The description adds minimal extra value beyond clarifying omitted parameters keep defaults, which is already implied 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 clearly states the tool crops a timeline clip using Premiere Pro's built-in Crop video effect, with specific behavior of reusing an existing effect or adding one. It distinguishes from siblings like 'trim_clip', 'set_clip_scale', 'razor_timeline_at_time' and others by specifying the use of the Crop effect.
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 (to crop a clip via the Crop effect) and notes that omitted parameters retain current values. However, it does not explicitly mention when not to use it or name alternatives (e.g., trim/clip operations), missing a full exclusionary note.
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 burden. It usefully discloses output specifics (normalized and pixel position values, sequence frame size, no need to export a frame) and implies a read-only operation with 'Gets'. However, it does not describe the full set of returned properties, error behavior, or sequence fallback semantics beyond the sequenceId note.
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 focused sentences, front-loaded with the core purpose, followed by high-value formatting detail and a practical invocation note. No fluff or redundant restating of the schema.
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 partially compensates by specifying the notable motion.position return format. It is adequate for a simple read tool with two well-documented parameters, though it leaves the full 'detailed properties' scope implicit.
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% with both parameters documented, so baseline is 3. The description adds valuable context beyond the schema by explaining when and why to pass sequenceId for non-active sequences and how the position output is presented.
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 ('Gets detailed properties of a clip') and clearly calls out the distinctive Motion values (opacity/scale/rotation/position), which differentiates it from sibling tools like get_clip_effects or get_full_clip_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 clear targeted usage guidance: pass sequenceId when the clip ID came from list_sequence_tracks for a non-active sequence. It does not explicitly name alternatives or exclusions, but the context is sufficient for correct invocation.
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 provided, so the description must disclose side effects and nuances. It does: duration is 'best-effort' (may not be exact), the override field behavior is explained (ignores extra text fields, fails if property not found), and the rollback via rollbackOnAllFail. These add valuable behavioral context beyond the raw schema.
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?
Description is two sentences: the first states the core action and the requirement; the second explains the field mapping and a caveat. Concise and front-loaded, but could be slightly more structured (e.g., bullet points) for readability. Still, 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?
Covers the critical requirement (MOGRT path), the multi-field mapping, the best-effort duration behavior, and the override mechanism. It lacks explicit error handling (e.g., what happens if the MOGRT is invalid) but provides enough for an agent to use the tool correctly. Given no annotations or output schema, it 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?
Schema already describes each parameter well (e.g., duration is 'best-effort', trackIndex mentions creating track first). The description adds the mapping of text fields to MOGRT components, which is not fully in schema (schema only says 'typically the main title' for text). It also clarifies the override behavior. The description adds meaning beyond the schema, especially the component behavior and the text2/text3/text4 mapping.
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?
Clear verb+resource: 'Adds a text overlay' to the video timeline. Distinguishes itself from sibling tools by specifying the MOGRT requirement and the up-to-4 text fields, which is unique among the many set_* and add_* tools. The purpose is 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?
States when to use: requires a .mogrt template, and the description explicitly mentions using add_track first if needed (via schema). It also clarifies when to use the override property (when auto-detection fails), providing alternative behavior. However, it doesn't explicitly list sibling alternatives or exclusions, but the usage context is clear.
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 fully discloses behavioral nuances: the open-sequence requirement, the QE DOM fallback, the risk of reporting by name rather than deleting, and the unsupported caption track behavior. This is thorough and transparent.
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 bit dense but each sentence contributes valuable information—scope, prerequisites, fallback behavior, and limitations. It is efficiently structured without redundancy, though slightly long for a high-level alert.
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 mutation tool with no output schema, it covers the essential operational constraints and failure modes. It does not explicitly state the return format or success/failure indicators, but the behavioral details are sufficient given the 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 covers all three parameters with descriptions (100% coverage). The description adds the caption track limitation and clarifies the sequenceId source, but these are more behavioral than parameter-specific. It does not significantly improve parameter understanding 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 action: deleting a video or audio track from a specified sequence. It uses specific verbs and resources, and distinguishes from related tools like add_track or ripple_delete by focusing on track deletion.
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 explicit usage context: the sequence need not be active but must be open, and explains the fallback to QE DOM and the unsupported caption track case. However, it does not explicitly name alternative tools for deleting tracks in other contexts or contrast with similar operations.
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 burden. It discloses the requirement for the optional panel, the return type (timeline-timed segments plus diagnostics), and the non-support for captions. It does not mention side effects (likely none) or failure modes if the panel is missing, but for a read tool 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?
The description is two concise sentences: the first states the core function and requirement, the second explains the output and limitation. Front-loaded and economical, with no redundant information.
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?
Given the low complexity (1 optional param, no output schema, no annotations), the description is complete: it covers the function, prerequisites, return content, and what it does not cover. For a read-only tool, no further details are necessary.
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% (the single sequenceId parameter is described with 'Optional sequence ID. Defaults to the active sequence.'). The tool description does not add additional parameter semantics, but the schema already handles it fully, so the 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 reads Premiere Speech-to-Text transcripts from source clips of a sequence, distinguishing it from caption reading ('it does not read caption tracks') which is a distinct sibling tool (read_sequence_captions). The verb 'Reads' is specific to a resource and scope.
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 a clear prerequisite (requires MCP Transcript Bridge panel in Premiere Pro 25.6+) and an explicit exclusion ('does not read caption tracks'), which guides when not to use it. However, it does not explicitly name an alternative for caption tracks, though the sibling list includes read_sequence_captions, making the guidance strong but not fully explicit.
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 present, so the description must disclose behavioral traits. It discloses that it bypasses the dialog and requires an installed preset. It could additionally mention that it creates the sequence in the current project, but this is reasonably implied. The disclosure is adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the core function, then alternatives. Every word earns its place; no 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?
The description is complete for its purpose: it explains what it does, avoids a dialog, and points to alternatives. No output schema exists, but that's typical for a creation tool. It might have mentioned the sequence is added to the current project, but this is implied and not critical.
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 for both parameters, including a detailed description for presetPath (explaining it avoids the dialog). The tool description repeats this information without adding new semantic detail, so it adds no value 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?
Clearly states it creates a new sequence from a .sqpreset file without opening the New Sequence dialog. Distinguishes from sibling tools create_sequence_from_clips and duplicate_sequence, making the unique purpose explicit.
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?
Directly advises when to use alternatives: for footage-driven edits prefer create_sequence_from_clips, and for an empty copy use duplicate_sequence with clearContents=true. This provides clear when/when-not 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?
No annotations are provided, so the description carries the full burden. It discloses that the tool does not perform the import but reports unavailability, and explains the underlying reason (interactive dialog blocks CEP). This is transparent about the tool's behavior, though it could mention what the tool actually returns (e.g., an error or status).
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 key message, and no wasted words. The description is concise and structured effectively.
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 simple purpose (reporting unavailability) and the single parameter, the description is complete. It explains the limitation, the reason, and the alternative. It could mention the return value, but the lack of an output schema and the tool's nature make this less critical.
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 filePath parameter, so the schema already documents it. The description adds context about the file type (.edl) but doesn't add new semantic meaning beyond 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 reports that EDL import is unavailable, naming the specific format (CMX 3600 EDL) and the reason (interactive dialog blocks CEP). It distinguishes itself from the sibling import_fcp_xml by explicitly recommending it as the 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 explicitly states when not to use this tool (EDL import is unavailable) and directs the agent to use import_fcp_xml for unattended timeline interchange. This provides clear guidance on alternatives and context.
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?
Crucial behavioral facts are disclosed: that on this Premiere build the operation is remove-and-reinsert (can overwrite destination contents) and that the clip receives a new id. This goes beyond what annotations alone would provide (none provided), though the description stops short of listing side effects like track-locking or permission prerequisites.
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 focused sentences; the first defines operation and scope, the second explains the destructive alternative and names the sibling call. No filler or repetition.
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 2-parameter no-output mutation operation, the description covers core semantics: movement target, track preservation, cross-track behavior, and overwrite risk. It omits permission/error details, but the schema plus known annotation level make this 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?
Input schema already has 100% parameter coverage with functional descriptions for both clipId and newTime. The text adds 'in seconds' to newTime, but this duplicates schema info; no deeper guidance on accepted time formats or precision is provided.
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+resource: 'Moves a clip along the timeline' plus scope constraint 'keeping it on its current track.' It explicitly distinguishes itself from the sibling tool move_clip_to_track, making the core 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 Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Directly states when to use this tool vs. the alternative: 'To move a clip to a different track, use move_clip_to_track' – naming the exact sibling tool. This gives the agent clear routing.
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?
The term 'non-destructive' immediately signals that the tool does not mutate project state, which is valuable given the absence of readOnly/destructive annotations. It also enumerates checks performed, but does not detail return value or any potential side effects beyond that, so a small gap remains.
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, efficiently covering the purpose and a comprehensive list of checks. It is well-structured and free of redundancy, making it easy for an agent to parse quickly.
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, the description adequately explains the audit's scope and non-destructive nature. However, it does not mention what the tool returns (e.g., a report, success/failure), which could be important for an agent to handle the outcome. This small omission prevents a perfect 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?
The schema already provides full descriptions for all five parameters, including defaults and optionality. The tool description does not significantly add meaning beyond referencing 'active or requested sequence' and 'missing export preset/output folder inputs', which are already implied by the parameter names and schema. This aligns with 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 runs a non-destructive export readiness audit, specifying the action (audit) and the target (active or requested sequence). It is distinct from sibling tools that focus on retrieval or modification, as it explicitly checks export-related conditions.
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?
Explicitly indicates usage 'before an agent queues an export', and describes what conditions it verifies (timeline content, offline media, missing inputs, gaps, markers, track state). This provides clear guidance on when to invoke this tool, even without directly contrasting with 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?
Despite no annotations, the description fully discloses behavioral traits: it creates a new sequence, requests UI suppression, and may reject malformed/unsupported XML. It also clarifies the version limitation versus FCPXML 1.x, covering failure modes and usage expectations without needing 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three tightly packed sentences deliver maximum value: the action, side effect, UI behavior, failure mode, and format warning. No word is wasted, and the most critical 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 single-parameter import tool with no output schema, this description is comprehensive. It answers 'what, what happens, what could go wrong, and what format to provide,' covering the behavioral contract completely despite 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 schema covers 100% of the single parameter with a description that already mentions 'FCP7 XML file'. The description adds minimal extra parameter-specific meaning beyond reinforcing the legacy format, so it rightly stays at 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 clearly states the action ('Imports a Final Cut Pro 7 XML (XMEML) file into the current project'), the resource, and the key side effect ('Premiere creates a new sequence with the cuts/clips defined in the XML'). It differentiates from siblings like export_as_fcp_xml by implying the import direction and explicitly distinguishing FCP7 XML from FCPXML 1.x.
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 on when to use the tool (for legacy FCP7 XML imports) and the caveat about malformed XML, but it does not explicitly name alternative tools like import_edl or import_media. The guidance 'Use legacy FCP7 XML, not modern FCPXML 1.x' is more about input format than tool selection, so it falls just 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosure. It explains the toggle action and emphasizes 'output' vs 'targeting', which adds behavioral clarity beyond the schema. However, it does not mention potential side effects or reversibility, though the operation is simple and likely reversible.
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, two sentences, each adding value. It front-loads the purpose and then adds a key differentiator. There is no redundancy or fluff.
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 toggle tool with 3 parameters and no output schema, the description is complete. It covers what, when, and how it differs from related operations. No missing critical information.
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 does not add substantial meaning to the parameters beyond what the schema already explains (e.g., visible, sequenceId, trackIndex). It provides minimal extra context, but the schema descriptions are sufficient.
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: shows or hides a video track by toggling its output (eye icon). It uses a specific verb and resource, and distinguishes from set_target_track by explicitly noting this is output, not targeting.
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 to use this tool (toggle output visibility) and when not to (targeting), directing to set_target_track for V1/A1 patch buttons. It also clarifies that the sequence need not be active, providing clear context for usage.
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?
The description explicitly states 'read-only' and 'without changing the project', clearly disclosing the non-destructive nature. It also mentions the report contents, providing transparency about 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two short sentences—and contains no unnecessary detail. It is well-structured and directly to the point.
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 readiness check, the description covers all necessary aspects: what it does, when to use it, and what it reports. No additional information is required, and it is complete within its scope.
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 parameters, so the baseline of 3 applies. The description does not need to add parameter details, and the tool's simplicity is well conveyed.
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 it is a read-only readiness check for the CEP bridge and Premiere Pro host, and it distinguishes itself from sibling tools like 'ping' by covering the bridge and host state in detail (version, project, 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?
It explicitly instructs to run before an editing workflow to confirm the bridge, giving clear usage context. However, it does not explicitly mention alternatives or when a lighter check like 'ping' might suffice, so it could be slightly more prescriptive.
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 the full burden and delivers: it discloses that settings are applied, read back for verification, and that any accepted-but-unchanged fields are reported. It also directly addresses the frame size mutation constraint. The DEV deliberately corrected prior codebase misinformation, showing proactive 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?
Three sentences, each earning its place: one for action, one for verification behavior, one for correcting a misconception. Essential information is front-loaded. No filler 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?
For a setter with a nested settings object and no output schema, the description fully explains the tool's behavior including edge-case handling (unaccepted values). It omits potential edge cases like type conversion behavior or whether parent sequences need to be open, but given the available context and sibling landscape, this is quite 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 input schema has 100% coverage with detailed types and format examples (e.g., N:M notation for pixelAspectRatio), which carries the parameter documentation. The description adds marginal value by noting read-back validation affects parameters, and the frame-size variation note implies width/height are mutable together. Description goes beyond mere restating.
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 'Updates sequence settings,' a clear verb+resource construct. It enumerates specific fields (width, height, frameRate, pixelAspectRatio) and describes the apply-readback-report lifecycle, which distinguishes it from focused siblings like set_sequence_frame_rate. The clarification about frame size being changeable adds 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?
Clear context is given for what the tool does and its verification behavior, but no explicit exclusions or named alternatives. Given siblings like set_sequence_frame_rate and set_sequence_resolution exist, explicit differentiation would earn a 5. The 'contrary to an earlier note' phrase hints at correcting prior guidance, which is useful context.
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 full responsibility. It fully discloses that execution is via child_process with ffmpeg, that ffmpeg must be on PATH, that it returns an explicit error if ffmpeg is missing rather than failing silently, and that it is detection-only with no modification side effects. This is comprehensive and 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 concise, with each sentence providing essential information: method, requirement, detection-only nature, and suggested user actions. It is front-loaded with the verb and resource, and there is no redundant or filler content.
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?
Given the tool's moderate complexity (external ffmpeg dependency) and absence of annotations, the description is remarkably complete. It explains the execution environment, error behavior, output format (intervals), and typical usage, leaving little ambiguity 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?
The input schema has 100% parameter description coverage, so the description doesn't need to add much. It does not go beyond the schema's details beyond reinforcing defaults and units, which is unnecessary. Baseline of 3 is appropriate given the schema already documents each parameter clearly.
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 'Analyzes a media file's audio for silent stretches' and specifies the method (ffmpeg's silencedetect filter). It explicitly distinguishes from siblings by noting it does not use Premiere's scripting API (which lacks audio-level reading) and by stating it is detection-only, differentiating from editing tools like split_clip and ripple_delete.
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 provides clear usage context: it explains this is the only way to read audio levels in this codebase, notes the ffmpeg requirement, and explicitly suggests pairing with split_clip/ripple_delete/razor_timeline_at_time for removal. This effectively communicates when to use it and how it fits into workflows.
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 burden. It explains the effect of clearContents (true vs false) and implies the source is not modified, but it does not explicitly state that the original sequence is untouched. The behavior is clear enough for a copy operation, though a minor note about non-destructiveness could improve 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 two sentences, front-loaded with the main action, and uses clear formatting (bold for emphasis). Every sentence adds value without redundancy, making it 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?
The description covers the tool's purpose, usage scenario, and parameter behavior well. However, there is no output schema or mention of return value, so the user is left without knowing what the tool returns (e.g., success indicator or new sequence ID). Given the complexity of the operation and no annotations, a brief note on the return would improve completeness, but it's not critical.
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?
Schema coverage is 100%: each parameter (newName, sequenceId, clearContents) has a description. The clearContents description is detailed, explaining the behavior for true/false and the default. The description adds helpful context about preserving settings, enhancing the schema-provided information.
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 copy of a sequence, and explicitly distinguishes it from create_sequence by noting that this method preserves frame rate, resolution, and track layout. This makes the purpose specific and well-differentiated 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 Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit guidance on when to use this tool over create_sequence: 'the reliable way to auto-create a correctly-specced blank target, since create_sequence ignores frame rate.' It also explains the clearContents option for creating an empty copy, giving clear usage instructions.
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 the full burden. It transparently discloses the API limitation: 'Premiere Pro exposes no caption-read API in its scripting DOM, so in practice this returns trackCount:0 / captions:[] even when the sequence HAS a working caption track.' It also documents the captionReadSupported:false flag and explains the meaning of a zero result, which is exemplary. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief yet information-dense. It front-loads the primary purpose, then explains the critical caveat in the next sentence, followed by an alternative approach. Every sentence adds necessary context; there is no fluff.
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 having no output schema, the description thoroughly covers the return format, the failure mode, the flag field, and a workaround. It even preempts misuse by clarifying that a 0 result does not mean no captions. This is complete for such a nuanced 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%—the only parameter (sequenceId) already has a description in the schema: 'Optional sequence ID. Defaults to the active sequence.' The tool description does not add additional parameter semantics, but none are necessary given the schema is clear. 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 opens with a specific verb+resource+return type: 'Reads caption tracks of a sequence, returning each caption clip as { start, end, text } in seconds.' This precisely states what the tool does and even distinguishes it from reading transcriptions by focusing on caption tracks and their structure.
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?
It gives explicit guidance: warns that the tool returns empty results in practice and directs to an alternative: 'To read cue text/timing, parse the source .srt file directly instead.' This clearly explains when not to rely on this tool and what to use instead, satisfying the when/alternative criteria.
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?
Despite no annotations, the description discloses that the operation is read-only and only makes a Premiere request when checkConnection is true, making side effects transparent. No contradiction with any annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, no redundant information, and the structure is logical: first states the general capability, then clarifies the optional parameter's effect. Every word 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?
The description is complete for its purpose: it covers the tool's main outputs and the condition for executing a live check. Since there is no output schema, no additional return information is required.
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?
The single parameter 'checkConnection' is well described in the schema, but the description adds meaning by explaining its effect (runs a live check) and default behavior (fast, non-invasive). This goes beyond the basic boolean type.
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?
Clearly states it reports runtime, bridge status, catalog sizes, and integration surfaces, using the verb 'reports' which specifies the action and the resources. Distinct from sibling tools that operate on project items, sequences, etc.
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?
Explicitly explains when to set checkConnection to true for a live connection check and that otherwise no Premiere request is made, providing clear usage context. Differentiates from other tools that perform direct edits or queries.
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/compimprove/adobe-premiere-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server