Server Quality Checklist

Tool Scores

• ffkit_extract_audioB
  3.2/5.0
  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 core operation but does not disclose whether the operation is destructive, whether it requires specific permissions, what happens to the original file, or any side effects (e.g., temporary files, licensing). The description is minimal and does not add behavioral context beyond the action itself.

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

  Conciseness5/5

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

  The description is two sentences, front-loading the primary action. Every word contributes meaning with no redundancy. It is efficiently sized for quick comprehension.

  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 has 5 parameters (2 required) and no output schema, the description is too brief. It does not explain what the output file contains, the return value format, error conditions, or that the original file is preserved. The context is incomplete for an agent to fully understand the tool's behavior and expected 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?

  Schema description coverage is 100%, so the schema already documents each parameter. The description adds minimal extra meaning beyond the schema, such as the option to re-encode, but this is already implied by the codec parameter description. With high coverage, a baseline of 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the action ('Extract the audio stream') and the resource ('from a video/audio file'). It also mentions the re-encoding capability, which distinguishes it from sibling tools like ffkit_add_subtitles or ffkit_clip that serve different purposes.

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

  Usage 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 (e.g., ffkit_transcode). It lacks explicit when-to-use or when-not-to-use conditions, and does not mention any prerequisites or context that would help an agent decide between this and sibling tools.

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

• ffkit_transcodeA
  3.6/5.0
  Behavior3/5

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

  With no annotations provided (no readOnlyHint, destructiveHint, etc.), the description carries the full burden of behavioral disclosure. It mentions that 'the output container is inferred from the file extension,' which is a useful behavioral trait. However, it does not disclose whether the operation is destructive (e.g., overwrites output), whether it requires disk space for the output, or details about error handling (e.g., what happens with invalid codecs).

  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 followed by a brief note about container inference. It is concise and front-loaded with the main purpose. One could argue it could be slightly longer to add usage guidelines or behavioral notes, but it is not overly verbose.

  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 (9 parameters, 2 required) and lack of output schema or annotations, the description is adequate but not complete. It explains the core function and one important inference, but it lacks guidance on parameter relationships (e.g., interaction between bitrate and CRF) and error behavior. A more complete description would also mention typical usage patterns.

  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%, meaning all 9 parameters have descriptions in the input schema. The description adds minimal semantics beyond the schema: it mentions that the output container is inferred from the extension, which relates to the output_path parameter. For the most part, the description does not add substantial meaning over 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 states the tool's purpose: 'Transcode a media file to a different format, codec, or resolution.' It specifies the action (transcode), the resource (media file), and the possible transformations. It also distinguishes itself from sibling tools (which focus on subtitles, clipping, audio extraction, and merging) by being the general transcoding tool.

  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 general media conversion but provides no explicit guidance on when to use this tool versus the siblings. It doesn't state prerequisites (e.g., input file must exist) or when not to use it. However, the sibling names offer some implicit differentiation.

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

• ffkit_clipA
  4/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 clearly states the effect (trimming a segment) and specifies time format constraints (HH:MM:SS.ms or seconds). It does not cover side effects, output format, or whether the operation modifies the original file, but given the lack of annotations, the description's transparency is strong for a simple trimming 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 concise sentences, with zero waste. Each sentence provides essential information: the action and the parameter alternatives plus time format. It is well front-loaded with the main purpose.

  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 moderate complexity (5 parameters, 3 required), no output schema, and no annotations, the description covers core usage adequately. It explains the trimming operation, parameter combinations, and time format. It could be improved by noting expected output format or that the operation is non-destructive, but it is largely complete for a straightforward trimming 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?

  Schema description coverage is 100%, so the schema already documents all parameters. The description adds some value by explaining the mutual exclusivity of end and duration, and by specifying allowed time formats. However, it does not clarify what happens if both end and duration are omitted or both provided beyond the schema's 'mutually exclusive' hints.

  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 specific verbs ('Trim a segment from a media file') and clearly identifies the resource (media file). It also distinguishes the tool from siblings by stating the action (trim) as opposed to adding subtitles, extracting audio, merging, or transcoding.

  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 basic usage context (trim a segment) and mentions the two mutually exclusive parameter groups (start+end or start+duration). However, it does not differentiate from sibling tools explicitly, nor does it state when not to use this tool (e.g., for concatenation or format conversion).

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

• ffkit_add_subtitlesA
  4.3/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 of behavioral disclosure. It effectively describes the two behavioral modes, clarifying that 'burn' permanently alters pixels. For a non-destructive operation like 'embed', no further behavioral caveats are needed, but some details about encoding support could improve transparency.

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

  Conciseness5/5

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

  The description is a single, well-structured sentence—front-loaded with the purpose, followed by clarification of the key parameter. Every word adds value with no redundancy or fluff.

  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 4-parameter tool with 100% schema coverage, 3 required parameters, and no output schema, the description is complete. It explains the purpose, the critical mode parameter, and the supported subtitle formats. No further information about return values is needed since there is no output schema, and the tool's effect is straightforward.

  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 each parameter (input_path, output_path, subtitle_path, mode) already has a description. The description adds value by explaining the enum values 'burn' and 'embed' more concretely, but does not provide extra semantics for the path parameters beyond what the schema already defines.

  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 'add' and the resource 'subtitles to a video'. It distinguishes between the two modes 'burn' and 'embed', explaining their effects. This helps differentiate from sibling tools like ffkit_clip, ffkit_extract_audio, ffkit_merge, and ffkit_transcode.

  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 implicitly guides usage by explaining when to use 'burn' (hard-coding into pixels) vs 'embed' (soft subtitle track). This helps the agent choose the appropriate mode, but does not explicitly state when not to use this tool or suggest alternatives.

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

• ffkit_mergeA
  4.4/5.0
  Behavior4/5

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

  Without annotations, the description fully carries the burden of behavioral disclosure. It states that the tool concatenates media files, explains two merge strategies (fast vs re-encodes), and implies the output is a single file. This is clear and sufficient for a straightforward tool with no destructive or auth concerns. No contradictions 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?

  Two sentences, zero wasted words. Each sentence earns its place: the first states the purpose, the second gives usage guidance. The structure is front-loaded with the action first, followed by method-specific details.

  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 no output schema and simple parameters, the description adequately covers what the tool does and how to choose the method. It could be slightly more complete by mentioning the file format requirement for concat_demuxer (same codec), but the 'same codec' hint suffices. No critical gaps remain.

  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 describes each parameter. The description adds value by explaining the trade-off between concat_demuxer (fast, same codec) and concat_filter (re-encodes, cross-format) – critical semantic context beyond the schema's enum labels. Input_paths and output_path are self-explanatory, so no extra detail needed.

  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 ('Concatenate') and resource ('multiple media files') that clearly states the tool's function. It also distinguishes between two methods (concat_demuxer vs concat_filter), adding precision. Among sibling tools like ffkit_clip or ffkit_extract_audio, this description uniquely identifies merging behavior.

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

  Usage Guidelines4/5

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

  The description provides explicit guidance on when to use each method (same codec vs cross-format), which helps the agent choose correctly. However, it does not mention when not to use this tool versus alternatives like ffkit_clip or ffkit_transcode for related tasks (e.g., trimming or conversion).

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