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

The description discloses the core behavior (burning text onto every frame) and the underlying filter. However, with no annotations, it doesn't explain that the tool creates a new output file rather than modifying the original, nor does it mention preservation of audio or any side effects. This leaves the agent to infer behavior, but the description is not misleading.

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

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

The description is a single, focused sentence that front-loads the core purpose and implementation detail. No unnecessary words or repetition.

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

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

The description is adequate for a video tool with high schema coverage. It lacks explicit mention of return values or output behavior, but for a relatively simple operation, the missing information is minor. The context signals (siblings, no output schema) make this short description acceptable.

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

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

Schema coverage is 100%—all 7 parameters have descriptions. The tool description adds context about the drawtext filter, but doesn't provide additional semantics beyond what the schema already offers. Baseline 3 is appropriate.

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

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

The description states a specific action ('Burn a text string') and resource ('onto every frame of a video'), using a known technique ('ffmpeg drawtext filter'). This distinguishes it from siblings like burn_subtitles, which handle subtitle files rather than arbitrary text.

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

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

The description clearly implies the use case: adding a static text overlay to a video. It doesn't explicitly mention when not to use it or compare with alternatives, but the context is clear enough for most agents.

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

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

No annotations are present, so the description carries full responsibility. It states the action and the ffmpeg filter, but doesn't disclose whether the input is modified, if output is a new file, if the operation is lossy, or any side effects. The schema suggests output_path, but the description doesn't confirm the behavior.

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

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

A single, clear sentence that directly states the tool's purpose without excess words. It mentions the implementation detail (ffmpeg eq filter) which is useful and concise.

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

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

Given the tool has 5 parameters, no annotations, and no output schema, the description is too sparse. It doesn't explain what happens to the output, whether the input is preserved, or what the return value is. The schema helps with parameters but the description lacks behavioral context.

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

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

Schema description coverage is 100%, with each parameter fully described in the schema. The description adds no extra detail about parameters beyond naming the three adjustable properties, which aligns with the schema. Baseline 3 is appropriate.

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

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

The description uses a specific verb 'adjust' with resource 'video' and lists the exact properties (brightness, contrast, saturation), plus mentions the ffmpeg eq filter. This clearly distinguishes it from sibling tools like adjust_volume or resize_video.

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

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. The description implies usage for brightness/contrast/saturation adjustments, but doesn't mention exclusions or when to choose convert_video or other color-related tools. The 'and/or' phrasing suggests optional combination, but no further context.

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

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

With no annotations, the description carries the burden. It discloses that the video stream is copied without re-encoding, which is a useful behavioral detail. However, it does not mention potential side effects like output file handling, overwrite behavior, or what happens to existing audio tracks, leaving some ambiguity.

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

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

Two concise sentences, front-loaded with the primary action and a supplementary detail. No wasted words.

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

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

The tool is simple, all parameters are covered by schema, and no output schema is needed. The description fully addresses what the tool does, making it complete for agent invocation.

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

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

Schema description coverage is 100%, so each parameter is well-documented. The description adds no extra parameter semantics beyond what the schema already provides. Baseline 3 is appropriate.

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

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

The description clearly states the action ('Change the audio volume of a video') and resource, distinguishing it from sibling tools like 'extract_audio' and 'strip_audio'. It also adds a relevant detail about video stream copying, which solidifies the purpose.

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

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

The description provides implicit usage context by noting the video stream is copied without re-encoding, suggesting efficiency and use cases where video quality preservation matters. However, it does not explicitly mention alternatives or when not to use this tool.

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

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

No annotations are provided, so the description carries the transparency burden. It discloses two key behavioral traits: subtitles are permanently burned into frames and re-encoding is required. However, it does not mention side effects like whether the original file is preserved, output file overwrite behavior, or processing time/quality implications.

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

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

Two sentences, front-loaded with the main purpose and immediate clarification of 'hard-code'. The second sentence explains the consequence and cost (re-encoding). No wasted words.

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

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

For a video-processing tool with no annotations or output schema, the description covers the core purpose and key constraint (re-encoding), but lacks some behavioral context like whether the original file is modified and what the output path behavior is beyond the schema. The schema covers output_path defaults, so that part is complete. Overall adequate but with gaps around side effects.

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

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

The input schema already provides 100% coverage with clear descriptions for all three parameters, so the description doesn't need to add param semantics. It adds no extra parameter detail, but none is needed beyond the schema.

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

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

The description uses a specific verb 'burn' with parenthetical 'hard-code' and states the result is permanently visible regardless of player settings, clearly distinguishing it from extract_subtitles and embed_subtitles.

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

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

It implies usage for permanent subtitle overlays by stating the result always shows regardless of player settings, but it does not explicitly name alternatives or state when not to use it. The 'requires re-encoding' note gives a practical consideration but no direct comparison to sibling tools.

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

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

With no annotations, the description carries a higher burden, and it does disclose a key behavior: both audio and video are adjusted to match. However, it omits side effects like output file creation, whether the original is modified, audio pitch handling, or failure modes.

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

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

Three short, front-loaded sentences with no filler. Each sentence adds value: the main purpose, the audio-video coupling, and the numeric speed convention.

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

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

For a straightforward tool with a rich parameter schema, the description covers the core action but does not explain output behavior or return values, which is notable given the absence of an output schema. It is minimally sufficient rather than fully self-contained.

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

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

Schema description coverage is 100%, so the baseline is 3. The description repeats the speed multiplier semantics already present in the schema but adds no additional parameter-specific meaning, such as output_path behavior beyond the schema's own note.

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

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

The description clearly states the action ('Speed up or slow down a video') and identifies the resource. It also distinguishes the tool from siblings like trim_video or adjust_volume by noting that both video and audio are adjusted together.

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

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

No explicit guidance is given on when to use this tool versus alternatives such as adjust_video or convert_video. The only implied use case is 'when you need to change playback speed,' with no exclusions, prerequisites, or alternative conditions mentioned.

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

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

With no annotations, the description carries the full transparency burden. It discloses key behaviors: lossless concatenation, no re-encoding, speed, and input compatibility requirements. This goes beyond a simple 'joins files' statement and informs the agent of critical constraints and expected performance.

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

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

Two concise sentences: the first states the core purpose, the second adds behavioral and constraint details. No filler, front-loaded with the verb phrase 'Join multiple video files', and every sentence earns its place.

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

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

Given the tool's simplicity, full parameter schema coverage, and absence of an output schema, the description sufficiently covers the main behavior, constraints, and output file creation. It could mention error handling for mismatched inputs, but the prerequisite is already stated, making this complete enough for a concatenation tool.

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

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

Schema coverage is 100%, giving a baseline of 3. The description adds semantic value by emphasizing that order matters ('in the order provided') and specifying that inputs must share codec/resolution, which directly relates to the file_paths parameter and potential failure conditions.

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

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

The description begins with a specific verb and resource: 'Join multiple video files into a single file in the order provided.' This clearly distinguishes it from sibling tools like trim, split, and convert, which perform different operations on single files or change encoding.

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

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

The description provides useful context by stating 'without re-encoding (lossless, very fast)' and the requirement that inputs share codec and resolution. This implies when to use it (lossless, quick joins) and when not to (if formats differ), though it does not explicitly name alternative tools or state exclusions.

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

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

With no annotations, the description must carry the burden of behavioral disclosure. It mentions quality control via CRF or bitrate, which is useful, but it does not elaborate on side effects like audio handling, compatibility constraints, or whether re-encoding is always performed. This leaves some behavioral ambiguity.

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

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

The description is concise, consisting of two clear sentences. It front-loads the primary purpose and immediately provides supported formats and codecs. No unnecessary words or redundant details are present.

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

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

The description is adequate for a tool with a well-documented schema, but it lacks additional context such as use cases, prerequisites, or notes on how audio streams are handled. Given the tool's complexity (6 parameters, no annotations), more context would be beneficial.

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

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

The input schema covers all six parameters with descriptions, so the baseline is 3. The description adds minimal additional meaning, merely restating that quality can be adjusted via CRF or bitrate, which is already present in the schema.

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

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

The description clearly states the tool converts videos to different container formats and codecs, listing specific supported formats and codecs. This distinguishes it from sibling tools like trim_video or extract_audio, which perform different operations.

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

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

The description clearly implies when to use the tool (when format or codec conversion is needed) and provides examples of valid formats/codecs. However, it does not explicitly mention alternatives or situations where other tools should be used, so it falls short of full usage guidance.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It clearly states the core operation (crop a video) and defines the crop region, but does not mention side effects such as whether the original file is preserved, if output_path defaults, or coordinate origin specifics. The behavior is adequately described for a simple operation but lacks depth.

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

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

The description is a single, front-loaded sentence with zero waste. It efficiently communicates the operation and key parameters without redundancy.

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

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

Given the tool's simplicity and 100% schema coverage, the description combined with the schema provides a complete picture. No output schema exists, but the tool's return behavior is not complex. The description could mention output file behavior, but the schema's output_path parameter fills that gap.

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

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

The input schema has 100% description coverage for all six parameters. The description adds the concept of a 'top-left corner (x, y)' which helps relate the parameters, but it does not add significant meaning beyond what the schema already documents.

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

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

The description uses the specific verb 'crop' and identifies the resource as 'a video' with explicit parameters for the crop region (width, height, x, y). This clearly distinguishes it from sibling tools like resize_video or trim_video, which have different operations.

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

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

The description implies usage for cropping rectangular regions but does not explicitly mention when to use this tool versus alternatives like resize_video or trim_video. There are no exclusions or prerequisite conditions stated.

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

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 openly explains that subtitles are soft and selectable, not burned into frames, and lists supported output formats. It does not cover output file creation or error scenarios, but the core behavior is transparently described.

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

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

The description is exceptionally concise: one sentence for the core action with a parenthetical clarifying the soft-subtitle nature, and a second sentence listing supported formats. Every word adds value, and no information is repeated unnecessarily.

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

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

The description, paired with the rich schema, covers the tool's purpose and key constraints. However, because there is no output schema and no annotations, the description omits the return value and whether a new file is created or the input is modified. These gaps reduce completeness for an agent that needs to predict tool behavior.

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

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

The schema already covers all 4 parameters with clear descriptions (100% coverage), so the baseline is 3. The tool description adds no meaningful parameter semantics; it merely repeats the format support already present in the output_format parameter description.

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

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

The description clearly identifies the tool's function: 'Embed a subtitle file as a soft subtitle track inside a video container'. The verb 'Embed' and the resource 'subtitle file' are specific, and the parenthetical 'selectable but not burned into the video frames' distinguishes it from burned-subtitle tools like burn_subtitles.

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

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

The description provides clear context on when to use the tool (when selectable soft subtitles are needed) and contrasts it with burned-in subtitles, effectively communicating the use case. However, it does not explicitly name an alternative tool or provide 'when not to use' guidance, which would be needed for a perfect score.

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

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

With no annotations, the description carries the full burden. It states the core behavior (extract and save audio), but does not disclose potential side effects like overwriting existing files, format conversion behavior, or quality implications. This is adequate but sparse.

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

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

The description is a single, front-loaded sentence with no filler. 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.

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

The description is sufficient for a basic extraction task, but there is no output schema or mention of return values, errors, or file overwrite behavior. Given the lack of annotations and output schema, the description leaves some operational context unexplained.

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

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

The input schema already covers 100% of parameters with clear descriptions and defaults. The tool description adds no additional parameter-level meaning, so the baseline of 3 applies.

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

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

The description uses a specific verb ('Extract') and clearly identifies the resource ('audio track from a video file') and output ('save it as a standalone audio file'). It unambiguously differentiates from siblings like extract_subtitles or strip_audio.

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

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

No guidance is given about when to choose this tool over alternatives such as strip_audio or convert_video. The description implies use for extracting audio but provides no explicit 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.

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

No annotations are provided, so the description carries the burden. It does disclose the output format (base64 JPEG), which is helpful, but it does not mention whether the operation is read-only, what happens for out-of-range timestamps, or any other behavioral constraints. Minimal but not absent.

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

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

The description is a single, front-loaded sentence that states the action, resource, and output format without any redundancy or filler. Every word earns its place.

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

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

For a simple 2-parameter tool with no output schema, the description covers the core function and return format, but lacks guidance on distinguishing this from many sibling tools (e.g., extract_frames) and does not address edge cases like timestamp bounds or file requirements.

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

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

Schema description coverage is 100% with both parameters (file_path, timestamp) already described clearly. The description adds no extra parameter details, so the baseline of 3 is appropriate.

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

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

The description clearly states a specific action ('Extract a single frame at a specific timestamp') and the resource ('video file'), with an explicit output detail ('base64 JPEG image'). This distinguishes it from sibling tools like extract_frames or generate_thumbnail_grid, which imply multiple frames.

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

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

The phrase 'single frame at a specific timestamp' implicitly suggests when to use this tool over siblings, but there is no explicit guidance, exclusion, or mention of alternatives. The intended use case is implied rather than stated.

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

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 frames are returned as base64 images that can be viewed directly, which is a key behavioral detail. However, it does not mention the output_dir alternative, potential performance implications, or error conditions. Given the lack of annotations, more behavioral context would be beneficial, but the core output behavior is disclosed.

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

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

The description is two sentences, front-loaded with the action and output format, followed by a concise use case. Every word earns its place, with no redundancy or filler.

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

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, no output schema, no annotations), the description covers the core purpose, output format, and intended use case. It does not mention the configurable time range or output_dir behavior, but those are fully described in the schema. The description is sufficiently complete for an agent to understand what the tool does and when to use it.

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

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

Schema description coverage is 100%, with each parameter already well-documented. The description does not add material semantic value beyond reinforcing that frames are evenly spaced and returned as base64 images, which aligns with the num_frames and output_dir parameters. The schema already carries the parameter semantics, so the description adds only marginal value.

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

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

The description clearly states the tool's action: 'Extract evenly-spaced frames from a video file as JPEG images.' It specifies the resource (video file), output format (JPEG), and sampling strategy (evenly-spaced). This distinguishes it from sibling tools like extract_frame_at_timestamp, which extracts a single frame at a specific timestamp.

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

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

The description gives a use case: 'Useful for understanding what happens in a video over time.' This implies when to use it but does not explicitly state when not to use it or mention alternatives like extract_frame_at_timestamp or generate_thumbnail_grid. Usage guidance is present but not fully explicit.

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

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

With no annotations, the description carries the full burden of behavioral disclosure, but it only states the core action. It does not mention potential failure modes (e.g., missing subtitle track), prerequisites, or that the input video is not modified. The description adds no deeper 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.

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

The description is a single, well-structured sentence that immediately states the tool's action and result. It contains no redundant information and is easy to parse.

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

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 only minimally complete. It does not explain error behavior, default naming conventions (though schema covers some), or how extraction interacts with other tools. It is adequate for a simple operation but lacks richer context.

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

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

The input schema provides 100% coverage of all four parameters with clear descriptions, so the description itself adds no additional parameter semantics. Baseline 3 is appropriate because the schema already handles parameter clarity.

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

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

The description clearly states the tool extracts a subtitle track from a video and saves it as a standalone file. This specific verb+resource combination distinguishes it from sibling tools like extract_audio, burn_subtitles, and embed_subtitles.

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

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

The description implies the tool is used when subtitles need to be extracted as a separate file, but it does not explicitly mention alternatives or when not to use it. Sibling tools like burn_subtitles have different purposes, yet no comparative guidance is provided.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It explains the output format (JPEG contact sheet) and layout (evenly-spaced grid), but does not mention side effects, overwrite behavior, permissions, or errors. This is minimal but sufficient for a straightforward generation tool.

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

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

Two concise sentences provide the core function and a use case. No wasted words or repetition of schema details.

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

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

The description covers purpose, use case, and output format. Given the schema fully documents parameters and there's no output schema, this is fairly complete. It could mention that thumbnails are sampled evenly across the video duration, but that's a minor gap.

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

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 four parameters. The description adds 'evenly-spaced' and 'grid' but doesn't explain parameter semantics or defaults beyond the schema, so it stays at the baseline of 3.

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

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

The description clearly states the tool's function with a specific verb ('generate') and resource ('contact-sheet image with thumbnail frames'). It differentiates from sibling tools like extract_frames by describing a grid-based overview rather than individual frame extraction.

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

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

It provides a usage context ('useful for getting a quick visual overview of a video'), indicating when to use it. However, it does not explicitly mention alternatives or when not to use it, so it falls short of the highest bar.

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

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

No annotations are provided, so the description carries the burden. It clearly indicates a read-only operation ('Get metadata') and lists expected output fields, but does not explicitly state that the file is not modified, nor does it cover error behavior or format support. The read-only nature is implied but not stated.

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

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

The description is a single, focused sentence that immediately states the tool's purpose and enumerates the metadata fields. Every word earns its place; no filler or redundancy.

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

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

With no output schema, the description compensates by listing the specific metadata attributes returned. It is sufficient for an agent to know what to expect, though it omits details like error handling or whether the result is a structured object. Given the tool's simplicity and single parameter, this is nearly complete.

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

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

Schema coverage is 100% with a single parameter whose description ('Absolute path to the video file') is clear. The tool description adds no additional parameter semantics beyond what the schema already provides, so the baseline score of 3 is appropriate.

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

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

The description uses a specific verb ('Get metadata') with a clear resource ('video file') and enumerates the exact attributes returned (duration, resolution, fps, codecs, bitrate, file size). This clearly distinguishes it from sibling tools that modify or extract content.

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

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

The description implies this is for inspecting video files rather than processing them, but it does not explicitly state when to use it over alternatives or when not to use it. Sibling tools are all mutating/processing tools, making the use case inferable, but no direct guidance is provided.

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

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

No annotations are provided, so the description carries the burden. It discloses a key behavior—preserving aspect ratio when one dimension is omitted—but does not mention output file behavior, overwrite risk, or format implications. This is useful but incomplete.

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

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

The description is a single, well-structured sentence that leads with the action and immediately explains the usage rule. Every word adds value, with no fluff or repetition.

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

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

For a simple resize tool with a fully described schema, the description is nearly complete. It explains the core optional-dimension behavior and aspect-ratio preservation. The lack of an output schema is not an issue, and the output_path default is already in the schema. Minor gaps like both-dimensions-provided behavior do not significantly hamper use.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds semantic value by explicitly stating the rule 'Provide width, height, or both' and 'preserve aspect ratio,' which clarifies the relationship between the parameters beyond the schema's individual descriptions. It effectively communicates the constraint that at least one dimension is intended.

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

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

The description clearly states the tool resizes a video to new dimensions, using the specific verb 'resize' and resource 'video'. It distinguishes itself from siblings like crop_video and rotate_video by focusing on dimension scaling, and the aspect-ratio detail adds specificity.

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

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

The description gives clear context on how to use the tool: provide width, height, or both, with the omitted dimension auto-computed to preserve aspect ratio. It does not explicitly mention when not to use this tool versus alternatives like crop_video, but the guidance is sufficient for common resizing scenarios.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the rotation operation and does not disclose whether the input file is modified or a new file is created, nor does it mention overwriting behavior or other side effects.

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

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

The description is a single, concise sentence that immediately conveys the tool's purpose with no unnecessary words. It is appropriately sized and front-loaded.

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

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

Although the description alone is minimal, the schema fully documents all parameters and the output_path default behavior, which mitigates the lack of detail. The tool is simple, and the description is sufficient for an agent to select and invoke it correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add any additional meaning to the parameters beyond what the schema already provides; it merely restates the rotation degrees.

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

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

The description clearly states the action: 'Rotate a video 90, 180, or 270 degrees clockwise.' It specifies the exact verb (rotate), resource (video), and degrees, which distinguishes it from sibling tools like resize_video or crop_video.

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

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

The description does not provide any guidance on when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. It simply states what the tool does, 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.

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose two important traits: lossless (no re-encoding) and output file naming convention ('_part_NNN'). However, it does not mention potential edge cases like what happens to the final segment if the video length is not a multiple, whether existing files are overwritten, or any prerequisites. More transparency is expected for a file-writing tool.

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

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

The description is two sentences long and front-loaded. The first sentence states the core function and lossless nature; the second explains the output naming. Every word contributes value, with no redundancy or filler.

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

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

The description covers the primary behavior, lossless splitting, and naming, but lacks information about return values (no output schema exists) and edge-case behaviors like last-segment handling or overwrite rules. Given the complexity of the operation and the absence of annotations, this is a moderate gap.

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

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

The input schema already provides 100% coverage of parameter descriptions, so the baseline is 3. The description does not add any additional parameter semantics beyond what the schema already states, such as clarifying segment_duration behavior or output_format constraints.

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

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

The description clearly states the action ('Split a video'), the resource ('a video'), and the key characteristic ('into equal-duration segments'). It also mentions 'without re-encoding (lossless)' which distinguishes it from other video manipulation tools like trim_video or convert_video.

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

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

The description implies the use case: splitting a video into equal-duration segments. However, it does not explicitly mention when to use this tool over alternatives or any exclusions. There is no reference to sibling tools like trim_video or concat_videos, so guidance is merely implied.

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

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 explicitly states the video stream is copied without re-encoding, which is a useful technical detail beyond the basic purpose. It does not disclose potential edge cases (e.g., no audio track) but covers the key behavior.

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

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

The description is two concise sentences. The first states the primary purpose, and the second provides a key technical detail. There is no redundant or filler content.

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

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

For a simple file-processing tool with two parameters and no output schema, the description is sufficient. It explains the result (silent video) and the processing method (no re-encoding). It lacks only minor details like error handling, which are not essential for basic use.

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

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

Schema coverage is 100%, and both parameters (file_path, output_path) have clear descriptions in the schema. The tool description adds no additional parameter semantics, 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.

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

The description clearly states the tool removes the audio track from a video file and produces a silent video, using a specific verb and resource. It distinguishes itself from sibling tools like extract_audio (which would extract audio to a separate file) by noting the output is a silent video.

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

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

The description implies usage when a silent video is needed, but provides no explicit when-to-use vs alternatives or exclusions. Sibling tools like adjust_volume or extract_audio are not mentioned, so guidance is only implicit.

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

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

With no annotations, the description does some work by revealing that the output is re-muxed (not re-encoded) and thus fast and lossless. However, it does not disclose side effects, whether the operation is non-destructive, or any limitations such as frame accuracy.

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

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

Two concise sentences with the primary action first. No redundant information; every phrase earns its place.

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

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

For a simple 4-parameter tool, the description covers the core operation and a key behavioral characteristic (re-muxing). It lacks explicit usage guidance but the schema fills in parameter details, and no output schema is needed.

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

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

Schema coverage is 100%, so all parameters are already described. The description adds no further semantic detail beyond the schema, 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.

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

The description clearly states the tool cuts a clip from a video using start and end times. This specific verb+resource+method distinguishes it from sibling tools like crop_video (spatial) and split_video (multiple segments).

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

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

The description implies usage for time-based clipping but does not explicitly state when to use this tool over alternatives or provide exclusions. No comparison with sibling tools is offered.

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