Final Cut Pro MCP Server

by elliotttate

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation2/5
Many tools have overlapping or ambiguous purposes, such as 'audio_operations' being vague while 'adjust_volume' and 'audio_fade_management' exist, or 'selection' and 'select_tool' being unclear in distinction. The high tool count exacerbates confusion, with multiple tools like 'add_effect' and 'add_color_correction' potentially overlapping in function, making it difficult for an agent to reliably choose the correct tool without trial and error.
Naming Consistency3/5
The naming is mixed with some consistency in verb_noun patterns like 'add_color_correction' and 'create_compound_clip', but there are deviations such as 'blade' (noun-only), 'navigate' (verb-only), and inconsistent styles like 'audio_fade_management' (noun-heavy) versus 'adjust_volume' (verb_noun). While readable, the lack of a uniform convention across all tools reduces predictability and coherence in the tool set.
Tool Count1/5
With 100 tools, this server is extremely overloaded for a video editing domain, far exceeding the typical well-scoped range of 3-15 tools. Such a high count suggests poor scoping, likely including many redundant or overly granular tools that could overwhelm agents and lead to inefficiency in tool selection and usage, indicating a severe mismatch between scope and implementation.
Completeness5/5
The tool set provides comprehensive coverage for Final Cut Pro editing, including core operations like adding effects, color correction, timeline management, audio controls, and advanced features like AI tools and XML handling. There are no obvious gaps; it supports full CRUD/lifecycle workflows from import to export, with tools for media management, editing, and sharing, ensuring agents can handle most tasks without dead ends.
Average 2.9/5 across 100 of 100 tools scored. Lowest: 1.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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.json to 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?
With no annotations provided, the description carries the full burden of behavioral disclosure but fails entirely. It does not indicate whether operations are read-only or destructive, what permissions are needed, or any side effects like rate limits. The vague phrase 'operations' offers no actionable 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While concise with only three words, the description is under-specified rather than efficiently structured. It lacks front-loaded critical information and wastes its limited space on a tautology that provides no operational value, failing to earn its place with meaningful content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity implied by multiple action types and no annotations or output schema, the description is completely inadequate. It does not explain what the tool does, when to use it, what behaviors to expect, or what results are returned, leaving significant gaps for an AI agent to understand and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage with a clear enum for the 'action' parameter, so the baseline score is 3. The description adds no additional meaning beyond the schema, as it does not explain what the enum values represent or how they differ, but the schema adequately documents the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Audio-specific operations' is a tautology that merely restates the tool name 'audio_operations' without specifying what it actually does. It mentions the domain (audio) but provides no verb or specific action, failing to distinguish it from sibling tools like 'adjust_volume' or 'audio_fade_management'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It does not mention any context, prerequisites, or exclusions, leaving the agent with no information about appropriate usage scenarios compared to other audio-related 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Render the timeline' vaguely implies a processing or output operation but fails to specify critical traits such as whether it's destructive, requires specific permissions, has rate limits, or what the output entails (e.g., file generation, preview). This leaves the agent guessing about the tool's behavior and 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While concise with a single sentence, the description is under-specified rather than efficiently informative. It lacks front-loaded critical details (e.g., what rendering produces), making it ineffective despite its brevity. Conciseness should not come at the cost of clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity implied by sibling tools in a video editing context (e.g., 'export_xml', 'transcode_media'), the description is severely incomplete. With no annotations, no output schema, and a vague purpose, it fails to provide enough context for an agent to understand the tool's role, behavior, or output, making it inadequate for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with a clear enum parameter 'scope' documented as 'Render all or just the selection'. The description adds no additional parameter semantics beyond this, but since the schema is comprehensive, the baseline score of 3 is appropriate as it doesn't need to compensate for gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Render the timeline' is a tautology that essentially restates the tool name 'render' with minimal added context. While it specifies the resource ('timeline'), it lacks specificity about what rendering entails (e.g., generating a video file, preview, or export) and doesn't distinguish it from sibling tools like 'export_xml' or 'transcode_media', which might involve similar output 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a timeline ready), exclusions, or comparisons to sibling tools like 'export_xml' or 'transcode_media', leaving the agent with no context for appropriate 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 burden for behavioral disclosure. 'Selection operations' reveals nothing about whether this is a read-only or mutating operation, what visual feedback occurs, whether selections persist across operations, or any side effects. For a tool that likely modifies application state, this complete lack of behavioral information is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with just two words, this is under-specification rather than effective conciseness. The description fails to communicate essential information and wastes the opportunity to guide the agent. Every word should earn its place, but here the words don't provide meaningful guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's likely importance in a video editing workflow (with many sibling tools for editing operations), the complete lack of annotations, no output schema, and a description that adds almost no value beyond the name makes this description completely inadequate. The agent cannot understand what this tool does, when to use it, or what behavior to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'action' having a clear enum and description. The description adds no parameter information beyond what the schema already provides. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Selection operations' is a tautology that merely restates the tool name 'selection' without specifying what it actually does. It doesn't mention the specific actions available (select_all, deselect_all, select_clip_at_playhead) or what resources are being selected. While the name implies timeline/media selection in a video editing context, the description adds no 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'delete_selection' or 'select_tool' that might be related, nor does it indicate any prerequisites, constraints, or appropriate contexts for selection operations. The agent receives zero usage direction from this 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?
With no annotations provided, the description carries the full burden of behavioral disclosure but offers none. It doesn't indicate whether these operations are read-only or destructive, what permissions might be required, what side effects occur, or what the tool returns. The vague 'operations' gives no insight into 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two words, but this conciseness comes at the cost of being under-specified rather than efficient. Every word earns its place, but there are too few words to be helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity implied by six different action types (create, add_and_edit, edit, extract_from_clip, split, resolve_overlaps), no annotations, and no output schema, the description is completely inadequate. It doesn't explain what captions are, what these operations do, or what to expect as results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage with the action parameter documented as 'Caption action', and the enum values provide specific operations. The description adds no additional meaning beyond what the schema already provides, so it meets the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Caption operations' is a tautology that merely restates the tool name 'captions' without specifying what operations are performed. It doesn't distinguish this tool from sibling tools like 'export_captions', 'import_captions', or 'transcribe_to_captions', nor does it mention the specific actions available through the action parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'export_captions' or 'import_captions', nor does it indicate any context, prerequisites, or exclusions for using this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It fails to explain what 'consolidate' does operationally—whether it merges files, optimizes storage, reorganizes media, or performs another action. It does not mention side effects (e.g., file modification, deletion), permissions required, or output behavior, leaving critical behavioral traits undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is 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 front-loads the core action ('Consolidate media files') but lacks necessary elaboration to be truly helpful. While not verbose, it fails to earn its place by omitting key details, making it minimally adequate in structure but insufficient in content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity implied by 'consolidate' (potentially a mutation operation) and the lack of annotations and output schema, the description is incomplete. It does not explain what the tool does, how it behaves, or what results to expect, leaving significant gaps. For a tool with no structured data to rely on, this description is inadequate 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, meaning no parameters need documentation. The description does not add parameter details, which is acceptable in this case. It implies the tool operates on 'selected items', but since there are no parameters, this does not compensate for missing schema information. A baseline of 4 is appropriate for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Consolidate media files for the selected items' is tautological—it essentially restates the tool name 'consolidate_files' with minimal elaboration. While it specifies the resource ('media files') and target ('selected items'), it lacks specificity about what 'consolidate' entails (e.g., merging, organizing, or optimizing files), making it vague. It does not differentiate from sibling tools like 'merge_clips' or 'synchronize_clips', which might involve 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., needing selected items), exclusions, or comparisons to sibling tools such as 'merge_clips', 'relink_files', or 'transcode_media', which could be related. Without any context, the agent must guess based on the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It fails to do so: it does not indicate whether this is a destructive or non-destructive operation, what permissions or timeline state are required, how it affects existing media, or what the expected outcome is (e.g., changes to timeline structure). The description is too vague to inform the agent about the tool's behavior beyond the basic action implied by 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly addresses the tool's action. It is front-loaded with the core purpose and avoids unnecessary elaboration. However, it is overly terse to the point of under-specification, which slightly detracts from its effectiveness, but it does not waste words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity implied by multiple edit modes and media types, the lack of annotations, and no output schema, the description is incomplete. It does not explain the tool's impact on the timeline, potential side effects, error conditions, or what the agent should expect after invocation. For a tool with nuanced parameters and no structured behavioral hints, the description fails to provide sufficient context for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear enum values and defaults documented for both parameters ('mode' and 'media_type'). The description adds no additional semantic context about these parameters—it does not explain what the modes do (e.g., 'insert' vs. 'append'), how 'media_type' influences the edit, or provide examples. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, but the description does not compensate with any extra insights.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Perform an edit insertion into the timeline' is a tautology that essentially restates the tool name 'edit_insert' with minimal added context. It lacks specificity about what resource is being edited (e.g., clips, media, timeline segments) and does not differentiate from sibling tools like 'insert_placeholder', 'trim', or 'blade', which also perform timeline edits. The verb 'perform an edit insertion' is vague and circular.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, context (e.g., timeline selection state), or sibling tools that might be more appropriate for specific edit types (e.g., 'trim' for adjusting clip boundaries, 'blade' for cutting clips). Without such information, the agent cannot make informed decisions about 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 are provided, so the description carries full burden for behavioral disclosure. 'Zoom the timeline view' gives no information about what the tool actually does behaviorally—whether it's a read-only operation, if it modifies project state, what visual changes occur, or any side effects. It's completely inadequate for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single three-word phrase. While this represents severe under-specification in terms of content, from a pure conciseness perspective it's maximally efficient with zero wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given 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 completely inadequate. It provides minimal information about purpose, no behavioral context, and fails to explain what 'zooming' actually accomplishes in this video editing context. Given the complexity implied by the sibling tools and the lack of structured data, this description leaves the agent with insufficient guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'action' fully documented in the schema with enum values and description. The tool description adds no additional parameter information beyond what the schema already provides, so it meets the baseline score of 3 for adequate coverage through structured data alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Zoom the timeline view' is a tautology that essentially restates the tool name 'zoom_timeline' without adding meaningful specificity. It doesn't distinguish this tool from potential sibling tools that might also manipulate timeline views, nor does it specify what 'zoom' means in this context beyond the obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does 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. The description doesn't mention any context, prerequisites, or exclusions, and with many sibling tools available (like 'navigate', 'go_to_timecode', or 'timeline_history'), there's no indication of when zooming is appropriate versus other timeline manipulation methods.
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. 'Delete markers' implies a destructive mutation, but it doesn't specify if deletions are permanent, reversible (e.g., via undo), require permissions, or have side effects. It lacks details on rate limits, error handling, or what happens upon success/failure, leaving critical behavioral traits 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is overly concise at two words, leading to under-specification rather than efficiency. It lacks front-loaded critical information (e.g., context or risks) and wastes an opportunity to clarify usage in a single sentence. While not verbose, it fails to convey necessary details, making it ineffective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature (implied by 'delete'), no annotations, and no output schema, the description is incomplete. It doesn't address behavioral risks, return values, or how it fits within the sibling tools (e.g., video editing context). For a mutation tool with zero annotation coverage, more context is needed to ensure safe and correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'scope' fully documented in the schema (enum values and description). The description adds no parameter semantics beyond the schema, but with only one parameter and high coverage, the baseline is strong. No compensation is needed, though it doesn't enhance understanding further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete markers' is a tautology that restates the tool name without adding meaningful context. It specifies the verb (delete) and resource (markers) but lacks specificity about what markers are or their context in the sibling tools (e.g., video editing markers). It doesn't distinguish from siblings like 'delete_selection' or clarify what type of markers are being deleted.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing markers to exist), exclusions, or related tools like 'add_marker' or 'delete_selection'. Without context, an agent might misuse it or overlook better options among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. 'Relink media files' implies a mutation operation but reveals nothing about permissions needed, whether it's destructive, what happens to existing links, error conditions, or output format. This leaves critical behavioral traits completely unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just three words with no wasted language. While this conciseness comes at the expense of completeness, the structure is front-loaded and efficiently communicates the core action without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what 'relink' means operationally, what the expected outcome is, or any behavioral characteristics. Given the complexity implied by file system operations and the lack of structured metadata, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage with a clear enum parameter ('original' or 'proxy'), so the description doesn't need to compensate. However, the description adds no additional context about parameter meaning beyond what's already documented in the schema, resulting in the baseline score for adequate schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Relink media files' is a tautology that essentially restates the tool name 'relink_files' without adding meaningful specificity. It doesn't explain what 'relink' means operationally or what resource is being acted upon, making it vague compared to more descriptive sibling tools like 'consolidate_files' or 'transcode_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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools that might involve file operations (like 'consolidate_files', 'import_media', 'transcode_media'), there's no indication of this tool's specific context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It merely lists action names without explaining what each does behaviorally (e.g., 'copy' duplicates content to clipboard, 'cut' removes and copies, 'paste' inserts from clipboard). It doesn't cover side effects, permissions, or response format, making it inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise—a single phrase in parentheses—and front-loaded with the tool name implying the topic. However, it's arguably too brief, bordering on under-specified rather than efficiently informative, as it lacks necessary behavioral details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a tool that performs mutations (clipboard operations imply changes). It fails to explain what the tool returns, error conditions, or dependencies, leaving significant gaps for an agent to use it correctly in a complex editing environment with many siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'action' fully documented in the schema (including enum values). The description adds no parameter-specific semantics beyond what the schema provides—it doesn't explain differences between actions like 'paste' vs. 'paste_as_connected'. 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Clipboard operations (copy, cut, paste)' states the general purpose (clipboard operations) and lists three specific actions, but it's vague about what resource these operations act upon (e.g., timeline selections, media items). It distinguishes from many siblings by focusing on clipboard functionality, but doesn't explicitly differentiate from tools like 'selection' or 'edit_insert' that might involve similar concepts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a selection first), context (e.g., timeline vs. browser), or exclusions. With many sibling tools for editing and manipulation, this lack of usage context leaves the agent to guess when clipboard operations are 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 of behavioral disclosure. 'Open' suggests a UI action, but it doesn't clarify whether this changes application state, requires specific conditions, has side effects, or what happens if the panel is already open. The description lacks essential behavioral context for a zero-parameter UI 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's appropriately sized for a simple tool and front-loads the core action without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a UI-focused tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the keyword editor panel is, what it's used for, or what the expected outcome of opening it is. Given the complexity implied by sibling tools and the lack of structured data, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters and 100% schema description coverage, there are no parameters to document. The description doesn't need to compensate for any schema gaps, so it meets the baseline expectation for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Open the keyword editor panel' is essentially a tautology that restates the tool name 'open_keyword_editor' without adding meaningful context. It doesn't specify what the keyword editor does, what resources it affects, or how it differs from sibling tools like 'add_keyword' or 'keyframes'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With many sibling tools related to keywords, markers, and editing, the description fails to indicate whether this is for creating, editing, or managing keywords, or what specific context triggers its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Rate the selected clip(s)' but doesn't explain what happens—e.g., whether this is a reversible action, if it affects clip visibility or sorting, or if there are permission requirements. For a mutation tool with zero annotation coverage, this is a significant gap in 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence with zero waste. It's front-loaded and to the point, making it easy to parse quickly. Every word earns its place by stating the core action and target without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity as a mutation operation (implied by 'rate'), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like reversibility, permissions, or what the rating affects (e.g., organization, filtering). For a tool that modifies clip state, more context is needed to ensure safe and correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'rating' fully documented in the schema as an enum of 'favorite', 'unfavorite', 'reject'. The description adds no additional meaning beyond this, such as explaining the semantic differences between these ratings or their effects. With high schema coverage, the baseline score of 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Rate the selected clip(s)' states the action (rate) and target (selected clip(s)), but it's vague about what rating entails—whether it's adding metadata, applying a label, or something else. It doesn't differentiate from siblings like 'add_keyword' or 'add_marker', which might serve similar annotation purposes. A more specific purpose would clarify the exact nature of the rating 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With siblings like 'add_keyword' or 'add_marker' that might annotate clips, there's no indication of when rating is preferred—e.g., for quality assessment versus organizational tagging. The description lacks context about prerequisites, such as needing clips selected first, 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. It mentions 'analyze and fix' but doesn't disclose behavioral traits like whether it's destructive, requires specific permissions, has side effects, or operates in batch. This leaves critical gaps for safe and effective use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action, though it could be more structured by including key details upfront. Overall, it's appropriately sized for its simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given 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 vague purpose, the description is incomplete. It doesn't explain what 'analyze and fix' does, what it returns, or how it behaves, making it inadequate for a tool in a complex editing environment with many siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add param info, which is fine here, but it could hint at implicit context (e.g., selection state). Baseline is 4 since zero params reduce the need for semantic details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('Run analyze and fix') and target ('selected clips'), which gives a basic purpose. However, it's vague about what 'analyze and fix' entails—does it detect issues like stabilization, color, or audio? It doesn't differentiate from sibling tools like 'color_correction_nav' or 'detect_beats', which might handle similar analyses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With many sibling tools for editing and correction (e.g., 'color_correction_nav', 'detect_beats', 'auto_reframe'), the description lacks context on prerequisites, specific use cases, or exclusions, leaving the agent to guess.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 states 'Change the clip appearance,' implying a mutation, but doesn't disclose behavioral traits like whether changes are reversible, require specific permissions, affect other clip properties, or have side effects. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action, though it could be more specific to improve clarity without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's mutation nature and lack of annotations or output schema, the description is incomplete. It doesn't explain what 'clip appearance' entails beyond the schema's enum, potential impacts, or return values, leaving significant gaps for an AI agent to understand and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'style' fully documented in the schema as an enum for clip appearance style balancing video thumbnails and audio waveforms. The description adds no additional meaning beyond the schema, so it meets the baseline of 3 where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Change the clip appearance in the timeline' clearly states the action (change) and target (clip appearance), but it's vague about what 'appearance' specifically means. It distinguishes from siblings like 'add_color_correction' or 'add_effect' by focusing on overall appearance rather than specific modifications, but lacks precision on the exact nature of the change.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With many sibling tools related to clip modifications (e.g., 'add_color_correction', 'adjust_volume', 'retime'), the description offers no context for selection, prerequisites, or exclusions, leaving usage 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. It mentions opening a dialog but doesn't disclose behavioral traits like whether this is a read-only operation, if it requires user interaction, what happens on invocation (e.g., modal dialog), or any side effects. The description is minimal and lacks context on how the tool behaves in practice.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded in a single sentence, with no wasted words. It efficiently states the tool's action and parameter options. However, it could be slightly improved by adding context (e.g., specifying the application) without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a dialog-opening tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the dialog does, how it interacts with the user, what the expected outcomes are, or any dependencies. For a tool that likely involves UI interaction, more context is needed to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with a single parameter 'type' that has an enum of 'find' and 'find_and_replace_title'. The description adds minimal semantics by mentioning these options in the text, but it doesn't provide additional meaning beyond what the schema already documents, such as explaining the difference between the two types or their effects.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool opens a dialog for finding or find-and-replace operations in title text, which is a clear purpose. However, it doesn't specify what application or context this is for (e.g., video editing software like Final Cut Pro), and while it distinguishes between 'find' and 'find_and_replace_title', it doesn't explicitly differentiate from sibling tools that might involve text manipulation or searching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, such as having a project open or being in a specific mode, nor does it refer to sibling tools like 'navigate' or 'selection' that might be related. Usage is implied by the action but not explicitly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the action generically. It doesn't disclose behavioral traits such as whether navigation affects playback, requires a timeline selection, has side effects (e.g., moving playhead), or any constraints (e.g., availability based on timeline state), missing key operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words, making it front-loaded and easy to parse. However, it's overly terse, lacking necessary detail for a tool with no annotations, which slightly reduces its effectiveness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It doesn't explain what 'navigate' means in practice, expected outcomes (e.g., cursor movement), or how it interacts with the timeline, leaving significant gaps for a tool with one parameter but critical behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the action parameter fully documented via enum values. The description adds no meaning beyond the schema, as it doesn't explain parameter implications (e.g., what 'jump_to_start' does). 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Navigate through the timeline' states a general purpose but is vague about what 'navigate' entails. It doesn't specify the exact resource (e.g., timeline cursor/playhead) or differentiate from sibling timeline tools like 'go_to_timecode' or 'timeline_history', though it implies movement within a timeline 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites, context (e.g., timeline must be open), or compare to siblings like 'go_to_timecode' for specific timecode jumps, leaving the agent to infer usage from the action parameter alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'share/export' which implies an output operation but doesn't disclose behavioral traits like whether this is destructive, requires specific permissions, has rate limits, or what the output format is. The description adds minimal 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the main action, but it could be more structured by separating 'share' and 'export' concepts. It's concise with zero waste, though slightly ambiguous in phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a tool that performs share/export operations. It doesn't explain what 'share' entails (e.g., file generation, network transfer), what 'export' produces, or any side effects. For a tool with potential complexity, this leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'destination' documented as 'Export destination' with enum values 'default' and 'compressor'. The description adds no additional meaning beyond what the schema provides, such as explaining what 'default' or 'compressor' entail. Baseline 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'share/export the project' which provides a basic verb+resource combination, but it's vague about what 'share' means versus 'export' and doesn't distinguish this from potential sibling tools like 'export_captions' or 'export_xml'. It's not tautological but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'export_captions' or 'export_xml' from the sibling list. The description mentions 'default destination or send to Compressor' but doesn't explain when to choose one over the other or any 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, the description carries the full burden of behavioral disclosure. It states the action is 'Add', implying a mutation, but doesn't cover permissions, reversibility, effects on the clip, or response format. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It's front-loaded with the core action, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavior, side effects, return values, and how it differs from related tools, leaving significant gaps for an AI agent to understand its use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the single parameter 'type' with its enum values. The description doesn't add any meaning beyond this, such as explaining the differences between mask types or their visual effects, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('Add a mask') and target ('to the selected clip'), which provides a basic purpose. However, it doesn't specify what a 'mask' does in this context or distinguish it from similar tools like 'add_effect' or 'adjustment_layer', making it somewhat vague rather than 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a clip selected), exclusions, or compare it to sibling tools like 'add_effect' or 'adjustment_layer', leaving usage 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. It states the action ('add') but doesn't disclose behavioral traits like whether this modifies the timeline destructively, requires specific permissions, or has side effects (e.g., affecting playback). This leaves gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words. It's front-loaded with the core action, making it easy to parse quickly without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity as a mutation operation with no annotations and no output schema, the description is incomplete. It lacks details on behavior, usage context, or expected outcomes, leaving significant gaps for an AI agent to understand how to invoke it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'type' fully documented in the schema as an enum for title types. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add a title to the timeline' clearly states the verb ('add') and resource ('title'), but it's vague about what a 'title' means in this context compared to other timeline elements like markers or effects. It doesn't distinguish this tool from siblings like 'add_marker' or 'add_effect' beyond the resource 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context (e.g., timeline selection), or when other tools might be more appropriate, such as using 'add_marker' for annotations instead of titles.
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 mentions 'control' but doesn't specify if this is read-only, destructive, requires permissions, or has side effects like UI changes. For a tool with an 'action' parameter that includes resets and toggles, more context on behavior is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded and appropriately sized for the tool's complexity, making it easy to parse without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits, return values, or error handling for a tool with multiple action types. For a control tool with potential UI or state changes, more context is necessary for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the 'action' parameter fully documented via enum values in the schema. The description adds no additional meaning beyond implying color board interaction, so it meets the baseline of 3 where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose as 'Control the color board for color grading,' which identifies the target resource (color board) and general action (control). However, it's vague about what 'control' entails compared to siblings like 'color_correction_nav' or 'match_color,' lacking specific differentiation. It's not tautological but doesn't provide 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/5
Does 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. With siblings like 'color_correction_nav' and 'match_color' that might overlap in color-related tasks, there's no explicit or implied context for selection. This leaves the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the action without disclosing behavioral traits. It doesn't mention if this is destructive, requires specific permissions, affects other clips, or has side effects like updating timelines, which is inadequate for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded and clear in its brevity, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given 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 is incomplete for a tool that likely mutates timeline clips. It lacks details on behavior, effects, or return values, leaving significant gaps in understanding how the tool operates in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents parameters. The description adds no meaning beyond the schema, as it doesn't explain 'nudge' in terms of direction or large amounts. Baseline 3 is appropriate since the schema handles parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('nudge') and target ('selected clip(s)'), but it's vague about what 'nudge' means in this context—likely moving clips in a timeline, but not explicitly stated. It doesn't differentiate from siblings like 'trim' or 'move', which might have overlapping functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'trim', 'move', or timeline adjustments. The description lacks context about prerequisites (e.g., needing clips selected) or exclusions, leaving usage 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. It states the tool 'switches' to another tool, implying a state change, but doesn't disclose behavioral traits like whether this requires specific permissions, what happens to the current editing state, or if it's reversible. For a mutation tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded and appropriately sized for a simple tool, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a tool-switching operation with no annotations or output schema), the description is incomplete. It doesn't explain what 'editing tool' refers to, how the switch impacts the user interface or editing workflow, or what the expected outcome is. For a tool that likely changes application state, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'tool' fully documented in the schema (including enum values). The description adds no meaning beyond what the schema provides—it doesn't explain what the tools in the enum do or how switching affects the editing environment. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Switch to a specific editing tool' clearly states the action (switch) and target (editing tool), but it's vague about what 'editing tool' means in this context. It doesn't distinguish this tool from sibling tools like 'blade' or 'trim' that might also involve tool selection or editing functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. Given the many sibling tools (e.g., 'blade', 'trim', 'selection'), it's unclear if this is for UI tool switching, activating specific editing modes, or something else. The description lacks context about prerequisites or when-not-to-use 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 the tool sets playback speed but doesn't disclose behavioral traits such as whether it requires specific permissions, affects current playback, has side effects (e.g., on audio pitch), or provides feedback. This is inadequate for a mutation tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded and appropriately sized for a simple tool, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation operation with no annotations and no output schema), the description is incomplete. It lacks details on behavior, side effects, or return values, which are critical for an AI agent to use it correctly. The high schema coverage doesn't compensate for these gaps in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the 'speed' parameter fully documented in the schema (including enum values like '0.5x' to '32x' and negative values). The description adds no meaning beyond what the schema provides, so it meets the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Set the playback speed/rate' clearly states the action (set) and resource (playback speed/rate), but it's vague about what exactly is being controlled (e.g., a clip, timeline, or media player). It doesn't distinguish from sibling tools like 'playback' or 'rate_clip', which might have overlapping functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. Sibling tools include 'playback' and 'rate_clip', which could be related, but the description doesn't mention them or specify contexts like editing vs. playback modes. Usage is implied only 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 are provided, so the description carries the full burden. 'Trim clip edges' implies a destructive or mutative operation on media, but it doesn't disclose behavioral traits like whether changes are reversible, if it requires specific permissions, what happens to adjacent clips, or any rate limits. It lacks essential context for safe and effective use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at three words, with zero wasted language. It's front-loaded with the core action ('Trim'), making it easy to scan. Every word earns its place, though this brevity contributes to vagueness in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of media editing (implied by sibling tools) and the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'trimming' entails operationally, what the tool returns, or how it interacts with other editing functions, leaving significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'action' fully documented in the schema's enum and description. The tool description adds no additional meaning beyond what the schema provides, such as examples or edge cases. With high schema coverage, 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Trim clip edges' states the general action (trimming) and target (clip edges), but it's vague about what 'edges' means and doesn't specify how it differs from sibling tools like 'blade', 'retime', or 'change_duration'. It provides a basic purpose but lacks specificity and 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/5
Does 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. With many sibling tools that might overlap (e.g., 'blade' for cutting, 'retime' for speed adjustments), there's no indication of context, prerequisites, or exclusions for using '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?
No annotations are provided, so the description carries the full burden. It states the tool performs 'undo or redo the last action', implying mutation but without details on permissions, reversibility, or effects. It lacks behavioral context such as what constitutes an 'action', whether it's limited to specific operations, or if there are constraints like availability based on history state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence ('Undo or redo the last action.') that is front-loaded and wastes no words. It directly conveys the core function without unnecessary elaboration, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter with enum) and no annotations or output schema, the description is minimally adequate. It states what the tool does but lacks completeness in usage guidelines, behavioral details, or output expectations. For a mutation tool with no structured support, it should provide more context to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with a single parameter 'action' clearly documented as an enum for 'undo' or 'redo'. The description adds no additional meaning beyond this, as it only restates the parameter's purpose. With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose ('Undo or redo the last action'), which is clear but vague. It specifies the verb ('undo' or 'redo') but doesn't clarify what 'action' refers to in context (e.g., editing operations in a video timeline). It doesn't distinguish from siblings, as no other tools in the list handle undo/redo 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., having a recent action to undo/redo), exclusions, or related tools. Given the sibling list includes tools like 'timeline_history', there's no explicit comparison or context for 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 provided, the description carries full burden for behavioral disclosure. It states this is an 'add' operation (implying creation/mutation) but doesn't clarify permissions needed, whether it's destructive to existing effects, how it integrates with the timeline, or what visual feedback to expect. For a mutation tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that immediately conveys the core functionality without unnecessary words. It's perfectly front-loaded and wastes no space while being completely understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficiently complete. It doesn't address what happens after adding the effect, whether there are limitations or side effects, how to verify success, or what the user experience implications are. The context demands more behavioral disclosure than provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'type' having a clear description and enum values in the schema. The description doesn't add any parameter information beyond what's already documented in the schema, so it meets the baseline for adequate but not exceptional parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add a color correction effect') and target resource ('to the selected clip'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'add_effect' or 'color_board', but the specificity of 'color correction effect' provides reasonable distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like 'add_effect' (general effect addition), 'color_board' (specific color correction interface), or 'match_color' (color matching). The description assumes context about having a selected clip but offers no explicit usage criteria 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 for behavioral disclosure. It states this adds an effect but doesn't specify what kind of effect (beyond the 'type' parameter), whether it modifies clips destructively, what permissions are needed, or what happens if multiple clips are selected. This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's appropriately sized for a simple tool and front-loads the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what a 'default effect' entails, how it interacts with selected clips, or what the result looks like. Given the complexity implied by sibling tools and lack of structured data, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'type' fully documented in the schema as an enum of 'video' or 'audio'. The description adds no additional parameter semantics beyond implying effects are added to clips, so it meets the baseline of 3 where 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add') and target resource ('default effect to the selected clip(s)'), making the purpose immediately understandable. However, it doesn't differentiate this tool from similar sibling tools like 'add_color_correction' or 'add_transition', which presumably also add effects to 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools that also modify clips (e.g., 'add_color_correction', 'add_transition'), there's no indication of what makes 'add_effect' distinct or when it should be preferred over other effect-adding tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the action without behavioral details. It doesn't disclose whether this is a destructive edit, permission requirements, how it affects clip metadata, or error conditions (e.g., invalid group numbers). The mention of 'pre-configured' groups adds minimal 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('Apply a keyword group') and includes essential context ('pre-configured in FCP's keyword editor'). There is no wasted verbiage or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral impact (e.g., whether changes are reversible), expected outcomes, or error handling. The context about pre-configured groups is helpful but insufficient for full agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the 'group' parameter's type, range, and purpose. The description adds no additional parameter semantics beyond implying keyword groups are numbered 1-9, which the schema already specifies. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Apply a keyword group') and target ('to the selected clip(s)'), with specific context about FCP's keyword editor. It distinguishes from siblings like 'add_marker' or 'add_color_correction' by focusing on keywords, but doesn't explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It mentions keyword groups are pre-configured in FCP's keyword editor, but doesn't specify prerequisites (e.g., clips must be selected) or compare to other tagging/metadata 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool adds a marker but doesn't disclose behavioral traits like whether it requires specific permissions, if it's undoable, what happens on error, or any side effects (e.g., opening an editor for 'standard_and_edit'). This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any fluff. It's front-loaded and wastes no words, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a mutation tool with no annotations and no output schema, the description is incomplete. It lacks information on behavioral context (e.g., success/failure responses, side effects) and doesn't compensate for the absence of structured data, making it inadequate for safe and effective use by an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the parameter 'type' fully documented in the schema (including enum values and a note about 'standard_and_edit'). The description adds no additional parameter semantics beyond what the schema 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add a marker') and the context ('at the current playhead position'), which is specific and unambiguous. It distinguishes from siblings like 'delete_markers' by focusing on creation, though it doesn't explicitly differentiate from other marker-related tools if any existed in the sibling list (none are present).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a timeline open), exclusions, or compare it to other marker-related operations, leaving the agent to infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states what the tool does without behavioral details. It doesn't disclose whether this is a destructive operation, if it requires specific permissions, what the response looks like, or any side effects (e.g., changes are immediate and undoable via 'undo_redo').
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits, error conditions, or what success looks like, leaving significant gaps for an agent to operate effectively in a complex editing environment with many sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'action' fully documented in the schema with enum values. The description adds no additional parameter semantics beyond implying volume adjustment, so it meets the baseline for high schema coverage without compensating value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('adjust') and resource ('audio volume of the selected clip'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'audio_fade_management' or 'audio_operations', which might have overlapping functionality in the audio domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a clip selected), exclusions, or how it relates to other audio tools in the sibling list, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It hints at 'advanced controls' and 'managing' but doesn't clarify if this is a destructive operation, requires specific permissions, has side effects, or details the response format. This is inadequate for a tool with potential audio modifications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the key information ('Advanced audio fade controls') without any wasted words. It's appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It lacks behavioral details (e.g., mutability, side effects) and doesn't explain return values, which is insufficient for a tool that modifies audio fades in a professional editing context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the 'action' parameter with enum values and descriptions. The description adds no additional parameter semantics beyond implying general fade management, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Advanced audio fade controls for managing fade handles and crossfades,' specifying both the resource (audio fades) and actions (managing fade handles and crossfades). However, it doesn't explicitly differentiate from sibling tools like 'audio_operations' or 'adjust_volume,' which might also handle audio adjustments, keeping it from 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions 'managing fade handles and crossfades' but doesn't specify contexts, prerequisites, or exclusions, leaving the agent to infer usage from the parameter enum 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 behavioral disclosure. It states the tool 'Set[s]' a mode, implying a mutation or configuration change, but does not disclose any behavioral traits such as permissions required, whether changes are reversible, side effects on other components, or error conditions. This is inadequate for a tool that likely alters editing state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without any wasted words. It is front-loaded with the core action and purpose, making it easy to understand at a glance. Every part of the sentence contributes essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of audio/video editing tools and the lack of annotations and output schema, the description is incomplete. It does not explain what happens after setting the mode (e.g., confirmation, error messages, or impact on subsequent edits), nor does it cover behavioral aspects like permissions or side effects. For a tool that likely changes system state, this leaves significant gaps in understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'mode' fully documented in the schema (including enum values: 'both', 'video_only', 'audio_only'). The description adds no additional semantic context beyond implying the parameter controls 'which components are affected by edits.' Since the schema does the heavy lifting, 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Set the audio/video edit mode to control which components are affected by edits.' It specifies the verb ('Set') and resource ('audio/video edit mode'), and explains the functional outcome ('control which components are affected by edits'). However, it does not explicitly differentiate from sibling tools like 'audio_operations' or 'video_output', which might have overlapping functions, so it misses the highest 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, exclusions, or specific contexts for application. Given the many sibling tools in this audio/video editing server, such as 'adjust_volume' or 'color_correction_nav', the lack of usage differentiation is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool 'cuts/splits' clips, implying a destructive or mutative operation, but doesn't disclose behavioral traits such as whether changes are reversible, what permissions are needed, or how it interacts with the timeline. This is a significant gap for a tool that modifies content.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('Blade (cut/split) clips') and condition ('at the playhead position'). There is no wasted text, making it highly concise and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a video editing tool that performs clip splitting, the description is incomplete. No annotations or output schema are provided, and the description lacks details on behavioral aspects like mutability, error conditions, or result format. This leaves gaps for an AI agent to use the tool effectively in a rich editing context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'all' fully documented in the schema. The description doesn't add any meaning beyond the schema, which already explains the parameter's effect. This meets the baseline of 3 since the schema handles the parameter semantics adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('cut/split clips') and the condition ('at the playhead position'), which is specific and actionable. However, it doesn't explicitly differentiate from sibling tools like 'break_apart_clip' or 'trim', which might have overlapping functionality in video editing contexts, 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'break_apart_clip' or 'trim' from the sibling list. It mentions the playhead position but doesn't specify prerequisites, exclusions, or comparative use cases, 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.
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. It mentions four specific actions but doesn't explain what each action does behaviorally (e.g., what 'collapse_to_spine' actually means, whether changes are destructive, what permissions are needed, or what the expected outcomes are). This leaves significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just one sentence that efficiently covers the tool's main functionality. Every word earns its place, and the structure is front-loaded with the primary purpose immediately clear. There's zero wasted verbiage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of video editing operations and the lack of both annotations and output schema, the description is insufficiently complete. It doesn't explain what a 'connected storyline' is, what 'spine' refers to, what happens after each action, or what errors might occur. For a tool with four distinct actions in a professional editing context, more contextual information is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage with a well-documented enum parameter, so the baseline is 3. The description adds some context by mentioning 'from selection' for creation and referring to 'storyline clips' for collapse/lift actions, which provides additional semantic meaning beyond the schema's technical description of 'action' as 'Storyline action'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('create', 'collapse', 'lift') and resources ('connected storyline', 'storyline clips'), making it easy to understand what the tool does. However, it doesn't explicitly distinguish this tool from its many siblings in the video editing context, though the specific focus on storylines provides some implicit 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. While it mentions 'from selection' for creation, it doesn't explain when to choose this over other editing tools like 'create_compound_clip' or 'merge_clips', nor does it specify prerequisites or exclusions for the different actions.
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 mentions two actions ('delete' and 'replace with a gap'), implying mutation, but does not specify permissions needed, whether changes are reversible, or what happens to adjacent clips. For a destructive tool with zero annotation coverage, this is a significant gap in 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence: 'Delete selected clips or replace with a gap.' It is front-loaded with the core action, has zero wasted words, and is appropriately sized for a tool with one parameter. Every part of the sentence contributes directly 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/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature (implied by 'delete'), lack of annotations, and no output schema, the description is incomplete. It does not cover behavioral aspects like side effects, error conditions, or return values. For a mutation tool in a media editing context, more context is needed to ensure safe and correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'mode' parameter fully documented in the schema's enum description. The tool description does not add any parameter details beyond what the schema provides, such as explaining the implications of each mode. With high schema coverage, the baseline score of 3 is appropriate, as the description adds no extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Delete selected clips or replace with a gap.' It specifies the verb ('delete' or 'replace') and resource ('selected clips'), making it easy to understand. However, it does not explicitly differentiate from sibling tools like 'delete_markers' or 'trim', which might handle similar deletion operations in different contexts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, context (e.g., timeline editing), or compare with siblings like 'delete_markers' or 'trim'. This lack of usage context leaves the agent to infer applicability based on the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool 'find[s] and manage[s]' duplicates, implying read and write operations, but doesn't disclose behavioral traits like whether changes are destructive, permission requirements, or side effects (e.g., 'make_unique' creates copies). The description lacks context on what 'manage' entails beyond the parameter hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. It wastes no words but could be slightly more structured (e.g., separating finding vs. managing). Every part earns its place, though it's brief given the lack of additional context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (1 parameter, 100% schema coverage, no output schema, no annotations), the description is minimally adequate. It states the purpose but lacks behavioral details, usage guidelines, and output expectations. It's complete enough for basic understanding but leaves gaps for effective agent use without schema consultation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the 'action' parameter fully documented in the schema (enum values and descriptions). The description adds no parameter semantics beyond what the schema provides—it doesn't explain how actions relate to 'find and manage' or provide usage examples. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Find and manage duplicate clips in the browser/timeline.' It specifies the verb ('find and manage') and resource ('duplicate clips'), and distinguishes it from siblings by focusing on duplicate detection. However, it doesn't explicitly differentiate from similar tools like 'find' or 'selection' beyond the duplicate-specific focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions 'browser/timeline' context but doesn't specify prerequisites, exclusions, or compare it to sibling tools like 'find' or 'selection' for clip management. Usage is implied through the action parameter but not explained in the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'Get all events' but doesn't specify if this is a read-only operation, what format the events are returned in, whether there are pagination or rate limits, or any error conditions. This leaves significant gaps for an agent to understand how to use it effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It is front-loaded with the core purpose and efficiently conveys the essential information without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given 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 is incomplete. It doesn't explain what 'events' are in this context, how they are returned, or any behavioral aspects like permissions or limitations. For a tool with no structured support, this leaves too much undefined for reliable agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with 'library_name' clearly documented. The description adds no additional meaning beyond the schema, such as examples or constraints on the library name. Since the schema does the heavy lifting, 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get all events') and resource ('within a specific library'), making the purpose immediately understandable. However, it doesn't distinguish this tool from sibling tools like 'get_libraries' or 'get_projects', which also retrieve data but different types, so it doesn't fully differentiate from 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_projects' or 'find', nor does it mention any prerequisites or exclusions. It simply states what the tool does without 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 of behavioral disclosure. It states the action ('Navigate focus') but doesn't explain what 'focus' entails (e.g., UI changes, selection state), potential side effects, or any prerequisites. This leaves significant gaps in understanding 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste—it directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to understand at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given 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 is incomplete. It doesn't address what happens after navigation (e.g., UI feedback, error conditions) or how it interacts with other tools. For a tool that likely changes UI state, more context is needed to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'panel' parameter clearly documented as 'Panel to focus' and an enum list provided. The description adds no additional meaning beyond this, so it meets the baseline of 3 where 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Navigate focus') and target ('to a specific panel'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from potential alternatives like 'toggle_panel' or 'navigate' among the sibling tools, which would require more specificity for a score of 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'navigate' and 'toggle_panel' present, there's no indication of how this tool differs in context or when it should be preferred, leaving usage ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('Import') but does not describe what happens during import (e.g., whether it opens a dialog, modifies projects, or requires specific permissions). This leaves key behavioral traits unspecified 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It is front-loaded with the core action and resource, making it easy to parse quickly without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a mutation tool (importing files) with no annotations and no output schema, the description is incomplete. It lacks details on behavioral outcomes, error handling, or what the import entails (e.g., project modifications), which are critical for an agent to use it effectively in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the parameter 'file_path' fully documented in the schema. The description does not add any additional meaning or context beyond what the schema provides, such as file format details or import behavior, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Import') and the resource ('an FCPXML file into Final Cut Pro'), providing a specific verb+resource combination. However, it does not differentiate from sibling tools like 'import_media' or 'import_captions', which handle different import types, so it lacks explicit sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., having Final Cut Pro open), exclusions, or comparisons to sibling import tools, leaving the agent to infer usage from context 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. It mentions 'insert' implies a mutation, but fails to disclose critical behavioral traits such as permissions needed, whether the insertion is reversible, how it affects existing timeline content, or any rate limits. This leaves significant gaps for an agent to understand 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without any fluff. It is front-loaded and appropriately sized, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral aspects, output format, error handling, or how it integrates with other timeline operations, leaving the agent with insufficient context for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'type' fully documented in the schema. The description adds no additional meaning beyond the schema, such as explaining the difference between 'placeholder' and 'gap' clips or their use cases. Baseline score of 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('insert') and resource ('placeholder or gap clip into the timeline'), making the purpose understandable. However, it doesn't explicitly distinguish this tool from similar timeline editing tools like 'edit_insert' or 'trim' among the many siblings, which prevents 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With numerous sibling tools like 'edit_insert' and 'trim' that might handle timeline modifications, there's no indication of specific contexts, prerequisites, or exclusions for inserting placeholders or gaps.
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 mentions actions but doesn't disclose behavioral traits such as whether operations are destructive, require specific permissions, affect multiple clips, or have side effects. The description is minimal and lacks context beyond the basic actions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste—every word contributes to understanding the tool's purpose. It's appropriately sized and front-loaded with key actions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given 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 single parameter with full schema coverage, the description is incomplete. It lacks details on behavioral traits, usage context, and expected outcomes, which are crucial for a tool that performs multiple actions on clips in a complex environment with many siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'action' fully documented in the schema via enum values. The description adds no additional meaning beyond implying the parameter relates to effects/attributes on clips, matching the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs (copy, paste, remove) and resources (effects and attributes on clips). It distinguishes from many siblings (e.g., add_effect, remove_effects is a subset here), but doesn't explicitly differentiate from tools like effect_presets or clipboard that might overlap in 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools like add_effect, remove_effects, clipboard, and effect_presets, there's no indication of context, prerequisites, or exclusions for choosing manage_effects over others.
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 mentions 'AI-powered' and 'neural network-based tracking,' hinting at computational intensity, but lacks details on permissions, side effects (e.g., whether it modifies media), performance characteristics, or error handling. For a tool with AI components, this is a significant gap in 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences that directly address the tool's function. It's front-loaded with the core purpose and avoids unnecessary fluff. However, the second sentence slightly repeats the first ('tracking' is mentioned twice), preventing a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given 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 single parameter with full schema coverage, the description is minimally adequate. It covers the high-level purpose but lacks details on behavioral traits, usage context, or output expectations. For an AI-powered tool in a complex editing environment, this leaves gaps in helping the agent understand its role fully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the action parameter's enum values well-documented in the schema. The description adds no additional parameter semantics beyond implying general tracking/segmentation context. This meets the baseline of 3 since the schema does the heavy lifting, but the description doesn't compensate with extra insights like default behaviors or inter-parameter dependencies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'AI-powered object tracking and segmentation mask controls' and 'Uses neural network-based tracking to follow objects across frames.' It specifies the verb (tracking/segmentation controls) and resource (objects across frames), but doesn't explicitly differentiate from sibling tools like 'add_mask' or 'clip_appearance' that might involve similar visual manipulation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description mentions tracking and segmentation controls but doesn't specify scenarios, prerequisites, or exclusions. With many sibling tools for visual editing (e.g., 'add_mask', 'color_correction_nav'), the lack of usage context leaves the agent to guess based on the action parameter alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool opens an inspector but doesn't disclose behavioral traits like whether this is a read-only view, requires specific permissions, affects project state, or has UI implications. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's action without unnecessary words. It's appropriately sized and front-loaded, with zero wasted content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 0 parameters, the description is minimal. While concise, it lacks completeness for a tool that likely interacts with project settings—it doesn't explain what the inspector does, whether changes can be made, or what happens after opening. For a tool in a complex media editing context, this is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description doesn't need to add parameter semantics, and it correctly doesn't mention any parameters, earning a baseline score of 4 for this context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool opens a project properties/settings inspector, which is a clear verb+resource combination. However, it doesn't differentiate from sibling tools like 'new_project', 'duplicate_project', or 'snapshot_project' that also involve project operations. The purpose is understandable but lacks sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With many sibling tools related to project management (e.g., 'new_project', 'duplicate_project'), the description offers no context about prerequisites, timing, or exclusions for opening project properties.
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 states a mutation ('Rename') but doesn't disclose behavioral traits like permission requirements, whether changes are reversible, or how renaming affects other properties. 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with zero wasted words. It's front-loaded and efficiently communicates the core action, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with no annotations, no output schema, and 0 parameters, the description is incomplete. It lacks behavioral context (e.g., side effects, error conditions) and doesn't compensate for the missing structured data, making it inadequate for safe use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add param info, but that's appropriate here, earning a baseline score above minimum.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('Rename') and target ('the selected clip'), which is clear but generic. It doesn't differentiate from other clip-modification siblings like 'rate_clip' or 'change_duration', leaving purpose somewhat 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a clip selected) or exclusions, leaving usage context implied at best.
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. While 'Set' implies mutation, the description doesn't disclose whether this requires specific permissions, whether changes are reversible, what happens to existing roles, or what the expected outcome looks like. For a mutation tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core purpose without unnecessary words. It's appropriately front-loaded with the essential information and wastes no space on redundant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'selected clip' means contextually, what visual or functional changes result from role assignment, or whether there are constraints on which clips can have roles set. The description leaves too many behavioral questions unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'role' fully documented in the schema with enum values. The description adds no additional parameter information beyond what the schema provides, which meets the baseline expectation when schema coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set') and target resource ('role of the selected clip'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'clip_appearance' or 'rename_clip', but the specificity of 'role' assignment provides reasonable distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools that might modify clip properties (like 'clip_appearance', 'rename_clip', 'rate_clip'), there's no indication of when role assignment is appropriate versus other clip modifications.
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 mentions 'advanced speed editing tools' but fails to detail critical aspects like whether this tool modifies clips destructively, requires specific permissions, has rate limits, or what the expected output or side effects are. This is a significant gap for a tool that likely performs mutations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the key information without any wasted words. It directly states the tool's purpose and scope, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, and the tool's likely complexity (involving speed editing with multiple action types), the description is insufficient. It doesn't explain behavioral traits, return values, or error conditions, leaving the agent with incomplete context for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'action' parameter fully documented via enum descriptions. The tool description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline score of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Advanced speed editing tools for creating speed ramps and custom speed segments,' specifying the verb ('editing') and resource ('speed ramps and custom speed segments'). However, it doesn't differentiate from sibling tools like 'set_playback_speed' or 'retime,' which may have overlapping functionality, preventing a score of 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'set_playback_speed' or 'retime.' It lacks explicit context, prerequisites, or exclusions, leaving the agent to infer usage based on the general purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states the tool duplicates a project with optional settings, but doesn't mention whether this is a destructive operation, requires specific permissions, or how it handles errors. For a mutation tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('duplicate the current project') and adds optional details. It avoids unnecessary fluff, though the mention of settings without parameters could be slightly confusing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., side effects, error handling) and doesn't explain what the tool returns, leaving gaps in understanding how to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description adds value by hinting at optional settings like resolution and frame rate, which might be relevant if parameters were present, but since there are none, this is slightly extraneous but not harmful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('duplicate') and resource ('the current project'), making the purpose evident. It doesn't explicitly differentiate from siblings like 'snapshot_project' or 'new_project', but the verb 'duplicate' implies creating a copy of an existing project rather than a new empty one or a snapshot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'snapshot_project' or 'new_project'. The description mentions optional settings but doesn't clarify prerequisites, such as requiring an open project or specific 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. While 'create and manage' implies mutation capabilities, it lacks details on permissions, side effects (e.g., whether it modifies existing clips), or operational constraints (e.g., if it requires a selection or specific mode). The description is too vague to inform the agent adequately about 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded with the core functionality ('Create and manage anchored storyline spines') and adds clarifying context ('for organizing connected clips'). Every part of the sentence contributes meaning, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (managing storyline spines) and lack of annotations or output schema, the description is minimally adequate. It covers the basic purpose but misses details on behavior, usage context, and output expectations. With no output schema, the agent is left guessing about return values, though the description's focus on purpose rather than results is acceptable for a baseline.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'action' parameter fully documented via its enum and description. The tool description does not add any parameter-specific information beyond what the schema provides, such as clarifying the 'selection' context for 'create' or explaining the editing modes. Thus, it meets the baseline score of 3, as the schema handles the parameter semantics effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Create and manage anchored storyline spines for organizing connected clips.' It specifies the verb ('create and manage'), resource ('anchored storyline spines'), and function ('organizing connected clips'). However, it doesn't explicitly differentiate from sibling tools like 'create_storyline' or 'create_compound_clip', which prevents 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools related to editing and organizing clips (e.g., 'create_storyline', 'create_compound_clip', 'timeline_history'), there is no indication of specific contexts, prerequisites, or exclusions for using anchored_storyline. This leaves the agent without clear usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'controls' and 'navigates', implying it's a read-only or low-risk operation, but doesn't clarify if it requires specific permissions, has side effects (e.g., modifying video files), involves rate limits, or what the response looks like. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior and safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with two sentences: the first sets the overall purpose, and the second specifies the navigation aspect. Every sentence earns its place by adding value, and it's front-loaded with the core functionality. There's no wasted verbiage or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (controlling an AI editor), lack of annotations, and no output schema, the description is minimally adequate. It covers the purpose but lacks details on behavior, usage context, and output. It doesn't fully compensate for the missing structured data, leaving gaps in understanding how to effectively use the tool in practice.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'action' parameter fully documented in the schema itself (enum values and descriptions). The description doesn't add any meaning beyond what the schema provides—it doesn't explain parameter usage, constraints, or examples. With high schema coverage, the baseline score of 3 is appropriate, as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Control the AI-powered Cinematic mode editor for iPhone Cinematic video. Navigate between AI focus/framing decisions.' It specifies the verb ('control', 'navigate'), resource ('Cinematic mode editor'), and scope ('iPhone Cinematic video'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'auto_reframe' or 'object_tracking', which might have overlapping video editing functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions 'navigate between AI focus/framing decisions', but doesn't specify prerequisites, exclusions, or compare it to sibling tools like 'auto_reframe' (which might handle automated reframing) or 'object_tracking' (which might involve tracking objects in video). There's no explicit when-to-use or 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, so the description carries the full burden of behavioral disclosure. It states the action ('Close') but does not explain what closing entails—whether it saves changes, requires confirmation, affects other operations, or has side effects. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It is front-loaded and appropriately sized for a simple tool, earning full marks for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation with potential side effects), lack of annotations, and no output schema, the description is incomplete. It fails to explain behavioral aspects like what 'close' does, whether it's reversible, or what happens to unsaved changes, leaving significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the schema description coverage is 100%, so no parameter information is needed. The description does not add parameter details, which is appropriate, but it also does not compensate for any gaps, so it meets the baseline for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Close') and the resource ('the current library'), making the purpose specific and understandable. However, it does not differentiate this tool from potential alternatives or explain what 'close' means in this context, 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description lacks context about prerequisites, consequences, or sibling tools, leaving the agent without usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool changes display settings, implying a mutation, but doesn't clarify if this is reversible, requires specific permissions, affects other tools, or has side effects like performance impacts. This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words, clearly front-loading the core purpose. It's appropriately sized for a simple tool with one parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter, no output schema, no annotations), the description is minimally adequate. It states what the tool does but lacks behavioral details and usage context, making it incomplete for safe and effective use despite the simple schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'channel' fully documented via enum values. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline of 3 for high schema coverage without extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Change') and target ('viewer color channel display'), providing a specific verb+resource combination. However, it doesn't differentiate this tool from potential sibling tools like 'color_board' or 'color_correction_nav' that might also affect color display, missing full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as the sibling tools 'color_board' or 'color_correction_nav'. There's no mention of prerequisites, context, or exclusions, leaving usage entirely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions actions like 'toggle_all_off' and copying from previous clips, but doesn't explain critical details: whether changes are destructive, if permissions are required, how errors are handled, or what happens if no previous clips exist. For a tool that modifies color corrections, this lack of transparency 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core functionality: navigating and applying color corrections. Every word earns its place, with no redundant or vague language. It's appropriately sized for the tool's complexity, making it easy to scan and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one well-documented parameter but no annotations or output schema, the description is minimally complete. It covers the basic purpose but lacks details on behavior, error handling, and output. For a tool that performs actions like toggling corrections and copying from other clips, more context on side effects and results would be helpful, though the schema mitigates some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'action' parameter fully documented in the enum description. The tool description doesn't add any meaning beyond what the schema provides, such as clarifying edge cases or usage examples. Since the schema does the heavy lifting, a baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Navigate between color corrections on a clip and apply corrections from previous clips.' It specifies the verb ('navigate' and 'apply') and resource ('color corrections'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'color_board' or 'match_color', which might have overlapping functionality, 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, such as needing a clip with color corrections, or compare it to siblings like 'color_board' for manual adjustments or 'match_color' for copying colors. Without such context, users may struggle to select the right tool in practice.
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 states the tool is 'AI-powered' and performs 'automatic beat detection,' implying it's a read-only analysis tool, but doesn't clarify if it modifies audio, requires specific permissions, has rate limits, or what the output entails (e.g., beat positions as data or visual markers). For a tool with potential audio processing, this is a significant gap in 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with two sentences: the first states the overall purpose, and the second elaborates on the analysis action. Every sentence adds value without redundancy, making it front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (AI analysis with two actions), no annotations, and no output schema, the description is minimally adequate. It covers the basic purpose but lacks details on behavior, output format, and usage context. This leaves gaps for an agent to fully understand how to invoke and interpret results, especially without annotations to fill in safety or operational traits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'action' parameter fully documented via enum values ('detect' and 'toggle_beat_grid') and descriptions. The description adds no additional parameter semantics beyond what the schema provides, such as explaining the differences between actions in more detail. 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'AI-powered automatic beat detection and beat grid for music/audio clips' with the specific action 'Analyzes audio to find beat positions.' It uses specific verbs ('detect,' 'analyzes') and identifies the resource ('music/audio clips'). However, it doesn't explicitly differentiate from sibling tools like 'audio_operations' or 'analyze_and_fix,' which might have overlapping functions in audio analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions the action but doesn't specify prerequisites, context (e.g., whether it requires selected audio clips), or exclusions. With many sibling tools in audio and analysis categories, this lack of differentiation leaves usage 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 mentions 'save and manage' but does not specify whether this requires permissions, if changes are destructive, what happens to existing presets, or the response format. For a tool with mutation capabilities and no annotations, this is a significant gap in 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. Every part of the sentence contributes directly to understanding the tool's function, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter with full schema coverage but no annotations or output schema, the description is minimally adequate. It covers the basic purpose but lacks details on behavioral traits, usage context, and output, which are important for a tool that likely involves mutations and management operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the 'action' parameter fully documented in the schema via its enum and description. The tool description does not add any parameter details beyond what the schema provides, so it meets the baseline score of 3 for adequate but not additive semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Save and manage effect presets for color corrections, video effects, and audio effects,' which specifies the verb ('save and manage'), resource ('effect presets'), and scope ('color corrections, video effects, and audio effects'). It does not explicitly differentiate from sibling tools like 'manage_effects' or 'color_correction_nav,' but the focus on presets provides reasonable distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or comparisons to sibling tools such as 'manage_effects' or 'add_effect,' leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the action without behavioral details. It does not disclose what 'export' entails (e.g., file format, destination, permissions required, or if it's destructive), making it insufficient for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words, clearly front-loading the core action. It is appropriately sized for a simple tool with no parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavior, output format, or error conditions, which are critical for an export operation. The context signals indicate simplicity, but the description does not compensate for missing structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so no parameter information is needed. The description does not add or detract from parameter semantics, meeting the baseline for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Export') and the resource ('captions from the current project'), making the purpose understandable. However, it does not differentiate from sibling tools like 'import_captions' or 'transcribe_to_captions' beyond the verb, leaving some ambiguity in scope or output format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites (e.g., having captions in the project), exclusions, or comparisons to siblings like 'export_xml' or 'generate_fcpxml', 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 full burden. It mentions 'Export' but doesn't disclose behavioral traits such as whether it requires a project to be open, if it's destructive, what permissions are needed, or how the output is delivered (e.g., file save dialog). This leaves significant gaps for a tool that likely involves file operations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and wastes no space, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given 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 input schema, the description is minimal. It lacks details on behavior, output format, or usage context, which is inadequate for a tool that likely involves file export operations. More information would help an agent understand how to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so no parameter information is needed. The description doesn't add param details, which is appropriate, earning a baseline score of 4 for not introducing confusion or redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Export') and the resource ('the current project/event'), with specificity about the output format ('as FCPXML'). It distinguishes from siblings like 'export_captions' or 'generate_fcpxml' by focusing on the current project/event, though it doesn't explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'export_captions' or 'generate_fcpxml'. The description implies it's for exporting the current project/event, but lacks context on 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.
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 mentions the tool retrieves data ('Get all projects') and includes specific details, but fails to address critical aspects such as permissions required, pagination, rate limits, or error handling. This leaves significant gaps for a read 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Get all projects within a specific event') and adds relevant detail without redundancy. Every word contributes to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read tool with no annotations and no output schema, the description adequately covers the basic purpose and scope. However, it lacks details on return format, error conditions, or behavioral traits, which are important given the tool's role in a media editing context with many sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters ('library_name' and 'event_name'). The description adds no additional semantic context about these parameters, such as format examples or constraints beyond what the schema provides, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get all projects') and resource ('within a specific event'), with added detail about included data ('sequence/timeline details'). It does not explicitly differentiate from sibling tools like 'get_events' or 'get_libraries', but the specificity of 'projects within an event' provides some implicit distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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 is provided. The description implies usage for retrieving project data within events, but it lacks context on prerequisites, exclusions, or comparisons to similar tools like 'get_events' or 'duplicate_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?
No annotations are provided, so the description carries full burden. It states the tool imports files but doesn't disclose behavioral traits like whether it overwrites existing captions, requires specific permissions, has file size limits, or what happens on success/failure. The description is minimal and lacks operational 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise single sentence with zero waste. It's front-loaded with the core action and includes helpful file format examples. Every word earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given 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 0 parameters, the description is incomplete. It doesn't explain what happens after import (e.g., where captions appear, format validation, error handling), leaving significant gaps in understanding the tool's behavior and outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0 parameters and 100% schema description coverage, the baseline is 4. The description adds no parameter information (as there are none), which is appropriate. No compensation is needed 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Import') and resource ('captions file') with specific file format examples (SRT, SCC, ITT). It distinguishes from sibling 'export_captions' by specifying import vs export, but doesn't differentiate from 'import_media' or 'import_xml' which handle other import types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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 like 'import_media' or 'import_xml'. The description implies it's for caption files specifically, but doesn't state prerequisites, constraints, 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'controls' but doesn't specify if this is a read-only or mutating operation, what permissions are required, or how it interacts with the UI (e.g., if it modifies the current selection). This leaves significant gaps for an agent to understand 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any fluff. It's front-loaded and appropriately sized, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (involving multiple action types for keyframe manipulation) and the lack of annotations or output schema, the description is minimally adequate. It covers the general purpose but misses details on behavior, usage context, and expected outcomes, leaving room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description doesn't add any parameter-specific information beyond what's in the input schema, which has 100% coverage with a well-documented 'action' enum. Since the schema fully describes the single parameter, the baseline score of 3 is appropriate, as no additional semantic value is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Keyframe animation controls for effects, transforms, and audio parameters,' specifying the resource (keyframe animation) and scope (effects, transforms, audio parameters). However, it doesn't explicitly differentiate from sibling tools like 'nudge' or 'retime' that might also involve keyframe adjustments, keeping it from 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description lacks context about prerequisites, such as needing an active timeline or selected clip, and doesn't mention when to choose this over similar tools like 'nudge' or 'adjust_volume' for audio parameter changes.
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 states 'Create' which implies a write/mutation operation, but doesn't disclose behavioral traits like whether it requires specific permissions, what happens on success/failure, if it's undoable, or how it interacts with the current library context. The description is minimal and lacks operational 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action ('Create a new event') and specifies the context ('in the current library'), making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a creation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what an 'event' entails in this context, what happens after creation (e.g., selection, timeline placement), or error conditions. For a mutation tool, more behavioral context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate here. A baseline of 4 is given since the schema fully covers the absence of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and target resource ('new event in the current library'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'new_library' or 'new_project' that also create resources, nor does it specify what type of event (e.g., timeline event, media event) is being created.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an open library), exclusions, or how it differs from similar creation tools like 'new_project' or 'create_storyline' 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.
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. It states 'Opens the new project dialog' which suggests this is a UI-interactive operation rather than a programmatic creation, adding some context. However, it doesn't address permissions needed, whether this is a modal operation that blocks other actions, or what happens if the dialog is cancelled.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two short sentences. The first sentence states the core purpose, and the second adds important behavioral context about the UI interaction. No wasted words, though it could be slightly more informative about the dialog's nature.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given 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 covers the basic purpose and UI interaction mode adequately. However, it lacks information about what happens after dialog completion, whether the tool returns anything, or how it relates to similar project-creation tools among siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the parameter situation. The description appropriately doesn't discuss parameters, maintaining focus on the tool's purpose and behavior. Baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a new project') and resource ('project'), making the purpose immediately understandable. However, it doesn't differentiate this from 'duplicate_project' or 'snapshot_project' among the sibling tools, which could create ambiguity about when to use each.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'duplicate_project' or 'snapshot_project'. It mentions 'Opens the new project dialog' which hints at UI interaction but doesn't clarify 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.
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 states the tool 'controls playback,' implying it performs actions that may affect playback state (e.g., starting, stopping, looping). However, it doesn't disclose critical details like whether it requires specific permissions, if it's destructive to media, its response format, or any rate limits. For a tool with no annotations, this is a significant gap in 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence: 'Control playback in Final Cut Pro.' It's front-loaded with the core purpose, has zero wasted words, and is appropriately sized for a tool with a simple parameter set. Every part of the description earns its place by clearly stating the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter with full schema coverage) and lack of annotations or output schema, the description is minimally adequate. It states what the tool does but doesn't provide enough context for safe or effective use—e.g., no behavioral details or usage guidelines. This makes it complete only in a basic sense, with clear gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'action' parameter fully documented via an enum list (e.g., 'play_pause', 'stop'). The description doesn't add any meaning beyond what the schema provides—it doesn't explain the semantics of actions like 'play_selection' or 'loop_toggle'. Since the schema does the heavy lifting, 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Control playback in Final Cut Pro.' It specifies the verb ('control') and resource ('playback'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'set_playback_speed' or 'retime', which also affect playback behavior, so it doesn't reach 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, exclusions, or comparisons to sibling tools like 'set_playback_speed' or 'retime', which might be better for specific playback adjustments. This lack of context leaves the agent to infer usage from the parameter enum alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool changes speed/retiming, implying a mutation, but lacks details on permissions, reversibility, or effects on the clip (e.g., whether it modifies the original or creates a new version). This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Change the speed/retiming of the selected clip') with zero wasted words, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (mutation with one parameter) and no annotations or output schema, the description is minimally adequate. It states what the tool does but lacks behavioral context, usage guidelines, and output details, leaving gaps that could hinder effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the 'action' parameter fully documented via an enum list in the schema. The description adds no additional parameter semantics beyond implying the action applies to a clip, so it meets the baseline of 3 where 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Change the speed/retiming') and resource ('selected clip'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'rate_clip', 'set_playback_speed', or 'show_retime_editor', which appear related to 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., requiring a clip to be selected), exclusions, or comparisons to sibling tools like 'rate_clip' or 'set_playback_speed', leaving usage context ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Set' implying a mutation, but doesn't disclose behavioral traits such as permissions needed, whether changes are reversible, or effects on existing clips. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded and appropriately sized for the tool's simplicity, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter with full schema coverage and no output schema, the description is minimally adequate. However, as a mutation tool with no annotations, it lacks details on behavior and context, leaving gaps in completeness for safe agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'quality' fully documented in the schema. The description adds no additional meaning beyond the schema, such as explaining the impact of different quality modes. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set') and target resource ('video quality for retimed clips'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'retime' or 'show_retime_editor', which might handle related retiming operations, so it doesn't reach the highest 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'retime' and 'show_retime_editor' present, there's no indication of context, prerequisites, or exclusions, leaving usage ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the tool sends shortcuts but doesn't disclose behavioral traits like whether this requires Final Cut Pro to be active/focused, potential side effects (e.g., triggering unintended actions), error handling, or system requirements. This leaves significant gaps for a tool that interacts with an external application.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. It avoids unnecessary words and gets straight to the point, though it could be slightly more structured by separating usage guidance into a second sentence for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of interacting with an external application and lack of annotations/output schema, the description is incomplete. It doesn't cover prerequisites (e.g., Final Cut Pro must be running), expected outcomes, error conditions, or safety considerations, which are crucial for reliable tool invocation in this context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing detailed parameter documentation. The description adds no additional parameter semantics beyond what's in the schema (e.g., it doesn't clarify parameter interactions like using 'key' vs 'key_code'). With high schema coverage, the baseline score of 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Send a keyboard shortcut') and target application ('to Final Cut Pro'), which is specific and actionable. However, it doesn't explicitly differentiate this tool from sibling tools like 'execute_menu_command' or 'select_tool' that might also involve interface interactions, missing full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage guidance ('Use this for any command that has a keyboard shortcut'), suggesting when to use this tool. However, it doesn't explicitly state when not to use it or mention alternatives like 'execute_menu_command' for commands without shortcuts, lacking clear exclusions or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action is a 'toggle', implying it switches the retime editor on or off, but does not clarify effects like whether it modifies project state, requires specific permissions, or has side effects (e.g., changing UI layout). This leaves significant gaps for a tool that likely interacts with the user interface.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words, making it highly concise and front-loaded. It efficiently communicates the core action without unnecessary elaboration, which is ideal for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given 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 is incomplete for a tool that likely affects the UI or project state. It does not explain what 'retime editor' entails, the outcome of toggling it, or any behavioral nuances, leaving the agent with insufficient context to use it effectively in complex scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the input schema has 100% description coverage (though empty). The description does not need to add parameter details, as there are none to explain. A baseline score of 4 is appropriate since no compensation is required for missing parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Toggle') and the target ('retime editor in the timeline'), making the purpose specific and understandable. However, it does not explicitly differentiate this tool from sibling tools like 'retime' or 'retime_quality', which appear related to retiming functions, leaving some ambiguity about when to choose this over those 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as the sibling tools 'retime' or 'retime_quality'. It lacks context about prerequisites, typical workflows, or exclusions, leaving the agent to infer usage based on the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action without behavioral details. It doesn't disclose whether this operation is destructive (e.g., alters timeline edits), requires specific permissions, has side effects like updating playback, or how it interacts with undo/redo. The mention of 'cut_and_switch' in the schema hints at behavior, but the description doesn't elaborate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with zero wasted words. It front-loads the core action and resource efficiently, making it easy to parse quickly without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 parameters, full schema coverage, and no output schema, the description is minimally adequate. It identifies the tool's domain (multicam editing) but lacks context about prerequisites, effects, or integration with sibling tools like 'timeline_history' or 'playback'. Without annotations, more behavioral detail would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage, clearly documenting both parameters ('angle' as 1-16 number, 'cut_and_switch' as boolean with default). The description adds no additional parameter semantics beyond implying the tool operates on multicam clips, so it meets the baseline for high schema coverage without adding value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Switch to') and resource ('a specific angle in a multicam clip'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'create_multicam_clip' or 'multicam_angle_selection' (if they existed), which would require more specificity about its role within multicam editing workflows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives or prerequisites. For example, it doesn't mention if a multicam clip must be selected or active in the timeline, or how it relates to tools like 'select_tool' or 'edit_insert'. This leaves the agent to infer context from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool performs synchronization but doesn't disclose behavioral traits such as whether it modifies original clips, requires specific permissions, has side effects, or how it handles errors. This is a significant gap for a tool that likely involves media processing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste—it directly states the tool's purpose without unnecessary elaboration. It's appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given 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 likely complex synchronization operation, the description is incomplete. It lacks details on behavior, outcomes, or error handling, which are crucial for an AI agent to use this tool effectively in a media editing context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description adds context by specifying 'selected clips' as the implicit target, which is appropriate given the lack of explicit parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('synchronize') and resource ('selected clips'), with specific purpose ('align audio/video from multiple sources'). It doesn't explicitly differentiate from siblings like 'merge_clips' or 'create_multicam_clip', but the synchronization focus is reasonably distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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 'merge_clips' or 'create_multicam_clip', which might handle similar multi-source scenarios. The description implies usage for alignment but lacks explicit context 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 the full burden of behavioral disclosure. It mentions 'show or hide' but doesn't specify whether this is a toggle action, if it requires specific interface states, what happens to other panels, or if there are side effects like layout changes. For a UI interaction tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded with the core action and target, making it easy to parse quickly, which is ideal for conciseness in a tool definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter with full schema coverage) and no output schema, the description is minimally adequate but lacks depth. It doesn't explain behavioral nuances, usage context, or integration with sibling tools, which could help an agent use it more effectively in the broader FCP interface ecosystem.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not add any parameter-specific information beyond what the input schema provides. However, schema description coverage is 100%, with a clear enum for the 'panel' parameter, so the baseline score of 3 is appropriate as the schema adequately documents the single required parameter without needing extra details from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('show or hide') and target ('various panels and browsers in the FCP interface'), making the purpose understandable. However, it doesn't explicitly differentiate this tool from sibling tools like 'go_to_panel' or 'window_layout', which might also involve panel navigation or arrangement, leaving some ambiguity about its unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as 'go_to_panel' for navigation or 'window_layout' for broader interface changes. It lacks context about prerequisites, timing, or exclusions, leaving the agent to infer usage based solely on the tool name and basic purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('Switch to') but doesn't clarify if this is a read-only operation, whether it affects other UI elements, requires specific permissions, or has side effects like resetting other settings. For a UI manipulation tool 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simple nature (one parameter with full schema coverage, no output schema), the description is minimally adequate. However, the lack of annotations and usage guidelines leaves gaps in understanding behavioral impact and differentiation from siblings, reducing completeness for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'layout' fully documented via its enum values. The description adds no additional semantic context beyond implying a 'preset' concept, which is already covered in the schema. This 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Switch to') and the resource ('a predefined window layout'), making the purpose understandable. However, it doesn't differentiate this tool from potential sibling tools like 'toggle_panel' or 'go_to_panel' that might also affect window arrangements, leaving room for ambiguity in a crowded toolset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools related to UI navigation (e.g., 'toggle_panel', 'go_to_panel'), there's no indication of context, prerequisites, or exclusions, leaving the agent to guess based on the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It states the tool applies an automated adjustment but doesn't disclose whether it's destructive (e.g., permanently alters the clip), requires specific permissions, has side effects (e.g., creates new clips), or details output (e.g., success/failure indicators). This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('Apply Auto Reframe') and purpose. There is no wasted text, repetition, or unnecessary elaboration, making it highly concise and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (an automated framing adjustment), lack of annotations, and no output schema, the description is minimally complete. It states what the tool does but lacks details on behavior, constraints, or results. For a mutation tool in a video editing context, more information on effects and limitations would be beneficial, though the zero parameters simplify the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the absence of inputs. The description adds no parameter information, which is appropriate here. Baseline is 4 for zero-parameter tools, as no additional semantic explanation is needed beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Apply Auto Reframe') and target ('selected clip') with a specific purpose ('automatically adjust framing for different aspect ratios'). It distinguishes from siblings like 'adjustment_layer' or 'color_correction_nav' by focusing on automated framing adjustments. However, it doesn't explicitly differentiate from tools like 'clip_appearance' or 'retime' that might also affect clip presentation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a clip selected), exclusions (e.g., not for audio clips), or compare to siblings like 'adjustment_layer' for manual framing or 'retime' for timing adjustments. Usage is implied but not explicitly defined.
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 states the tool opens a dialog, implying a user-interactive or modal operation, but does not detail outcomes (e.g., whether changes are applied immediately, if it's destructive, or permission requirements). For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the key action ('Open the change duration dialog') and purpose. There is no wasted language, and it directly communicates the tool's function without redundancy or ambiguity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, no annotations, and no output schema, the description provides basic purpose but lacks depth. It does not explain what happens after the dialog is opened (e.g., user interaction flow or result confirmation), which is crucial for understanding the tool's full context. However, for a simple dialog-opening tool, it meets a minimum viable level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, meaning no parameters are documented in the schema. The description does not mention any parameters, which is appropriate since the tool likely relies on a dialog for input. This aligns with the schema, and the description adds context about the dialog mechanism, compensating adequately for the lack of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Open the change duration dialog to set a specific clip or selection duration via timecode.' It specifies the action ('Open...dialog'), resource ('clip or selection'), and mechanism ('via timecode'), making the function understandable. However, it does not explicitly differentiate from sibling tools like 'retime' or 'trim', which might have overlapping functionality, 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions setting duration 'via timecode' but does not clarify scenarios where this is preferred over other tools (e.g., 'retime' for speed adjustments or 'trim' for cutting). Without explicit when-to-use or exclusion criteria, the agent lacks 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 mentions actions like 'save a reference frame' and 'compare side-by-side', which imply read/write operations, but doesn't disclose behavioral traits such as whether it modifies data, requires specific permissions, has side effects, or how it handles errors. The description is too vague to fully inform an agent about the tool's behavior beyond basic functionality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences that efficiently state the tool's purpose and key actions. It's front-loaded with the main function and avoids unnecessary details. However, it could be slightly more structured by explicitly linking actions to the parameter enum for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (single parameter with enum actions), no annotations, and no output schema, the description is somewhat complete but has gaps. It covers the basic purpose and hints at usage, but lacks details on behavioral transparency, error handling, and output expectations. For a tool with no structured support, it should provide more context to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'action' parameter well-documented via enum values. The description adds minimal semantic context by mentioning 'save a reference frame' (related to 'add' action) and 'compare side-by-side' (implied for viewer actions), but doesn't provide additional details beyond what the schema already specifies. This 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Compare frame/viewer for before-and-after comparison of color corrections and effects.' It specifies the verb ('compare') and resource ('frame/viewer') with context about color corrections and effects. However, it doesn't explicitly differentiate from sibling tools like 'match_color' or 'color_correction_nav', which might involve similar color-related operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for comparing color corrections and effects, suggesting it's used in post-production workflows. It mentions saving a reference frame and side-by-side comparison, which gives some context. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., 'match_color' for color matching or 'color_correction_nav' for navigation), and doesn't specify prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it 'creates' something, implying a mutation, but doesn't disclose behavioral traits like whether it requires specific permissions, if it's destructive to the original selection, what happens on failure, or any side effects. This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with zero waste. It's front-loaded with the core action and resource, making it highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, no annotations, and no output schema, the description is minimal but covers the basic purpose. However, as a mutation tool with no behavioral details or output information, it lacks completeness for safe and effective use by an AI agent, leaving key aspects like success criteria or effects unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameters need documentation. The description adds context by implying the tool uses the 'current selection' as an implicit input, which is useful beyond the empty schema. This compensates adequately for the lack of explicit parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does 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 ('compound clip'), specifying it's from 'the current selection'. It distinguishes from sibling tools like 'create_multicam_clip' or 'create_storyline' by focusing on compound clips specifically. However, it doesn't fully explain what a compound clip is, which slightly limits 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance: it implies use when there's a current selection to create a compound clip from. No explicit when-not-to-use instructions, alternatives, or prerequisites are mentioned, such as how to make a selection first or what constitutes a valid 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 mentions 'selected clips' but doesn't disclose behavioral traits like whether this is a destructive operation, what happens to the original clips, if it requires specific permissions, or what the output looks like. For a creation tool 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters and no output schema, the description is minimally complete for a simple creation tool. However, with no annotations and sibling tools like 'create_compound_clip', it lacks context on differences, permissions, or output behavior, leaving gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so the schema fully documents the lack of parameters. The description adds value by implying that the tool operates on 'selected clips' (contextual input), which isn't in the schema. This compensates adequately, though it could specify how clips are selected.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does 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 ('multicam clip'), specifying it's made 'from the selected clips'. It distinguishes from siblings like 'create_compound_clip' or 'create_storyline' by focusing on multicam functionality. However, it doesn't explicitly define what a multicam clip is, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'create_compound_clip' or 'merge_clips', nor does it mention prerequisites such as having clips selected. It only states what the tool does, not when it's 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 states the tool toggles a display, implying it's non-destructive and likely read-only for viewing purposes, but doesn't clarify if it requires specific viewer states, affects playback, or has side effects like UI changes. More behavioral details would help agents predict outcomes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('toggle') and resource. Every word contributes meaning, with no redundancy or fluff, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate but has gaps. It explains what the tool does but lacks usage context, behavioral nuances, or output expectations. For a toggle tool in a complex media environment, more guidance on integration with other tools would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does 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%, so no parameter documentation is needed. The description adds value by explaining what the toggle controls (title safe, action safe zones, etc.), which isn't captured in the schema. This compensates well for the lack of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('toggle') and the resource ('custom overlay display in the viewer'), specifying what it controls (title safe, action safe zones, etc.). It distinguishes from siblings by focusing on overlay display rather than media editing or project management functions, though it doesn't explicitly differentiate from similar toggle tools like 'toggle_panel' or 'toggle_snapping'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a viewer open), exclusions, or related tools for overlay management. Without such context, an agent might struggle to apply it appropriately in workflows.
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 states the tool 'opens' the Image Playground, implying it launches an interface rather than performing an automated operation, but doesn't clarify if this requires user interaction, what permissions are needed, whether it's destructive, or what happens after opening. For a tool with zero annotation coverage, this leaves critical behavioral aspects unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the key action ('Open') and resource, making it immediately understandable. Every part of the sentence contributes essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given 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 adequately covers the basic purpose. However, as a tool with no annotations, it lacks details on behavioral aspects like whether it's interactive, requires specific conditions, or has side effects. For a tool that likely involves AI image generation/editing, more context on usage constraints would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage (empty schema). The description doesn't need to explain parameters, and it appropriately doesn't mention any. Since there are no parameters to document, this meets expectations without redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Open') and the target resource ('Apple's AI-powered Image Playground'), specifying it's for generating and editing images within Final Cut Pro. It distinguishes from siblings by focusing on a specialized AI image tool rather than general editing functions. However, it doesn't explicitly differentiate from potential similar image tools (none listed in siblings).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions the tool's purpose but doesn't indicate prerequisites, when it's appropriate, or what other tools might be better for different image-related tasks. With many sibling tools for effects, color correction, and editing, this lack of comparative 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?
With no annotations provided, the description carries full burden but only states the action without behavioral details. It doesn't mention whether this opens a modal dialog that blocks other operations, requires user interaction, has side effects on the UI state, or what happens after the dialog opens. For a UI-interaction tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no wasted words, front-loading the core action. Every word earns its place, making it immediately clear what the tool does without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given 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 important context about behavioral implications. It doesn't explain what 'opening the import media dialog' means operationally—whether it's a blocking UI action, what the expected user flow is, or how it integrates with other import tools. Given the complexity of UI interaction tools, more behavioral context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema description coverage, so the schema already fully documents the parameter situation. The description doesn't need to explain parameters, and it correctly doesn't mention any. Baseline 4 is appropriate for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Open') and target ('import media dialog in Final Cut Pro'), making the purpose immediately understandable. It doesn't distinguish from siblings like 'import_captions' or 'import_xml', but the verb+resource combination is specific enough for basic understanding.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'import_captions' or 'import_xml'. The description simply states what it does without context about when it's appropriate or what prerequisites might exist.
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 burden for behavioral disclosure. It states the tool's function but reveals nothing about permissions needed, whether it modifies clips destructively, how it handles errors, or what visual feedback to expect. For a tool that likely alters media, this lack of transparency is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently communicates the core function and purpose. Every word earns its place with no fluff or repetition, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that performs color matching (likely a media-altering operation), the description is insufficient given no annotations and no output schema. It lacks critical context about side effects, success indicators, or error conditions that an agent would need to use this tool responsibly in a video editing workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately focuses on the tool's purpose without redundant parameter explanations, meeting the baseline for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('match the color') and target resources ('selected clip' and 'reference clip'), with a clear purpose ('for consistent color grading across scenes'). It distinguishes itself from siblings like 'color_board' or 'color_correction_nav' by focusing on matching rather than general color 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when color consistency is needed across scenes, but provides no explicit guidance on when to use this tool versus alternatives like 'add_color_correction' or 'color_board'. No prerequisites, exclusions, or comparisons to sibling tools 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 burden but offers minimal behavioral insight. It states the outcome ('into a single clip') but doesn't disclose permissions needed, whether it's destructive (e.g., overwriting original clips), rate limits, or error conditions. For a mutation tool, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It front-loads the core action ('merge') and key details ('adjacent selected clips'), making it easy to parse quickly. Every part of the sentence contributes directly to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (simple mutation with 0 parameters) and lack of annotations/output schema, the description is minimally adequate. It states what the tool does but lacks behavioral context, usage guidelines, or output details. For a mutation tool, this leaves the agent under-informed, though the zero-parameter nature reduces risk.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents inputs. The description doesn't add parameter details, which is acceptable given no parameters exist. A baseline of 4 is applied as it doesn't need to compensate for missing schema information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('merge') and target resource ('adjacent selected clips'), specifying they become 'a single clip'. It distinguishes from siblings like 'break_apart_clip' or 'trim' by focusing on combination rather than separation or adjustment. However, it doesn't explicitly differentiate from all siblings (e.g., 'create_compound_clip'), slightly limiting specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing selected clips), exclusions (e.g., non-adjacent clips), or comparisons to siblings like 'create_compound_clip' for similar operations. The description implies usage context but lacks explicit instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Create' implies a write/mutation operation, the description doesn't specify permissions needed, whether this opens the library, what happens if a library already exists, or any side effects. It provides minimal behavioral 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core purpose without any wasted words. It's appropriately sized for a zero-parameter creation tool and is perfectly front-loaded with the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter creation tool with no output schema, the description adequately states what the tool does. However, without annotations covering behavioral aspects and no sibling differentiation, it leaves gaps in understanding when and how to use this tool effectively in context with other library/project management tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the parameter situation. The description appropriately doesn't mention parameters since none exist, earning a baseline 4 for not adding unnecessary information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and target resource ('a new library in Final Cut Pro'), providing specific verb+resource information. However, it doesn't distinguish this tool from sibling tools like 'new_event' or 'new_project' that also create resources, missing full 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'new_event' or 'new_project', nor does it mention any prerequisites or context for library creation. It simply states what the tool does without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states the tool creates a snapshot/backup, implying a write operation, but doesn't disclose behavioral traits like whether it requires specific permissions, if it's reversible, what happens to existing snapshots, or any rate limits. The description is minimal and lacks operational 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the key action ('create a snapshot') and includes essential context without any wasted words. It's appropriately sized for a no-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given 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 minimally adequate but lacks depth. It explains what the tool does but doesn't cover behavioral aspects like side effects or usage scenarios, which is a gap for a mutation tool with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description doesn't add parameter details, but that's appropriate here, earning a baseline score above 3 due to the lack of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('create a snapshot') and the resource ('current project state'), with additional context about where it's saved ('duplicate within the event'). It doesn't explicitly differentiate from siblings like 'duplicate_project', but the backup/snapshot purpose is specific enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'duplicate_project' or 'consolidate_files'. The description implies it's for backup purposes but doesn't specify 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.
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. It states the action but doesn't explain what 'solo' means operationally (e.g., muting other tracks, toggling state), whether changes are reversible, or what visual/audio feedback occurs. This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and target, making it immediately understandable without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given 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 complete but lacks behavioral context. It explains what the tool does but not how it behaves or when to use it, which is important given the many sibling audio/video editing tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, earning a baseline score of 4 for not adding unnecessary information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('solo or unsolo') and target resource ('selected clip(s) audio'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'adjust_volume' or 'audio_operations' that might also affect audio 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/5
Does 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. The description doesn't mention prerequisites (e.g., needing clips selected), exclusions, or context for choosing solo/unsolo over other audio manipulation 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.
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 mentions the action of navigating hierarchy levels but fails to describe what the tool actually does behaviorally—such as whether it changes the user interface view, modifies project state, requires specific permissions, or has side effects like closing tabs. This leaves significant gaps in understanding 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose and context without any unnecessary words. It is front-loaded with the core action ('Navigate timeline hierarchy levels') and specifies the editing contexts concisely, making it easy to understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given 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 is insufficient for a tool with behavioral implications like navigation in a complex editing environment. It does not explain what the tool returns, how it affects the user interface, or any error conditions, leaving the agent with incomplete information to invoke it correctly in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the 'action' parameter fully documented in the schema via enum values and descriptions. The description does not add any additional meaning or context about the parameters beyond what the schema provides, so it meets the baseline score of 3 for adequate but not enhanced parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as navigating timeline hierarchy levels during editing, specifying the context of compound clips, multicam clips, or auditions. It uses a specific verb ('Navigate') and resource ('timeline hierarchy levels'), but does not explicitly differentiate from sibling tools like 'navigate' or 'go_to_panel', which might have overlapping functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage within specific editing contexts (compound clips, multicam clips, auditions), providing some situational guidance. However, it does not explicitly state when to use this tool versus alternatives like 'navigate' or 'go_to_panel', nor does it mention any exclusions or prerequisites for use.
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 states the action ('toggle on/off') but doesn't explain what timeline snapping entails, whether it affects current edits, requires specific permissions, or has side effects. This leaves significant gaps in understanding 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste—it directly states the tool's action without unnecessary elaboration. It's front-loaded and appropriately sized for a simple tool with no parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, no annotations, and no output schema, the description is minimally adequate. It states what the tool does but lacks details on behavior, usage context, or output, leaving room for improvement in guiding the agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, aligning with the schema's completeness, though it doesn't add extra semantic context since none is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('toggle') and the resource ('timeline snapping'), making the purpose evident. However, it doesn't differentiate this tool from its many siblings, which include various timeline and editing tools like 'snapshot_project' or 'timeline_history', leaving some ambiguity about its specific role in the broader toolset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'snapshot_project' or 'timeline_history' that might relate to timeline operations, there's no indication of context, prerequisites, or exclusions for toggling snapping, 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.
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. While it indicates this opens a dialog (suggesting user interaction rather than automated processing), it doesn't disclose whether this requires specific permissions, whether it's destructive to media files, what happens if no clips are selected, or what the expected user flow is after the dialog opens.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core purpose without any wasted words. It's appropriately sized for a simple tool that opens a dialog, and the information is front-loaded with the essential action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description adequately explains what the tool does at a basic level. However, given the lack of annotations and the fact this appears to be a UI interaction tool (opening a dialog), more context about the expected user workflow and what happens after the dialog opens would be helpful for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the parameter situation. The description appropriately doesn't waste space discussing parameters that don't exist, earning a baseline score of 4 for this zero-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Open the transcode media dialog') and the target ('for the selected clips'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate this tool from sibling tools like 'render' or 'consolidate_files' which might also involve media processing 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance - it indicates this tool should be used when you want to open a transcode dialog for selected clips. However, it offers no guidance on when to use this versus alternatives like 'render' or 'consolidate_files', nor does it mention any prerequisites (like needing clips to be selected first).
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 mentions 'Toggle' implying a state change, but does not specify if this requires specific permissions, what the default state is, whether it's reversible, or any side effects like performance impacts. This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words, clearly front-loading the core action ('Toggle external video output') and providing relevant context. It is appropriately sized for a tool with no parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given 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 minimally adequate but lacks completeness for a mutation tool. It does not cover behavioral aspects like error conditions, confirmation of state changes, or integration with other tools, leaving room for improvement in contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not add parameter details, which is appropriate here, but it could have mentioned if any implicit parameters (like device selection) are involved, though not required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Toggle') and resource ('external video output'), and specifies the target devices (external displays, broadcast monitors, HDMI devices). However, it does not explicitly differentiate this tool from sibling tools, as none appear to be direct alternatives for video output control.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, prerequisites, or exclusions. It lacks context such as whether it's for monitoring during editing or final output, and does not reference any sibling tools for comparison.
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 mentions that the tool 'Opens the timecode entry dialog and types the timecode,' which adds some behavioral context beyond a basic 'navigate' action. However, it does not disclose critical traits like whether it requires specific permissions, if it changes the timeline state, or any side effects, leaving gaps 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded and concise, consisting of two sentences that directly state the purpose and action without unnecessary words. Every sentence earns its place by clarifying the tool's behavior efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is adequate for a simple navigation tool with one parameter. It covers the basic action and parameter use but lacks depth on behavioral aspects like error handling or return values. It meets minimum viability but has clear gaps in completeness for a tool that interacts with the UI.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the 'timecode' parameter with examples. The description adds minimal value by implying the parameter is used for navigation but does not provide additional syntax or format details beyond what the schema offers. Baseline 3 is appropriate as the schema handles most of the parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Navigate to a specific timecode position') and the resource ('timecode'), distinguishing it from siblings like 'navigate' or 'playback' by specifying it opens a dialog and types the timecode. It provides a precise verb+resource combination that is not tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool versus alternatives. It lacks explicit context, prerequisites, or exclusions, such as whether it works only in certain modes or if other tools like 'navigate' or 'playback' are better for different scenarios. No sibling tool comparisons are made.
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. It mentions the 360° viewer requirement for navigation controls, which is useful context. However, it doesn't describe what the tool actually does behaviorally: whether it's a read-only display control or makes permanent edits, what permissions are needed, what happens when invoked, or what the expected outcomes are. For a tool with 20 possible actions, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences. The first sentence efficiently lists the tool's three main capability areas. The second sentence provides a critical prerequisite. Both sentences earn their place by adding value beyond what's in the schema. It could be slightly more front-loaded with the core purpose, but overall it's well-structured without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (20 possible actions, no annotations, no output schema), the description is minimally adequate but incomplete. It covers the basic purpose and provides some parameter context, but doesn't explain what the tool returns, how different actions affect the video, or what behavioral outcomes to expect. For a tool with this many action options and no structured output documentation, more guidance would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context about parameter semantics despite 100% schema description coverage. While the schema documents the 'action' enum values, the description groups them into categories (stereoscopic, navigation, FOV, display) and clarifies that navigation 'requires 360° viewer open'. This provides organizational context and usage constraints that go beyond the schema's technical documentation of enum values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Controls for 360°, VR, and spatial video editing' with specific capabilities listed (stereoscopic viewing modes, 360° navigation, field of view adjustments). It distinguishes from siblings by focusing on spatial/VR editing, unlike general editing tools like 'add_effect' or 'color_correction_nav'. However, it doesn't explicitly contrast with similar-sounding tools like 'navigate' or 'video_output'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some implied usage context: 'The 360° viewer must be open for navigation controls' indicates a prerequisite condition. However, it doesn't explicitly state when to use this tool versus alternatives (e.g., when to choose 'spatial_video' over 'navigate' or 'video_output'), nor does it provide exclusions or clear decision criteria beyond the viewer requirement.
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 mentions creating and previewing variants, but fails to describe key traits: whether actions are reversible (e.g., 'finalize' might be permanent), permission requirements, side effects on the timeline, or how variants are stored/managed. This leaves significant gaps for a tool with multiple action types.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and front-loaded, using two clear sentences that directly state the tool's function and key actions. Every word earns its place, with no redundant or vague phrasing, making it easy to scan and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple actions via a single enum parameter) and lack of annotations or output schema, the description is incomplete. It covers the high-level purpose but omits details on behavioral outcomes, error conditions, or what 'finalize' entails. For a tool with varied operations, more context on usage and results would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'action' parameter fully documented via enum and descriptions. The tool description adds minimal semantics beyond the schema—it hints at 'create alternate clip versions' and 'preview them', which loosely maps to some enum values like 'create_from_active', but doesn't provide additional context on parameter usage or interactions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: managing variant controls for comparing different clip versions, with specific actions like creating alternates and previewing. It uses concrete verbs ('create', 'preview') and identifies the resource ('clips'), but doesn't explicitly differentiate from sibling tools like 'duplicate_detection' or 'compare_frame' that might 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('preview them before committing'), suggesting it's for auditioning changes without permanent application. However, it lacks explicit guidance on when to use this versus alternatives (e.g., 'duplicate_detection' for duplicates or 'compare_frame' for visual comparisons), and no exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'Open the recording panel' and 'start/stop recording,' which implies mutation (opening/controlling), but doesn't disclose behavioral traits like permissions needed, side effects (e.g., if it interrupts playback), or error conditions. The description is minimal and lacks rich context beyond basic actions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and front-loaded: two sentences that directly state the tool's purpose and actions. Every word earns its place with zero waste, making it easy to parse quickly for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter with full schema coverage and no output schema, the description is minimally complete. It covers the basic purpose but lacks depth for a mutation tool with no annotations—e.g., it doesn't explain what happens after actions or potential constraints. It's adequate but has clear gaps in behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'action' fully documented in the schema (enum values and descriptions). The description adds no additional meaning beyond what the schema provides, such as explaining when to choose 'show_panel' versus 'toggle_recording' in practical terms. 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Voice-over recording controls. Open the recording panel and start/stop recording.' It specifies the verb ('controls') and resource ('voice-over recording'), and distinguishes it from siblings by focusing on voice-over functionality. However, it doesn't explicitly differentiate from potential audio-related siblings like 'adjust_volume' or 'audio_operations' beyond the voice-over focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for controlling voice-over recordings, but provides no explicit guidance on when to use this tool versus alternatives. It mentions two actions ('show_panel' and 'toggle_recording'), which suggests contexts for opening the panel or toggling recording, but lacks when-not scenarios or named alternatives among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool adds a transition but doesn't disclose behavioral traits like whether it requires specific permissions, if it modifies existing transitions, what happens on multiple selections, or error conditions. The description is minimal and lacks operational 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any fluff. It's front-loaded with the core action and resource, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given 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 mutation tool (implied by 'Add'), the description is incomplete. It doesn't explain what the tool returns, error handling, or side effects. For a tool that modifies timeline content, more behavioral context is needed for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing instead on the tool's action. Baseline is 4 for zero-parameter tools when schema coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Add'), the resource ('default cross dissolve transition'), and the target ('selected edit point(s)'). It distinguishes from siblings like 'add_effect' or 'add_title' by specifying the exact type of transition being added.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing selected edit points), exclusions, or how it differs from other transition-related tools that might exist 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.
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 mentions the requirement for macOS speech recognition, which adds useful context about dependencies. However, it lacks details on permissions needed, whether it modifies existing clips, error handling, or output format. For a tool with zero annotation coverage, this is insufficient to fully inform 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences that are front-loaded and efficient. The first sentence states the core purpose, and the second adds a critical prerequisite. There is no wasted text, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no annotations, and no output schema, the description provides basic purpose and a prerequisite. However, for a tool that performs AI transcription, it lacks details on behavioral aspects like what 'selected clips' means, how captions are generated, or error conditions. This makes it minimally adequate but with clear gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, meaning no parameters need documentation. The description does not discuss parameters, which is appropriate. It earns a 4 because it focuses on the tool's purpose without redundant parameter info, aligning with the baseline for zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Use AI to automatically transcribe audio in the selected clips to captions/subtitles.' It specifies the action (transcribe), target resource (audio in selected clips), and output format (captions/subtitles). However, it does not explicitly differentiate from sibling tools like 'import_captions' or 'export_captions', which is why it scores a 4 instead 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context with 'Requires macOS speech recognition,' indicating a prerequisite. However, it does not specify when to use this tool versus alternatives like 'import_captions' or 'export_captions' from the sibling list, nor does it give explicit when-not-to-use guidance. This leaves usage somewhat implied rather than fully clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool performs a destructive operation ('break apart'), implying mutation, but fails to detail critical aspects like whether this action is reversible, if it requires specific permissions, or what happens to effects or adjustments applied to the original clip. This leaves significant gaps in understanding 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and outcome with zero wasted words. It directly communicates the tool's function without fluff or repetition, making it easy for an AI agent to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters and no output schema, the description adequately covers the basic purpose. However, as a mutation tool with no annotations, it lacks details on behavioral traits (e.g., reversibility, side effects) and usage context, which are important for safe and effective operation. This makes it minimally viable but incomplete for informed tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately focuses on the tool's purpose without redundant parameter details, earning a baseline score of 4 for not adding unnecessary information beyond what the schema already covers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('break apart') and target resources ('compound clip or multicam clip'), distinguishing it from sibling tools like 'create_compound_clip' or 'create_multicam_clip' that perform opposite operations. It precisely defines the outcome ('into its individual component clips'), leaving no ambiguity about its 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as when to break apart clips versus using other editing tools like 'blade' or 'trim'. It also lacks prerequisites, like requiring a compound or multicam clip to be selected, which could lead to incorrect usage by an AI agent.
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 mentions that it retrieves data from 'open libraries', implying a read-only operation, but does not specify potential limitations like whether it requires specific permissions, if it's rate-limited, or what happens if no libraries are open. More behavioral context is needed for a mutation-free 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the action ('Get all open libraries') and specifies the returned data. There is no wasted verbiage, and every word contributes to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate but has gaps. It explains what data is returned but lacks context on usage scenarios, error conditions, or behavioral constraints. For a read-only tool with no parameters, it meets minimum viability but could be more informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does 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%, so no parameter information is needed. The description appropriately does not discuss parameters, focusing instead on the output data. A baseline of 4 is applied as it efficiently handles the lack of parameters without unnecessary details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'all open libraries in Final Cut Pro', specifying the exact data returned (names, IDs, file paths, event counts). It distinguishes from sibling tools like 'get_events' and 'get_projects' by focusing specifically on libraries rather than events or projects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'get_events' or 'get_projects', nor does it mention prerequisites such as requiring Final Cut Pro to be open or having libraries available. The description only states what it does without contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the tool's action and outcome, but lacks details on behavioral traits such as whether it requires specific permissions, if changes are reversible, or what happens if no video clip is selected. 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the key action ('Detach audio') and outcome, with zero wasted words, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation operation with no annotations and no output schema), the description is minimal but covers the basic purpose. However, it lacks details on behavioral context (e.g., error handling, side effects) and output format, leaving gaps in completeness for safe agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not add param info, but this is acceptable given the schema's completeness, resulting in a baseline score of 4 for tools with no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('detach audio') and the resource ('selected video clip'), and it distinguishes from siblings by specifying the outcome ('creating separate audio and video clips in the timeline'), which is unique among tools like 'audio_operations' or 'break_apart_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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing to separate audio from video in a timeline, but it does not explicitly state when to use this tool versus alternatives like 'audio_operations' or 'break_apart_clip', nor does it mention prerequisites (e.g., requiring a video clip to be selected).
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 mentions that the tool generates 'valid FCPXML 1.11' and that it can be imported into FCP, but lacks details on permissions needed, error handling, rate limits, or what happens with the 'import_immediately' parameter. For a tool with 8 parameters and no annotations, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in two sentences: the first states the core purpose, and the second adds context about usage and capabilities. Every sentence earns its place with no wasted words, making it easy to scan and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, no annotations, no output schema), the description is adequate but incomplete. It covers the purpose and high-level usage but lacks behavioral details like output format, error cases, or integration specifics with FCP, which are important for a tool generating structured XML content.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value by implying the tool uses these parameters to generate XML content, but does not provide additional syntax, format details, or examples beyond what the schema specifies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('generate', 'create') and resources ('FCPXML content', 'timeline structures'), and distinguishes it from sibling tools like 'export_xml' or 'import_xml' by focusing on programmatic generation rather than export/import operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('to create projects with clips, transitions, titles, and effects defined in XML'), but does not explicitly mention when not to use it or name specific alternatives among the many sibling tools, such as 'create_project' or 'export_xml'.
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 but only states the basic action. It doesn't disclose whether this requires specific permissions, whether it opens a new Finder window or selects an existing one, what happens if no clip is selected, or if there are any side effects. The description doesn't contradict 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with zero waste - every word contributes essential information. Front-loaded with the core action ('reveal'), followed by the specific target and location. No redundant or verbose phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given 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 covers the basic purpose adequately. However, without annotations, it should provide more behavioral context about how the tool works, what happens on failure, or what visual feedback to expect. The description is complete enough for basic understanding but lacks operational details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, and the schema already fully documents this.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('reveal') and target resource ('selected clip's source media file in Finder'), distinguishing it from all sibling tools which perform editing, navigation, or media management operations within Final Cut Pro itself. It's the only tool that interacts with the macOS Finder.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need to locate the original media file of a clip in the filesystem, but provides no explicit guidance on when to use this versus alternatives like 'find' or 'relink_files'. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It explains what adjustment layers do (apply effects to clips beneath them), but lacks details on prerequisites (e.g., requires a timeline with clips), side effects (e.g., may affect rendering performance), or error conditions (e.g., what happens if no clip is selected).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero waste: the first states the action and placement, the second explains the functional impact. It is front-loaded with the core purpose and efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 0 parameters and no output schema, the description covers the basic purpose and effect of adjustment layers. However, as a mutation tool with no annotations, it lacks details on behavioral aspects like permissions, reversibility, or error handling, leaving gaps for an AI agent to use it correctly in complex scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately adds no parameter details, maintaining focus on the tool's purpose and usage. A baseline of 4 is applied since no parameters exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Add an adjustment layer') and resource ('above the current clip'), distinguishing it from siblings like 'add_effect' or 'add_color_correction' by specifying that adjustment layers apply effects to all clips beneath them in the timeline.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('apply effects to all clips beneath them in the timeline'), which implicitly differentiates it from tools that apply effects to individual clips. However, it does not explicitly state when not to use it or name specific alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the action ('Execute') but lacks details on permissions needed, potential side effects (e.g., changes to projects), error handling, or what happens upon execution. This is a significant gap for a tool that likely performs mutations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by a specific example in the second. Both sentences are essential, with zero waste, making it highly efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (executing arbitrary commands) and lack of annotations or output schema, the description is incomplete. It covers the input format but omits behavioral details like what commands are available, success/failure responses, or system state changes, which are critical for safe use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the 'menu_path' parameter. The description adds value by explaining the parameter's semantics with an example (e.g., ['File', 'New', 'Project...']) and clarifying the array structure, going beyond the schema's basic description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Execute') and resource ('any Final Cut Pro command by navigating the menu bar'), and it distinguishes itself from siblings by focusing on menu navigation rather than specific editing functions like 'add_effect' or 'adjust_volume'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (to execute commands via menu bar navigation) and includes an example format, but it does not explicitly state when not to use it or name specific alternatives among the many sibling tools.
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:

[![finalcutpro-mcp MCP server](https://glama.ai/mcp/servers/elliotttate/finalcutpro-mcp/badges/card.svg)](https://glama.ai/mcp/servers/elliotttate/finalcutpro-mcp)

Score Badge

Copy to your README.md:

[![finalcutpro-mcp MCP server](https://glama.ai/mcp/servers/elliotttate/finalcutpro-mcp/badges/score.svg)](https://glama.ai/mcp/servers/elliotttate/finalcutpro-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/elliotttate/finalcutpro-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server