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

No annotations are supplied, so the description must carry the full behavioral burden. It usefully discloses that the burn is hardcoded and always visible, which tells the agent the result is not a toggleable track, but it says nothing about re-encoding/quality loss, output overwrite behavior, or what happens when the subtitle path is invalid or mismatched.

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 sentences, front-loaded with the operation and scope, with zero filler. The style sentence is somewhat static detail that could be read as implying configurability that no parameter supports.

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 four-parameter media transform with no output schema, the definition covers what the tool does and what subtitle files it eats, but omits the operational facts an agent needs: re-encoding implications, output format/container rules, and failure conditions.

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 50%: input and captions are documented, output reuses the input description via $ref, and font_size has a default and range but no textual meaning. The description's format list reinforces the captions parameter and the style sentence hints at how font_size manifests, but it never explains units or that style is otherwise fixed.

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?

"Burn subtitles into the video (hardcoded, always visible)" names a specific verb and resource and distinguishes the operation from soft-subtitle embedding or the sibling extract_audio/concat tools. It does not explicitly contrast itself with any sibling, which keeps it just short of a 5.

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

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

The accepted subtitle formats (.srt, .ass, .vtt) imply the input conditions, but there is no explicit statement of when to use this versus other video tools, no prerequisite notes (e.g., that the source must already carry a subtitle file), and no 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 carries the full burden; it does disclose that the operation re-encodes, which implies quality/speed cost and codec normalization — real behavioral value. Missing are whether the output path is overwritten or must be new, what happens on mismatched resolution/framerate, and whether the call is destructive to inputs.

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 tight sentences with the core action front-loaded and the re-encode caveat immediately after. Nothing is wasted, though it is arguably too short for a 4-parameter mutation tool.

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 a small flat schema with a clear required/optional split and no output schema, the definition covers the essentials an agent needs to invoke it. The main omission is output-file behavior (overwrite vs. create) for a tool whose entire job is writing a file.

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 50%: inputs and output are documented in the schema, while audio_codec and video_codec have only defaults and no descriptions. The description's mention of re-encoding hints that codec params matter, but it does not explain them or their defaults, so it does not compensate for the gap.

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?

Names a specific verb and resource ('Join 2+ media files into one') and adds a constraint that matches the schema's minItems=2. It is clearly distinct from siblings like convert or trim, though it never names an alternative explicitly.

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 clause 'inputs may differ in codec or size' implicitly tells the agent this is safe for heterogeneous inputs, which is a useful usage signal. However, there is no explicit when-to-use/when-not guidance versus convert or other siblings, and nothing about ordering expectations beyond the schema's 'Files in order'.

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 behavioral burden. It usefully discloses the stream-copy behavior when codecs are omitted and a recommended crf default, which are non-obvious behavioral details. However, it omits critical mutation semantics: whether the output file is overwritten, whether directories are created, error handling, and any permission or environment requirements.

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 three short sentences, front-loaded with the primary purpose and followed by operational rules. Every sentence adds concrete guidance with no filler, though the ordering could slightly better group codec-related tips.

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 six-parameter mutation tool with no annotations and no output schema, the description covers purpose, stream-copy behavior, and a crf suggestion. It still leaves out preset semantics, overwrite behavior, and error conditions, so an agent would need to infer or probe those aspects before calling it confidently.

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 low (33%): only input and audio_codec have descriptions, while crf, preset, and video_codec lack explanatory text. The description partially compensates by explaining the crf default and the omit-to-copy rule for codecs, but it leaves preset values and output overwrite behavior unexplained, so the added meaning is incomplete for a six-parameter tool.

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 verb+resource ('Change container or codec'), making the tool's core function unambiguous. It does not explicitly differentiate itself from siblings like extract_audio or resize, but the scope is clear enough for an agent to recognize when a general media conversion is needed.

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 one important usage rule: omitting video_codec/audio_codec triggers stream-copy for that stream. It also offers a default crf suggestion, but it does not say when to prefer this tool over siblings (e.g., use extract_audio for audio-only extraction) or when not to use it.

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

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

No annotations are supplied, so the description carries the full behavioral burden. "Must fit inside the source frame" usefully signals a hard constraint, but the description never says what happens on violation (error vs clamp), whether the output is re-encoded, or whether the input file is touched.

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 short sentences, zero filler, with the operation front-loaded and the constraint immediately after it. Nothing is wasted.

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?

A six-parameter mutation tool with no annotations and no output schema needs more than two sentences. Overwrite behavior, output file semantics, and failure modes on out-of-frame rectangles are all left unaddressed.

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 17%, so the description must compensate, and it does add units and a validity constraint for width/height/x/y. However, it says nothing about x/y defaulting to 0, the minimum of 2 for dimensions, or the input/output path roles that the schema only partly 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?

"Crop a video to a rectangle" states a specific verb and resource, and the rectangle framing distinguishes it from the spatial sibling resize and the temporal sibling trim. It stops short of naming any sibling explicitly, so the differentiation is inferable rather than stated.

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?

There is no guidance on when to prefer crop over resize, or over extract_frame/thumbnail for static extraction. The only usage-adjacent statement is the geometric constraint, not a selection rule.

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 behavioral burden. It discloses that the output format is inferred from the output extension, but it does not explain overwrite behavior, error handling for files without audio, permissions, or what the tool returns.

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 wasted wording. The supported formats and format-inference rule are stated efficiently.

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 three-parameter media tool with no annotations and no output schema, the description covers the core operation and format selection. It remains incomplete regarding return values, failure cases, and overwrite 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?

Schema coverage is 67%, and the description adds useful meaning by clarifying that the output extension determines the format. The schema already documents the format override, so the description adds some but not comprehensive parameter context.

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 verb and resource: extract the audio track. It also lists the supported output formats, so the operation is clear. It does not explicitly distinguish itself from the sibling convert tool, which keeps it from a 5.

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 to extract audio, but it gives no explicit when-to-use guidance. It does not mention alternatives such as convert, prerequisites, or when extraction is inappropriate.

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 supplied, so the description carries the full disclosure burden, and it discloses little: nothing about how the output format is selected, what happens if the timestamp exceeds the media duration, or whether the output path is overwritten. For a file-writing operation with zero annotation coverage this is a meaningful gap.

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 short sentence, front-loaded with the action and resource, with no filler. It is efficient, though the terseness leaves the format-selection rule implicit.

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 and has only three parameters, but with no annotations and no output schema the description should clarify format inference and the default/edge behavior of the timestamp. It is adequate for the happy path but incomplete for correct invocation in ambiguous cases.

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 67% and already documents 'input' and 'timestamp' in seconds. The description adds one useful signal — that PNG/JPG/WebP are the supported output encodings — but it does not state explicitly that the format is inferred from the 'output' extension, which is the key semantic for that parameter.

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 gives a concrete verb plus resource ('grab a single frame') and scopes it with a timestamp and supported image formats, so an agent knows this produces an image still. It does not differentiate itself from the sibling 'thumbnail', which is the tool most likely to be confused with it.

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?

There is no when-to-use or when-not-to-use guidance and no prerequisites mentioned. The sibling 'thumbnail' plausibly overlaps in function, yet the description gives no rule for choosing between them.

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 behavioral burden. It usefully discloses the algorithm ('single-pass loudnorm', implying a faster but less precise one-pass normalization) and the default target, but says nothing about overwrite behavior on the output path, re-encoding/codec consequences, or whether the operation is destructive.

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 tight sentences; the operation and its default are front-loaded, and the parenthetical reference value is genuinely informative rather than filler. Nothing needs trimming.

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 four-parameter audio-mutation tool with no annotations and no output schema, the definition covers the core operation but omits output-path semantics, format handling, and any indication of what happens to the source file. Adequate to select the tool, thin for invoking it confidently.

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 only 25%, so the burden to explain parameters falls largely on the description. It does add real meaning for target_lufs by naming the -14 LUFS YouTube/Spotify convention, but leaves 'format' and especially 'output' (a $ref to the input path definition) unexplained, including whether the output must differ from the input.

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 gives a specific verb and resource ('Normalize loudness') plus the concrete mechanism ('single-pass loudnorm filter'), so an agent knows exactly what operation runs. It doesn't reference any sibling, but no sibling in the list (concat, convert, trim, etc.) overlaps with loudness normalization, so ambiguity risk is low.

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?

'Good for speech and creator audio' gives an implied when-to-use signal, but there is no explicit when-not guidance, no prerequisite (e.g. source must be audio-only or have an audio track), and no named alternative for other normalization goals.

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 supplied, so the description carries the full behavioral burden. "Inspect" implies a non-mutating read and the named backend (ffprobe) implies the tool shells out to an external binary, but the description does not state that the source file is untouched, how failures on invalid/missing paths surface, or what the response looks like. It is adequate for a trivial one-argument reader but not richly transparent.

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?

One front-loaded sentence, verb first, with the returned fields enumerated at the end. Nothing is redundant and nothing needs to be moved earlier.

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 single-parameter read-only tool with no annotations and no output schema, the description is nearly sufficient because it enumerates the return fields (duration, dimensions, codecs, streams), standing in for the missing output schema. Only the error behavior on unreadable files is left unaddressed.

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?

There is a single parameter with 100% schema description coverage ("Path to the file (relative or absolute)"), so the schema already does all the work. The description adds no constraint, format, or example beyond that, which is the expected baseline when coverage is high.

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 names a specific verb ("Inspect"), a specific resource (a media file), the underlying implementation (ffprobe), and the exact attributes returned (duration, dimensions, codecs, streams). An agent can immediately tell this is the read-only metadata tool among a sibling set that otherwise performs transformations (convert, trim, crop, concat). It stops short of a 5 only because it never explicitly contrasts itself with those siblings.

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?

Usage is only implied: the returned fields strongly suggest probing before convert/trim/resize so the agent knows duration and dimensions to work with. There is no explicit "use this before X" statement, no guidance on when a different sibling is appropriate, and no note about handling files that ffprobe cannot read.

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 and does disclose meaningful behavior: keep_aspect defaults to true, the missing dimension is derived from aspect ratio, and the result is rounded to an even number. However, it is silent on what happens when both dimensions are supplied under keep_aspect, what occurs if neither is given, whether the output file is overwritten, and whether codec/quality is preserved on this write operation.

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 tight sentences, front-loaded with the purpose and followed immediately by the parameter rule that matters most. No filler or restatement of the tool name.

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?

Adequate but not complete for a file-mutating tool with no annotations, no output schema, and 5 parameters at 20% schema coverage. Key gaps remain: the requirement for at least one dimension, the both-dimensions-with-keep_aspect case, and output file/encoding 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?

Schema coverage is only 20% (only 'input' has a description), so the description must compensate, and it does: it explains that width and height are individually optional ('and/or'), and defines keep_aspect's effect of deriving and even-rounding the other dimension — meaning the bare schema does not convey. It still adds nothing about 'output' or the minimum-2 constraint.

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?

States a specific verb and resource ('Resize a video'), which is instantly distinguishable from most siblings like trim or extract_audio. It does not explicitly draw the line against crop (spatial cut vs. scale) or convert, so an agent must infer that boundary.

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?

Implies usage by saying 'Give width and/or height', but never states the selection rule versus crop/convert/thumbnail, nor prerequisites such as needing at least one dimension. No when-not guidance at all.

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 behavioral burden. It discloses the core behavior—sampling N evenly spaced frames and tiling them into a grid—but does not mention whether the input is expected to be video, whether frames are sampled across the full duration, how the output file is written or overwritten, or what errors may occur.

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. It efficiently communicates the core operation and result.

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 five-parameter tool with no annotations and no output schema, the description covers the central behavior but omits important context such as input media type, sampling semantics, output handling, and the meaning of key parameters. It is minimally adequate but incomplete for reliable 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 only 40%, and the description partially compensates by explaining that 'frames' means N evenly spaced frames and that output is a tiled grid image, implicitly covering 'columns.' It adds no meaning for 'width,' 'output,' or the allowed ranges and defaults, so it leaves notable parameter gaps.

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 and output: build a contact sheet by tiling N evenly spaced frames into a grid image. This is clear enough to distinguish it from siblings like extract_frame or resize, although it does not explicitly name alternatives.

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?

Usage is implied by the phrase 'contact sheet' and 'evenly spaced frames,' which suggests previewing multiple points in a media file. However, the description gives no explicit when-to-use or when-not-to-use guidance relative to extract_frame, resize, or other siblings.

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 supplied, the description carries the full burden and does disclose the most important behavioral trait: re-encoding by default for frame accuracy versus fast lossless keyframe-boundary cuts with stream_copy. It omits overwrite semantics, whether output must not already exist, and the relative cost of re-encoding, so it is strong but not exhaustive.

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 dense sentences, front-loaded with the core action and followed immediately by the parameter convention and the mode tradeoff. Every clause carries actionable information with no 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?

For a 6-parameter mutation tool with no annotations and no output schema, the description covers the action, the parameter convention, and the accuracy/performance tradeoff. Remaining gaps such as overwrite behavior and error conditions when neither duration nor end is supplied are minor but real.

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%, which sets a baseline of 3, but the description adds real meaning the schema does not express: the mutual exclusivity of duration and end as alternative ways to define the clip end. That constraint is absent from the schema (no oneOf/enum), so the extra text earns a 4.

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 gives a specific verb and resource: "Cut a clip out of a media file," which is instantly distinguishable in practice from concat and extract_audio. It never explicitly names a sibling or scoping boundary, so it stops just short of the top mark.

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 clearly states the calling convention (start + duration OR end) and gives explicit guidance on the key mode decision: default re-encode vs stream_copy for speed. It offers no guidance on when to prefer trim over siblings like concat or extract_frame, which keeps it from a 5.

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