Server Quality Checklist

Tool Scores

• capcut_read_projectA
  4/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It explicitly frames the operation as 'Read', which implies read-only, and details the output fields and time unit. It does not cover error cases or permissions, but the core read behavior is well disclosed.

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

  Conciseness5/5

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

  The description is two crisp sentences. The first sentence front-loads the purpose and enumerates the return content, and the second adds the unit. Every word earns its place with no redundancy or ambiguity.

  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 single-parameter read tool with no output schema, the description gives a solid high-level picture of what is returned: tracks, segments with start time, duration, speed, and material. It lacks exact nesting details and error behavior, but the description is adequate for the agent's likely needs.

  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% because the only parameter 'project' has a highly descriptive schema comment: 'Folder name exactly as capcut_list_projects reports it.' The tool description adds no further parameter semantics, so the baseline of 3 applies.

  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 'Read one project's timeline' with a specific verb and resource, then enumerates the exact content returned (tracks, segments, start time, duration, speed, material). This unambiguously differentiates it from siblings like capcut_list_projects and capcut_project_media.

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

  Usage Guidelines3/5

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

  The description implies its use case by detailing what it reads, but offers no explicit guidance on when to choose it over alternatives or any exclusions. Sibling tools are not referenced, so the agent must infer the appropriate context from the purpose alone.

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

• capcut_create_beat_editA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden. It discloses key behaviors: cut lengths follow detected tempo, footage is sampled evenly (so short edits survey the whole video), and safety rules align with capcut_create_project. While it doesn't cover all failure modes or return values, these disclosed traits add meaningful context beyond the raw schema.

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

  Conciseness5/5

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

  The description is two succinct sentences: the first states the core purpose, the second provides a specific behavioral detail (even sampling) and a safety reference. No filler or redundant repetition of schema fields.

  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 rich schema (8 parameters, 88% described) and the creation-oriented nature, the description covers the essential algorithm (beat-synced cuts, tempo-based lengths, even sampling) and safety alignment. It omits return values or failure behavior, but for a project-creation tool these are not critical, especially when sibling tools may document them.

  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 88%, so parameters like everyNthBeat, skipSeconds, and maxDurationSeconds are already well documented. The description adds context about even sampling and tempo detection, which indirectly informs how `clips` and `source` are used, but it does not provide additional per-parameter meaning beyond the schema, matching the baseline for high coverage.

  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 'Build a new project whose cuts land on the beat' with specific details about tempo-derived cut lengths and even sampling across the source. This distinguishes it from sibling tools like capcut_create_project (non-beat-synced) and capcut_detect_beats (only detection).

  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 implies when to use this tool (when a beat-synced edit is wanted) and references 'Same safety rules as capcut_create_project' for behavioral consistency. However, it does not explicitly state when not to use it or name alternative tools for non-beat edits, missing the 'when-not' and 'alternatives' criteria for a 5.

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

• capcut_detect_beatsA
  4.2/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the full burden. It discloses the output behavior (BPM, beat spacing, beat times in seconds) and implies read-only operation through the verb 'Find'. It does not explicitly state that files are not modified, but the descriptive output is adequate for a simple detection 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 two sentences long, with the action and output front-loaded. Every sentence contributes: what the tool does, what it returns, and when it is useful. No wasted words.

  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?

  Despite the lack of an output schema and annotations, the description covers the main behavioral contract: inputs are audio-bearing files, outputs are tempo-related metrics. It does not discuss edge cases (e.g., silent files) or usage of the skipSeconds parameter, but the schema fills the latter gap. Overall, it is sufficiently complete for a straightforward detection tool.

  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 provides full descriptions for both parameters (path and skipSeconds), so the baseline is 3. The description adds no parameter-specific semantic meaning beyond what the schema already states, though it does reinforce that the tool works with audio content.

  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 'Find' and names the resource clearly: tempo and beat times of audio files. It distinguishes itself well from sibling tools like capcut_create_beat_edit or capcut_list_projects by focusing on analysis rather than creation or management.

  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 a concrete use case ('useful on its own for deciding how long cuts should be'), giving the agent context for when to invoke it. However, it does not explicitly mention when not to use it or point to an alternative like capcut_create_beat_edit.

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

• capcut_project_mediaA
  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 burden of disclosing behavior. It openly states that it reports whether each file "still exists on disk," which is a useful behavioral detail beyond simple listing. It does not mention error cases or permissions, but as a read-only listing tool, the description is adequately transparent.

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

  Conciseness5/5

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

  The description is two sentences, with the action and outputs front-loaded. Every word contributes meaning, and it avoids fluff, making it easy for an agent to parse quickly.

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

  Completeness4/5

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

  For a tool with one simple parameter and no output schema, the description covers the essential context: what it lists, what it reports (size and existence), and a concrete use case. It could have mentioned what happens if the project does not exist, but overall it is sufficiently complete for its scope.

  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%: the only parameter 'project' has a clear description in the schema ("Folder name exactly as capcut_list_projects reports it"). The tool description itself adds no additional parameter guidance, so it meets the baseline for high schema coverage without added value.

  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 "List" and clearly identifies the resource: "source files a project references." It further specifies what is included (size, existence on disk), which distinguishes it from sibling tools like capcut_list_projects (which lists projects) and capcut_read_project (which reads project details).

  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 a clear usage context: "Use this to find edits broken by moved or deleted media." This tells the agent when and why to use the tool, though it does not explicitly mention alternative tools or when not to use it. This is slightly below the top score because no exclusions or alternative mentions are present.

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

• capcut_create_projectA
  4.7/5.0
  Behavior5/5

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

  With no annotations, the description bears full responsibility for behavioral disclosure. It explicitly reveals non-obvious traits: only creates, never modifies, refuses duplicates, and requires CapCut to be closed. These are critical safety details the schema cannot express.

  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 three sentences with a clear opening statement and two sentences of critical constraints. Every sentence adds value—no redundant phrasing 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?

  The description covers the tool's effect (create), constraints (duplicate refusal, CapCut closed), and parameter behavior (trimming, canvas scaling). Even without an output schema, it provides enough context for correct selection and invocation.

  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 schema already describes all 4 parameters at 100% coverage, but the description adds meaningful semantics: clips are 'laid end to end on one track', 'each optionally trimmed', and canvas scaling states 'Clips are scaled to cover the frame rather than letterboxed.' This goes beyond the schema's per-parameter descriptions.

  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 opens with 'Build a new CapCut project from video files', a specific verb+resource+layout. It clearly distinguishes itself from siblings like create_beat_edit, list_projects, and read_project by focusing on creation from raw clips and explicitly stating it never modifies existing projects.

  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?

  States the primary use case and gives a clear exclusion: 'never modifies an existing one, and refuses if a project of that name is already there.' It also provides the prerequisite 'CapCut must be closed' and a suggested follow-up step. While it doesn't explicitly name sibling tools as alternatives, the context is sufficient for proper usage.

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

• capcut_list_projectsA
  4.7/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden. It discloses sort order (newest first), source (local draft library), and output fields (duration, resolution, track count), but doesn't explicitly state read-only nature or response format. Listing is inherently non-mutating, and the added behavioral details are useful.

  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?

  Two sentences, no fluff. Front-loads the action and immediately adds workflow guidance, with every word earning its place.

  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?

  For a simple list tool with no parameters and no output schema, the description is sufficient: it tells the user what data is returned, sorting, and its role in the workflow, including implicit project names via 'every other tool takes a project name from this list'.

  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, so there is no parameter-level meaning to add. Baseline for 0 params is 4, and there are no gaps to compensate for.

  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 lists CapCut projects in the local draft library with specific output fields (duration, resolution, track count) and sort order (newest first). It distinguishes itself from siblings by positioning as the starting point for obtaining project names.

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

  Usage Guidelines5/5

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

  Explicitly says 'Start here' and explains that all other tools take a project name from this list, providing clear when-to-use guidance and context about its role relative to siblings.

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