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

With no annotations, the description carries the full burden and does substantial work: two-pass encoding, bitrate math with a 5% margin, automatic resolution lowering, reporting whether the target was met, erroring on impossible targets, codec selection driven by output extension, and the default output filename. Remaining gaps are behavioral edge cases such as what happens when the output path already exists and overwrite=false, and whether audio/subtitle streams are preserved beyond the bitrate subtraction. That is strong but not exhaustive disclosure for a 9-parameter mutation 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?

Front-loaded with the outcome, then organized as a bullet per mode, followed by a compact pass over the remaining parameters. The bitrate-maths parenthetical is dense but it explains why resolution gets lowered, so it earns its place. No filler sentences.

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?

Nine parameters, no annotations, and an output schema that already covers return values — given that, the description supplies nearly everything needed to call the tool correctly. The one real hole is conflict resolution: it never says what happens if both target_mb and preset are provided, or whether quality is ignored when a preset is used (only implied by "neither").

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 0% and the schema declares no enums, so the description must supply all parameter meaning — and it does, covering target_mb, preset (with all five valid values and their caps), quality (low|medium|high), max_height, output (extension-to-codec mapping plus default), overwrite, dry_run, and timeout_s. Only the trivially obvious input is left undocumented. This fully compensates for the empty schema descriptions.

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?

"Make a video smaller" is a concrete verb+resource that an agent can distinguish from convert, trim, or extract_audio without opening the schema. The three named strategies (target_mb, preset, quality) further pin down what kind of operation this is. It stops short of explicitly contrasting itself with any sibling, 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 lays out three mutually exclusive selection modes and what each is for, including the case of supplying neither (CRF re-encode via quality), which is exactly the decision an agent must make. It adds useful failure context ("errors if the target is impossibly small"). It gives no guidance on when to prefer a sibling tool such as convert instead, so 4 rather than 5.

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 and does well: it discloses the no-re-encoding guarantee, the fact that mismatches fail with a diagnostic naming the differing property, and the default output location. It stops short of stating whether existing files are clobbered by default, what dry_run does, or how timeout_s is enforced.

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 core capability is front-loaded in the first clause, followed by the precondition and the failure/remediation note. No redundant sentences; the default-output remark is the only optional detail and it is genuinely useful.

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?

An output schema exists, so return values need no prose, and the hardest thing to get right — matching stream parameters before concatenation — is covered thoroughly. For a file-writing tool with zero annotations, the missing explanation of overwrite and dry_run semantics is the notable remaining 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 0%, so the description must compensate and it only partially does: it explains the constraints on 'inputs' and the default naming rule for 'output'. The three remaining parameters (dry_run, overwrite, timeout_s) are given no meaning beyond their names and defaults.

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 ('Join clips end to end') plus a defining technical property ('without re-encoding, fast and lossless'). This clearly separates it from siblings like trim, convert, and transform, which alter or slice media rather than concatenate 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?

Gives the positive condition (clips joined end to end) and the hard prerequisite (shared codec, resolution, pixel format, frame rate, audio parameters). It also names the remediation path explicitly — convert/transform them to match first — routing the agent to the correct siblings when the precondition fails.

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 burden; it does disclose key defaults: output lands next to the input, overwrite refuses by default, dry_run returns the ffmpeg command rather than executing, and timeout_s kills ffmpeg. It omits failure behavior, whether partial outputs are cleaned up, and any permission or resource constraints for a long-running ffmpeg invocation.

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?

Front-loaded purpose sentence followed by a compact format inventory and a param-by-param block; no filler. The format enumeration is dense but scannable and each clause carries distinct information.

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?

An output schema exists, so return values need no prose; the description instead spends its budget on defaults and failure-adjacent knobs (overwrite, timeout_s, dry_run), which is the right allocation for a mutating media tool with no annotations. Only error/cleanup behavior remains uncovered.

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 0%, so the description must compensate, and it largely does: format vs. output extension precedence, quality's low/medium/high trade-off, overwrite default-refuse, dry_run return semantics, and timeout_s behavior. Only `input` (accepted path/URL forms) is left unelaborated, which keeps it from a 5.

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 clear verb+resource ("Convert a file to another format") and enumerates supported target families (mp4/mov/mkv, webm, mp3/wav/flac, gif). It actively distinguishes itself from two siblings by name — make_gif for gif control and compress for size limits — so an agent can route without opening schemas.

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?

Gives explicit alternative routing for two cases: gif trimming (use make_gif) and size-limited output (use compress). No guidance on when to prefer extract_audio, transform, or concat over converting, so it stops short of full when/when-not coverage.

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 at all, the description carries the full burden and does supply useful behavior: it fails clearly when the input has no audio, it states the default output path and naming convention, and it notes that 'copy' is fast and lossless while bitrate overrides quality. It is silent, however, on the risk-relevant flags present in the schema — overwrite (a destructive write), dry_run (preview), and timeout — so the agent cannot infer side effects from the text.

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?

Front-loaded with the purpose, then structured as labeled facts (format, bitrate, failure mode, default output). Dense but every line is informative; the format enumeration earns its length precisely because the schema has no enum for it. Minor redundancy in the parenthetical asides.

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?

An output schema exists, so return values need not be explained. But for an eight-parameter file-writing tool with zero annotation coverage, the omission of overwrite and dry_run semantics is a real gap an agent needs before invoking it safely.

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 0%, so the description must compensate for eight parameters. It does well on format (full enumerated value list plus default) and bitrate ('192k' example), and explains the default output naming, but says nothing about input, quality (default 'medium'), overwrite, dry_run, or timeout_s — leaving five parameters undocumented anywhere.

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 — 'Pull the audio track out of a video (or re-encode an audio file)' — which is immediately actionable. It does not, however, distinguish itself from the sibling 'convert', which plausibly overlaps with the re-encode case, so the agent gets no explicit routing signal.

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 parenthetical hints that this doubles as an audio re-encoder, and 'copy' is framed as the fast/lossless option. There is no explicit 'use this when… / use convert instead when…' guidance, and no mention of when to prefer extract_frames or compress.

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 it does disclose useful behavior: default output directory ('name.frames' beside the input), the exact output filename patterns, and that max_frames exists to prevent thousands of files. However it never mentions `overwrite` (default false — what happens to existing files?), `dry_run`, or `timeout_s`, all of which materially affect a tool that writes files to disk.

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 mode-selection logic is front-loaded in the first two sentences and the remaining details are packed into short parenthetical clauses with no filler. The heavy use of inline parentheses makes it denser to scan than a bulleted layout would be, but nothing is redundant.

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?

An output schema exists, so return values need no explanation, and the frame-selection and naming behavior is well covered. For a 10-parameter tool with zero annotations that writes files to a directory, leaving overwrite semantics, dry_run and timeout unaddressed is a real gap an agent would have to guess about.

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 0% across 10 parameters, so the description must compensate and largely does: it explains `times` accepts numbers or timestamp strings like "0:01:30", `every_s` starts at 0, `format` defaults to png, `width` preserves aspect ratio, and where `output_dir` points by default. Three parameters — dry_run, overwrite, timeout_s — get no explanation at all, so the coverage is good but incomplete.

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 opening line gives a precise verb and resource: 'Save still images (thumbnails) from a video.' That unambiguously separates it from siblings like extract_audio, make_gif and trim without needing to name them. It stops short of explicitly routing against a sibling, so it is clear but not sibling-differentiated by name.

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 explains the three mutually exclusive modes — explicit `times`, uniform `every_s` sampling, or the fallback single middle frame — which is exactly the decision an agent must make before calling. It gives no guidance on when to prefer this tool over transform/make_gif, so it is strong on intra-tool context but silent on alternatives.

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 it does disclose real behavior: the two-pass palette approach, duration being shortened when the clip ends early, no upscaling, and that output size grows fast. It says nothing about file-writing semantics, however — overwrite behavior, where output lands when omitted, what dry_run does, or timeout handling — which matters for a tool that writes a file by default.

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 framing sentence followed by terse per-parameter clauses with defaults and hard limits, then a closing caution — front-loaded and free of filler. Every clause carries information an agent cannot get from the schema.

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 output schema exists, so return values need no explanation, and the description covers the creative/quality parameters well. The gap is the file-management and safety surface (output path, overwrite, dry_run, timeout) on a ten-parameter, annotation-free mutation 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 0%, so the description must supply all parameter meaning; it documents five of ten (start, duration with the 30s cap, fps range 1-30, width with aspect-ratio and no-upscale rules, loop). It leaves the required `input` parameter and output, dry_run, overwrite, and timeout_s entirely unexplained, so it only half compensates for the coverage 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?

"Make a high-quality animated GIF from a video" is a specific verb plus resource, and the parenthetical naming the palettegen/paletteuse technique tells an agent exactly what pipeline it triggers. It also implicitly separates itself from the still-image and re-encode siblings by routing long clips to convert.

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 final sentence gives an explicit when-not and names the alternative (use convert to mp4/webm for long clips), which is the main misuse risk for a GIF tool. It stops short of covering the other plausible siblings (trim, extract_frames, compress) or stating prerequisites, so it is clear context rather than a full routing 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 supplied, so the description carries the burden. It discloses the underlying implementation (ffprobe) and the full content of the report, and the framing as 'learn what you have' / 'check results' makes clear this is a non-mutating inspection step. It stops short of explicitly stating the file is not modified or noting any size/format limitations, which is the only gap for an unannotated 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 short sentences front-load the action and reported fields, then a terse parameter line. No filler, and the workflow guidance follows immediately after the capability statement.

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 one-parameter inspection tool with an output schema present, the description covers purpose, workflow placement, and the shape of the report, which is everything an agent needs to select and call it correctly. Return-value details are appropriately left to the output schema.

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 0%, so the description must compensate, and it does: 'input: path to an audio/video/image file' tells the agent the parameter is a filesystem path and which media categories are accepted. It adds the meaning the bare string-typed 'input' property lacks, though it offers no detail on path conventions or error behavior for unsupported files.

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 ('Summarize a media file with ffprobe') and enumerates exactly what is reported: container, duration, size, bitrate, and per-stream codec/resolution/fps/sample rate/channels. This clearly separates it from the sibling mutation tools (convert, compress, trim, extract_*), which all transform rather than inspect.

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?

Gives explicit sequencing guidance: 'Use it first to learn what you have before compressing or converting, and to check results afterwards.' It names the sibling activities (compress, convert) and the two points in the workflow where this tool applies, so the agent does not have to infer precedence.

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 to lean on, the description still carries real behavioral weight: it discloses that the operation re-encodes (a lossy, potentially slow, quality-affecting step), names the codecs, notes audio is retimed with speed changes, that crop applies before resize, and that the default output is name.transformed.ext rather than overwriting the input. The gap is safety semantics — overwrite and dry_run exist in the schema but the description never says what overwrite destroys or that dry_run previews without writing.

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?

Front-loaded with the one-sentence capability statement, then grouped by parameter with each rule compressed into a clause. No filler, no restatement of the tool name, and the units, ranges, and defaults that matter are all present in a very short block.

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 output schema means return values need no explanation, and the transformation semantics are well covered. But for a 9-parameter tool that writes a new media file, the description omits the flags an agent most needs to reason about safely (dry_run, overwrite, timeout_s) and says nothing about format inference from the output extension or failure conditions such as an existing target 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 description coverage is 0% across 9 parameters, so the description has to compensate and it only partially does. It richly explains width/height (aspect-ratio coupling), crop syntax ('W:H' centered vs 'W:H:X:Y'), speed range and semantics (0.25-4, 2 = twice as fast), and output naming, but input, output as an explicit parameter, dry_run, overwrite, and timeout_s are left entirely to the bare schema titles.

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 opening line gives a specific verb set and resource: 'Resize, crop and/or change the speed of a video'. That operation set is distinct from every sibling (convert, compress, trim, make_gif, extract_audio), so an agent can route to it without opening the schema, and the parenthetical about H.264/AAC vs VP9 adds useful precision about what re-encoding implies.

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 is effectively a parameter primer ('give one and the other keeps the aspect ratio', 'applied before resizing') rather than usage routing. It never says when to choose transform over compress (which also shrinks output) or convert, and offers no exclusions or preconditions such as requiring a valid video input. Usage is implied by the operation list, not 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, the description carries the full burden and does meaningful work: it discloses re-encoding behavior, the keyframe-snapping side effect in fast mode ("the cut may begin a little early"), and the default output filename. It omits what happens when the output file already exists (the role of overwrite) and what dry_run returns, which are notable gaps for a mutating file 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?

Front-loads the one-line purpose, then organizes the rest as short labelled lines for the time parameters and for mode. Every sentence carries information an agent needs; no restatement of the tool name 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?

An output schema exists, so return-value explanation is correctly omitted, and the tricky temporal/mode semantics are well covered for a nine-parameter tool. The remaining shortfall is operational: no statement of overwrite behavior, dry_run semantics, or the timeout default's implications.

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 0%, so the description must compensate, and it does for the hardest parameters: the accepted time formats for start/end/duration (seconds, [HH:]MM:SS[.ms], with examples), the mutual exclusivity of end vs duration, the mode values, and the output naming default. It leaves dry_run, overwrite, and timeout_s entirely to their bare names, so three of nine parameters get no added meaning.

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?

Opens with a specific verb and resource: "Cut a section out of a video or audio file." That cleanly separates it from join-oriented siblings like concat, or re-encode-only siblings like convert/compress, without the agent needing to open a schema.

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?

Gives concrete usage rules: supply start+end or start+duration, and with only start the cut runs to EOF. It also frames the accurate-vs-fast tradeoff as a selection decision (frame-exact vs instant/lossless). It stops short of explicitly contrasting against siblings such as extract_audio or make_gif, so no exclusions are stated.

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