Server Quality Checklist

Tool Scores

• build_timelineA
  3.8/5.0
  Behavior3/5

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

  Discloses output files, default durations, and that out_dir is created if missing. No annotations provided, so description carries burden; lacks details on permissions, error handling, or reversal, but adequate for a non-destructive assembly 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?

  Three sentences, each serving a distinct purpose: purpose/output, specific file types, assembly behavior. No wasted words, efficiently front-loaded.

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

  Completeness4/5

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

  Covers outputs, defaults, directory creation. No output schema, so description explains return value implicitly. Could mention error behavior, but overall sufficient for the tool's complexity.

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

  Parameters3/5

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

  Schema coverage is 100% with descriptions for all parameters. The description adds context (e.g., 'already-downloaded', defaults for still/video) but does not substantially extend beyond schema; baseline score of 3 is appropriate.

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

  Purpose5/5

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

  Clearly states it writes a timeline from downloaded clips, specifies output formats (FCPXML, EDL, manifest), and distinguishes from siblings like build_premiere_script (script output) and place_in_resolve (direct placement).

  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?

  Implies usage when clips are already downloaded and a timeline is needed, but does not explicitly state when to avoid this tool or mention alternatives like build_premiere_script or place_in_resolve.

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

• download_assetA
  3.9/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden. It discloses that the tool works for all asset types, creates directories if missing, and notes the YouTube URL nuance. However, it does not mention overwrite behavior, error handling, or return values. Adequate but not rich.

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

  Conciseness5/5

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

  The description consists of two efficient sentences. The first states the primary purpose, and the second adds a critical nuance about YouTube. No wasted words; front-loaded and to the point.

  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 output schema, the description should explain return values (e.g., saved file path, success status). It does not. It also omits error cases or prerequisites beyond the URL source. While it covers core functionality well, the lack of return value documentation is a notable gap.

  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 all three parameters. The description adds context that 'url' is from search_broll and that 'dir' is absolute and created if missing, but this does not significantly exceed what the schema provides. Baseline 3 is appropriate.

  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 downloads a single asset URL to a local file for timeline use, and specifies it comes from search_broll's download_url. It distinguishes from siblings like build_premiere_script, build_timeline, and place_in_resolve, which handle other stages of asset processing.

  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 gives context that all asset types are downloadable and adds a specific note about YouTube (page_url for moving clips). It implies usage after search_broll but lacks explicit when-not-to-use or alternative tool guidance. Clear context but no exclusions.

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

• place_in_resolveA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden. It discloses the required state of Resolve, the import/appending behavior, and timeline creation. It does not mention error handling or limits, but the core behavioral traits are well communicated.

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

  Conciseness5/5

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

  The description is two sentences with no fluff. The first sentence delivers the core purpose, and the second adds a crucial prerequisite. Every word earns its place.

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

  Completeness4/5

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

  Given the tool's simplicity (one parameter, no output schema, no nested objects), the description covers the essential actions and prerequisites. It could mention error handling or fallback behavior, but is sufficiently complete 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 coverage is 100% with a single parameter 'clips' well-documented in the schema. The description adds emphasis on 'already-downloaded' and 'DIRECTLY', but does not significantly enhance understanding beyond what the schema already provides.

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

  Purpose5/5

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

  The description clearly specifies the action ('Insert already-downloaded clips DIRECTLY onto the open DaVinci Resolve timeline'), the resource (clips), and the additional steps (imports into media pool, appends to timeline). It effectively distinguishes this tool from siblings like build_premiere_script and build_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 states a key prerequisite (Resolve running with external scripting enabled) and implies when to use (after downloading clips). It lacks explicit 'when not to use' or alternatives, but the context of siblings and the specific phrasing provide adequate guidance.

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

• build_premiere_scriptA
  4.3/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden. It discloses the core behavior (generates a script that appends clips to the active sequence) and that the script file is written to out_dir. However, it does not mention potential error conditions (e.g., if no sequence is open) or side effects beyond timeline modification.

  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 consists of three efficient sentences: purpose, usage, and identity. Every sentence adds unique value, and there is no redundancy or filler.

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

  Completeness5/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 (2 parameters, no output schema, no annotations), the description covers all essential aspects: what it does, how to use it, prerequisites, and the output file. No gaps are evident.

  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 coverage is 100%, so the schema already documents both parameters. The description adds value by explaining that clips are 'chosen' and appended in order, and that out_dir is created if missing. It also clarifies the default duration for stills (5 seconds).

  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 uses a specific verb ('generate') and resource ('Premiere Pro script'), and clearly states the action ('imports the chosen clips and appends them to your ACTIVE sequence'). It distinguishes from siblings by calling it 'the direct-to-timeline path for Premiere'.

  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 explicit context on when to use the tool ('Run it in Premiere via File > Scripts... with a project + sequence open') and implicitly contrasts with sibling tools (e.g., place_in_resolve). It does not explicitly state when not to use it, but the guidance is clear.

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

• search_brollA
  4.4/5.0
  Behavior4/5

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

  Since no annotations are provided, the description carries the full burden. It transparently states 'Returns assets with direct, downloadable URLs (images: full_url, stock video: video_url).' This discloses the output format and indicates it's a read-only operation. No destructive behavior is implied.

  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 compact at two sentences, front-loading the core purpose and then providing usage hints. Every sentence is informative without redundancy.

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

  Completeness4/5

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

  For a search tool with 3 parameters (one required) and no output schema, the description explains the return value (URLs) and hints at weighting. It is complete enough for an agent to use correctly. Minor gap: no mention of pagination or result limits, but not critical.

  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 100% parameter description coverage (e.g., 'query' description, 'aspect' enum descriptions, 'weights' nested description). The description adds value by summarizing how to use weights and aspect, and by specifying the return URL types, which is not in the schema. This adds meaning beyond the schema.

  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: 'Search B-Roll Studio for real, embeddable b-roll for a topic or moment.' It specifies the resource (B-Roll Studio) and the action (search), and differentiates from siblings which are about building scripts, timelines, downloading, or placing assets.

  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 explicit usage guidance: 'Use the weights to bias the mix (0=off..3=heavy) and aspect to set the frame shape.' It does not explicitly state when not to use or mention alternatives, but the context is clear for an agent.

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