kinocut

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

No annotations are provided, so the description carries the full behavioral-disclosure burden. It does not say whether diagnostics are read-only, whether they may mutate state, what permissions are required, or what kind of checks are performed; only an output schema exists to cover return values.

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 front-loaded sentence with zero waste. It is appropriately sized for a simple diagnostic command.

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 and fully documented parameter reduce the need for return-value explanation. However, the absence of usage guidance and behavioral disclosure leaves gaps for an agent deciding when and how to invoke 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 100%, and the single optional overwrite parameter is fully documented in the schema. The description adds no parameter-level meaning beyond the schema, so 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?

States a specific verb (Run) and resource (Hyperframes environment diagnostics). It is clear what the tool does in general, but it does not distinguish itself from sibling tools like hyperframes_validate, hyperframes_inspect, or hyperframes_info.

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?

Provides no guidance on when to use this tool versus alternatives, nor any prerequisites or exclusion conditions. The agent must infer usage from the name alone.

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, so the description carries the burden and does well: it gives the exact response shape, discloses ranking behavior ('Exact names rank first'), and warns that results describe contracts rather than installed backend availability — a real limitation an agent would otherwise misread. The unexplained 'overwrite' parameter is the one behavioral hole.

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 purpose, then return shape, then usage, then args — good ordering with no filler. Minor redundancy: the example terms 'blur, resize, subtitle, audio, trim' are listed in the body and then again in the Args 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?

An output schema exists, so explaining return fields is a bonus rather than a requirement, and the description still does it. For a 2-param discovery tool with no annotations, it covers what to pass and what comes back; only the 'overwrite' parameter and any result-count limits remain 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 50%; the description fully compensates for the undocumented 'query' by giving example terms and phrase forms, which is genuinely beyond the schema. However it never mentions 'overwrite', which is surprising for a search tool and is only described in the schema itself — an agent cannot tell from the description whether search can mutate anything.

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?

Opening sentence states a specific verb and resource ('Find registered MCP tools') plus the three lookup modes (name, keyword, task phrase). Against ~190 siblings that are all concrete media operations, this is unmistakably the meta-discovery tool.

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?

Explicitly tells the agent when to reach for it ('to find the right tool for a task without reading every description') and supplies concrete query patterns, including task phrases like 'remove filler words' and 'resume render'. It does not state when NOT to use it (e.g. when the target tool name is already known), so not a full 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 destructiveHint=true and readOnlyHint=false already declared, the description adds real value by stating the source video and audio are read only and that a new file is rendered. It does not cover the overwrite permission or what happens to the existing output file, but the safety story is largely consistent and supplemented.

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?

Four tight sentences, front-loaded with the action and output behavior, and every sentence carries information. The "Returns JSON {success, output_path}" clause is mildly redundant given an output schema exists, which keeps it off a 5.

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 10-parameter mutation with full schema coverage and an output schema, the description supplies the essential orientation: what is read, what is written, and the two key path parameters. The only notable omission is sibling disambiguation among the several audio-track tools.

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 ten parameters are already documented, and the description's mapping of video_path/audio_path and mix to replace-vs-combine mostly restates the schema. Baseline 3 is appropriate; it adds no syntax, units, or edge cases beyond what the schema already provides.

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 set (add, replace, mix) on a concrete resource (audio track in an existing video) and states that it renders a new output file, so the agent knows exactly what happens. It falls short of a 5 because it never distinguishes itself from a very close sibling, video_mix_audio, which an agent could easily confuse it with.

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?

"Use to score or re-voice a video" gives a genuine usage context and the mix flag adds a mode choice, so usage is implied clearly. But there are no exclusions and no routing to alternatives such as video_mix_audio, video_add_generated_audio, video_duck_audio, or video_audio_bed, which is a meaningful gap given how many audio-overlay siblings exist.

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 the return shape {success, output_path} and that output_path is auto-generated when omitted. It does not say whether the source video is modified, that the operation re-encodes (and is therefore lossy/quality-affecting), or what permissions/overwrite behavior apply beyond the crf/preset hints.

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 prose lead is three tight, front-loaded sentences covering purpose, return value, and scoping. The long Args block is justified given near-zero schema description coverage, though it slightly duplicates the lead sentence.

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 restating the return JSON is minor redundancy; the description fills the real gaps with per-parameter semantics and auto-naming behavior. The remaining omission is behavioral: no disclosure that rendering re-encodes the video or how overwrite interacts with existing output files.

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 8% across 13 parameters, so the description must compensate and largely does: it explains position's three syntaxes (named, pixel {x,y}, percentage {x_pct,y_pct}), that duration requires start_time, that start_time null means always visible, the CRF range and quality direction, and preset values. Only overwrite is left to the schema, which already documents it.

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+resource (overlay text on video) with concrete examples (titles, captions, watermarks) and pins scope as 'a single text element', which implicitly distinguishes it from the sibling video_add_texts. It never names that sibling or other text-related tools explicitly, so differentiation is inferred 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?

'Use to burn a single text element into a video' hints at when this tool applies versus multi-element alternatives, but no sibling (video_add_texts, video_subtitles, video_watermark, video_text_animated) is named and no when-not guidance or prerequisites are given.

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 the single-pass FFmpeg behavior, the return shape {success, output_path}, auto-generated output path, and the auto_layout default that distributes stacked texts. It does not mention overwrite semantics or permissions, though overwrite is covered in the schema.

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 purpose and return shape, then a well-organized Args block. The nested texts documentation is necessarily verbose but every line earns its place; minor redundancy in restating defaults already in 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?

Despite 7 parameters and a nested texts list, the description covers all inputs, their defaults, sub-field structure, and the return format. An agent has everything needed to invoke it correctly; the output schema being present makes the return note a bonus rather than a 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 coverage is only 14%, so the description must compensate, and it does: every parameter is documented with defaults (crf 0-51 lower=better default 23, preset enum values, auto_layout default True) and the texts dict sub-fields are fully enumerated with types 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 ('Overlay multiple text elements on a video in a single FFmpeg pass') and the plural/plural-batch scope distinguishes it from the singular sibling video_add_text. An agent can tell them apart without opening either 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?

Explicitly says 'Use when one video needs several captions at once,' which implies the alternative (single-text tool) for other cases. It stops short of naming video_add_text as the fallback, but the routing condition is clear.

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?

Annotations already flag destructiveHint=true, readOnlyHint=false and non-idempotent, and the schema's overwrite parameter documents the media-protection rule. The description adds one genuinely new behavioral fact — long renders stream MCP progress — but says nothing about the destruction/overwrite risk itself, so it is modest value on top of structured data.

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 tight sentences, front-loaded with purpose before the routing rule and parameter notes. The 'Returns JSON {success, output_path}' sentence is wasted space because an output schema already exists, but overall there is little 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?

With an output schema present, return values need no explanation, and the description covers purpose, the key alternative, the required parameter, and progress streaming. Gaps remain around quality/two_pass/bitrate selection and overwrite behavior, though annotations and schema partially backfill the latter.

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 71%, so the baseline is 3. The description restates input_path and format, which the schema already documents, and is silent on quality, two_pass, target_bitrate, and overwrite — the parameters most likely to be misused for a transcode.

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 (transcode) and resource (video into a different container or codec) with example formats. It also explicitly distinguishes itself from the sibling video_export, so an agent can choose between them without reading either 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?

"Use for format conversion; prefer video_export for delivery presets" gives an explicit alternative and the condition that selects it. It does not address adjacent siblings such as video_resize, video_hls_segment, or video_export_frames, so routing is clear only against the one named competitor.

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 full burden. It does say the call is read-only and returns JSON, but it never says what the verdict consists of, whether it blocks or just reports, or — critically — why a supposedly read-only check exposes an 'overwrite' option that allows replacing existing media. That internal tension is left unexplained.

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 front-loaded sentence with zero filler. Nothing is padded or buried.

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 covers the return shape, so the description needn't detail the verdict fields. However, for a doctor/preflight tool with no annotations, it should say what is being checked and clarify the read-only claim against the destructive-sounding overwrite parameter.

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?

Only one optional parameter and schema description coverage is 100%, so the schema already explains 'overwrite' in detail. Baseline 3 applies; the description adds nothing about the parameter and does not resolve why a read-only verdict takes an overwrite flag.

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: return a readiness verdict (preflight check) for the next video job. That distinguishes it from siblings like video_trim or video_convert, though it does not explicitly contrast with the nearest peers (video_quality_check, hyperframes_doctor, video_rescue_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?

'Readiness verdict for the next video job' implies a preflight/doctor step, but there is no statement of when to call this versus video_quality_check, hyperframes_doctor, or video_rescue_inspect, and no prerequisites or when-not-to-use 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?

No annotations are provided, so the description carries the full burden. It does disclose non-obvious behavior: automatic output path generation and the fallback sampling strategy. It omits, however, whether the call writes a new file into the workspace, how existing files at output_path are treated (the schema's overwrite flag hints at collision protection but is never explained), and what errors occur on invalid timestamps or missing files.

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 core action, followed by the sampling rules, then a compact Args block – efficient and scannable. The opening clause about matching "CLI and Python frame extraction" adds little for an MCP agent and could be cut.

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 needn't be explained, and the sampling logic is covered. But with zero annotations on a tool that produces a file, the agent is left to infer side effects, overwrite protection, and failure modes; that is a meaningful gap for a write-producing operation.

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 25%, so the description must compensate, and it largely does: it explains input_path must be absolute, timestamp semantics including the None and 0 cases, and that output_path is auto-generated when omitted. The overwrite parameter is not addressed in the description, but the schema itself documents it well, so the only gap is redundancy rather than omission.

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 ("Extract a frame") and clarifies the sampling behavior, so the agent knows exactly what it produces. It does not distinguish itself from plausible siblings like video_thumbnail, video_export_frames, or video_seek_frame, and the reference to "CLI and Python frame extraction" points outside the tool catalog rather than at an alternative MCP tool.

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 gives useful parameter-level usage rules (omit timestamp for smart selection with a 10% fallback; pass 0 explicitly for the first frame), which is more than nothing. But it never says when to choose this over video_thumbnail or video_export_frames, nor any preconditions such as path validity or video format support, so usage is only 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 the description carries the full burden and does well: it discloses cost (exact=true decodes the whole stream, so it is slower), what extra fields result, and that raw rate strings may be null. It never states this is a read-only/no-side-effect operation explicitly, nor mentions the overwrite parameter present in the schema, leaving a small 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?

Front-loaded with purpose, then return shape, then the when-to-use hint, then parameter detail — a logical order with no filler. The Args block partially duplicates the prose but earns its place by adding semantics the prose only implies.

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 and the description still usefully previews the returned fields; the performance tradeoff of exact is covered. What remains unaddressed is error/edge behavior (non-video or missing files, overwrite interaction) and differentiation from the other inspection siblings.

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 33%, but the description compensates by explaining both key parameters: input_path must be an absolute path to an existing file, and exact triggers a full decode returning frame_count, frame_count_source and raw ffprobe rate strings. The third parameter (overwrite) is omitted from the Args block, so coverage is high but not complete.

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+resource ("Probe a video file for metadata") and immediately describes the return shape, so an agent can distinguish it from siblings like video_doctor or video_quality_check which analyze content rather than report container/stream metadata.

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?

"Use before any edit to learn the source's dimensions and length" gives a clear triggering condition for a typical workflow. It does not name an alternative tool or state when not to use it (e.g. versus video_doctor or video_rescue_inspect), so it stops short of a 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?

Annotations already declare destructiveHint=true and non-idempotent, so the safety bar is lower; the description still adds real context: output is auto-named or written to output_path, and concatenation produces a 'rendered output file' rather than metadata. It does not state re-run cost, processing time, or re-encoding behavior, keeping it below a 5.

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 action and followed by usage and parameter constraints; nothing is padded. The 'Returns JSON {success, output_path}' sentence is slightly redundant given the tool has an output 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?

For a six-parameter mutation tool with full schema coverage and an output schema, the description covers action, ordering constraint, minimum input count, and output destination handling. Remaining gaps (failure modes on incompatible clips, transition-duration constraints) are documented in the schema, though failure behavior is nowhere stated.

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 reinforces the two most important semantics an agent could miss — clips must be an ordered list of absolute paths and at least two are required — but adds nothing about transition, transitions, or overwrite 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 a specific verb and resource ('Concatenate two or more existing video clips into one rendered output file') and restates the join intent in a second sentence. It is immediately distinguishable from analysis siblings (video_info) and image-sourced siblings, though it never explicitly names a nearest alternative such as video_composite_layers or video_create_from_images.

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?

'Use to join ordered clips into a single video' implies the use case, and the ordered-list requirement adds practical setup context. There is no when-not-to-use guidance, no mention of alternatives, and no prerequisites (codec/resolution compatibility of inputs is unaddressed).

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 the folder structure and output_dir default, but does not explain overwrite behavior, what happens if the project already exists, permissions needed, or other mutation safety details.

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 short and front-loaded: the purpose appears in the first sentence, followed by only the argument details that add value beyond the schema. No sentence 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?

For a three-parameter scaffold tool with an output schema, the description covers the core creation behavior and two of the three parameters. The remaining overwrite behavior is documented in the schema, so the definition is largely complete, though the lack of annotations means safety context is thin.

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 33%, but the description compensates well for two of the three parameters: it specifies the slug format (lowercase letters, numbers, hyphens, underscores) and explains output_dir as the base directory defaulting to the current working directory. The overwrite parameter is documented in the schema itself.

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: 'Scaffold a cinematic video project' and names the folders it creates (style, storyboard, refs). It is clear what the tool does, but it does not distinguish itself from siblings such as video_init_project or hyperframes_init.

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 word 'Scaffold' implies project initialization, but the description gives no explicit when-to-use guidance, prerequisites, or alternative tools. An agent must infer that this is for starting a new project rather than any sibling create/init 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?

With no annotations, the description carries the full burden; it does disclose the analysis dimensions and that results come back as scores plus recommendations, and explains that warnings can be escalated to failures. It does not state that the operation is read-only/non-destructive, whether it writes artifacts, or how long/costly the analysis is — meaningful gaps for a media-processing tool with zero annotation coverage.

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 core action and scope, then a compact Args block; every line carries information. Slight redundancy between 'Returns quality scores and recommendations' and the presence of an output schema, but nothing wasteful.

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 little explanation, and the analysis dimensions are covered. Missing: whether the call is safe/non-mutating, what happens to existing files, and why `overwrite` is a parameter at all on a 'check' tool — an agent could be surprised by write 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 only 33%, so the description must compensate. It does document input_path (absolute path) and fail_on_warning (treat warnings as failures) with meaning beyond the schema, but leaves the safety-relevant `overwrite` flag entirely unexplained even though it governs whether existing media is replaced.

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 ('Run visual quality checks on a video') and enumerates the analyzed dimensions — brightness, contrast, saturation, audio levels, color balance — which helps distinguish it from abstract QC siblings. However, it never names or contrasts with the many closely-named siblings (video_design_quality_check, video_metric_qc, video_qc_vision, video_qc_narrative, video_compare_quality), so an agent must infer the 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?

There is no guidance on when to use this versus alternatives, despite an unusually crowded QC family in the sibling list. No prerequisites, no exclusions, no mention of which check suits which stage of a pipeline.

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 behavioral burden, but it does not disclose whether inspection is read-only, whether it can mutate artifacts, or what happens when integrity checks fail. The presence of an overwrite parameter in the schema suggests possible mutation, yet the description does not address that risk or any permission 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 a single, front-loaded sentence with no filler. The action and target are immediately clear.

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 an output schema exists, the description is too sparse for a rescue-inspection tool that accepts an overwrite option and has no annotations. It omits mutation risk, prerequisites, and the relationship to the plan/render steps, leaving important context for safe invocation unstated.

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%: the overwrite parameter is documented in the schema, while the required receipt parameter is not described. The description partially clarifies that the receipt relates to a rescue plan or receipt, but it does not explain the expected format or how the receipt identifies the plan.

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 clear verb and resource: inspect a rescue plan or receipt and re-check artifact integrity. It distinguishes the tool from video_rescue_plan and video_rescue_render by framing it as an inspection step, though it does not explicitly name 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?

There is no explicit guidance on when to use this tool versus alternatives such as video_rescue_plan, video_rescue_render, or other inspection tools. The phrase 're-check artifact integrity' only weakly implies post-plan or post-render verification.

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 two real behavioral facts: aspect_ratio overrides width/height, and output_path is auto-generated when omitted. It does not cover re-encoding/lossiness, overwrite behavior (which the schema documents but the description omits), or what error occurs if neither width/height nor aspect_ratio is given.

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 summary followed by a compact per-argument list; no filler sentences. Mild redundancy between 'Resize a video or change its aspect ratio' and the following 'Use to fit a video to target dimensions or a preset ratio' keeps it from a 5.

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 the brief return-value note is sufficient. But the combination rule between width/height and aspect_ratio is only half-stated ('Use with height'), and the overwrite safety flag present in the schema is never referenced in the description, leaving gaps for a 7-parameter mutation tool with no annotations.

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 14%, but the description compensates well: it enumerates the accepted aspect_ratio values (16:9, 9:16, 1:1, 4:3, 4:5, 21:9) and quality presets (low, medium, high, ultra), neither of which appears as an enum in the schema. Only the overwrite parameter is left to the schema's own 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?

States a specific verb and resource ('Resize a video or change its aspect ratio') and names the two modes of operation (target dimensions or preset ratio). It does not, however, distinguish itself from adjacent siblings like video_crop, video_rotate, or video_convert, so an agent must infer the boundary itself.

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?

Offers implied usage ('Use to fit a video to target dimensions or a preset ratio') and one useful upstream hint ('input_path ... e.g. from video_info'), but never says when to prefer crop or convert instead, nor what happens when no dimension argument is supplied. Usage is inferable but not spelled out.

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, yet it does not state that the tool likely writes files, what a review package contains, whether publishing is blocked or merely reported, or what permissions are needed. The schema's overwrite parameter hints at replacing existing media, but the description never warns about destructive behavior or file-protection rules.

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 single sentence is front-loaded and free of filler. It is concise, though its brevity contributes to the larger completeness problem rather than being a virtue by itself.

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 has four parameters, no annotations, and only 25% schema coverage, so the description needed to carry substantial context. It does not explain what the package includes, what the verdict means, or how blocking_findings changes behavior. The existence of an output schema excuses it from describing return values, but not from the rest.

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 25%, and the description adds no parameter-level meaning at all. Only overwrite is documented in the schema; project_dir and candidate_artifact are left to inference from their names, while blocking_findings is entirely unexplained despite likely affecting the publish-gate verdict.

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 verb (assemble) and two outputs (review package and publish-gate verdict), giving a rough sense of the tool's job. However, "review package" and "publish-gate verdict" are undefined jargon, and it never distinguishes this tool from the many review/publish siblings such as video_publish_gate, video_review_run, video_review_decide, video_verdict, and video_acceptance_eval.

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 use this tool versus alternatives, no prerequisites, and no exclusions. An agent seeing video_review_package next to video_review_run, video_publish_gate, and video_review_decision has no textual basis for choosing among 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 burden of behavioral disclosure and comes up short. It doesn't say that this writes/export media files, whether outputs overwrite by default, or what permissions/paths are required; 'export' hints at file creation but nothing about side effects is 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?

A single front-loaded sentence with no filler, and the sequence of operations is easy to scan. It is arguably too terse for a 5-parameter composite tool, but there is no wasted text.

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 covers return values, but for a complex 5-parameter tool with nested segment structures and zero annotations, the description leaves too much open: segment format, style semantics, output location, and overwrite behavior are all 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 description coverage is only 20% (just the overwrite flag), so the description needs to compensate but doesn't. It never explains what 'style' controls, the expected shape of a 'segments' entry, or how output_path is used, leaving 4 of 5 parameters semantically undocumented across both description and 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 names four concrete operations (trim, caption, make vertical, export) on a specific resource (selected segments), which tells an agent exactly what capability this composes. The phrase 'in one call' implicitly distinguishes it from the single-purpose siblings like video_trim, video_add_text, and video_resize, though it doesn't name them.

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 'in one call' hints that this is the combined/batch alternative to chaining individual tools, which is useful routing context. However, it never states when to prefer this over the sibling tools or when not to use it, leaving the agent to infer the tradeoff between one-shot composition and granular control.

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?

The annotations already declare readOnlyHint=false, destructiveHint=true, idempotentHint=false, and openWorldHint=false. The description adds useful behavioral context beyond that: it creates a new output file, leaves the source video unchanged, and returns JSON with success/output_path, though it does not discuss overwrite behavior or permissions.

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 short, front-loaded with the core action and result, and every sentence contributes useful information. The return format is mentioned briefly without bloating the definition.

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 rich input schema, existing output schema, and annotations covering safety and mutation profile, the description is complete enough. It supplies the key mental model: a new video is rendered, the source is untouched, and the factor controls slowdown or speedup.

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%, and the factor parameter already documents 2.0 as double speed, 0.5 as half speed, and 1.0 as unchanged. The description restates input_path as the source and clarifies above/below 1.0 behavior, but adds little meaning beyond the schema, so the 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 verb and resource: rendering a new video with changed playback speed, while explicitly noting the source video is unchanged. It also frames the intended effect as slow-motion or fast-forward, but does not explicitly distinguish itself from siblings such as video_reverse or video_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?

It gives clear usage context by saying to use it for slow-motion or fast-forward effects. However, it does not name alternatives or state when not to use this tool, so routing versus other video-edit siblings is left 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 carries the full burden, and it delivers real behavioral detail: the return shape {success, output_path}, auto-generated output paths, and the important caveat that accurate=False uses fast input seeking and 'may land on the nearest keyframe'. It omits overwrite/error behavior, but the overwrite parameter is at least documented in the schema.

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?

Purpose and return value are front-loaded in the first two sentences, followed by practical guidance, with the Args block last. The Args block repeats some parameter names already visible in the schema, adding modest redundancy but earning its place through format examples.

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 7-parameter tool with 14% schema coverage, the description fills nearly all the semantic gaps an agent needs: timestamp formats, exclusivity, output path defaults, and the accuracy/speed tradeoff. Output schema exists so return-value detail is not strictly required, and the overwrite guard is covered by the 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 only 14%, so the description must compensate, and it largely does: it documents input_path (absolute path), start (timestamp or numeric seconds), duration, end, output_path (auto-generated if omitted), and accurate (slower, keyframe caveat). Only overwrite is left to the schema, which does describe it adequately.

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 ('Trim a video clip') plus the scope of the result ('cut a segment out of a longer video'), which is enough to place it apart from merge, split_screen, or crop siblings. It does not name any specific sibling it competes with (e.g. video_edit, video_export_frames), so it stops short of the top score.

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 a clear operating context ('Use to cut a segment out of a longer video') and a prerequisite chain by pointing at video_info for the input path. It also flags the duration-vs-end mutual exclusivity, which prevents a common wrong call. No explicit when-not-use guidance or named alternative 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?

With no annotations, the description must carry the full behavioral burden; it does disclose the checks performed and that output is a warnings list plus a clean boolean. It never says whether the tool is purely analytical or may write files, which matters because the schema exposes an `overwrite` parameter described as "allow replacing existing media" — an agent cannot tell whether this tool mutates anything. Warning severity levels are also undisclosed.

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 purpose and check list, then structured Args/Returns sections — each line carries information. The Args block slightly over-indents across lines and the Returns line is redundant given the output schema, costing a little economy.

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 validation tool with a loose schema, the overlay contract is well covered and the output shape need not be restated since an output schema exists. Gaps remain: the `overwrite` parameter's purpose, whether any side effects occur, and how warnings are ordered or prioritized relative to the `clean` flag.

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%, but the description compensates strongly by enumerating the overlay spec keys (text, position, size, color, shadow, start_time, duration), which the schema leaves as an untyped `additionalProperties: true` object, and by explaining what video_width/height and background_color are used for. It omits the `overwrite` parameter entirely, leaving one of five parameters unexplained.

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 ("Validate a set of text overlays") and enumerates exactly what is checked: overlap, contrast, safe positioning, overlay density, missing shadows. It is clearly distinguishable from sibling mutators like video_add_text or video_add_texts, though it never names them 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 phrase "before rendering" gives a clear workflow slot for when to call it. It does not, however, state exclusions or point at the alternative (e.g., call video_add_text to apply overlays after validation passes, or video_preflight/quality_check for whole-video checks), so routing is inferred rather than 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 and does so: it declares the operation strictly read-only ('Nothing is rendered or modified'), specifies the fail-closed error surface (invalid_workflow_receipt on malformed/unreadable input), and explains that hash verification is a live re-check of recorded hashes against bytes currently on disk. It also discloses the legacy kind-inference behavior and the shape of the returned normalized report.

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 a one-line summary, then a detail paragraph, then an Args block — a sensible order. It is verbose in places (reST backticks, the unexplained '(N3)' tag) but nearly every clause conveys a real behavioral fact.

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 optional, yet the description valuably previews the normalized report fields (kind, schema_version, per-step statuses, hash integrity, warnings, cleanup state). What's missing is any statement about the orphaned overwrite parameter and any routing to the alternative validate/rescue-inspect tools.

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 33%; receipt_path and compare_path have no schema descriptions, and the description compensates well for those two (absolute path to the receipt JSON; optional second receipt producing a diff). However, the third parameter, overwrite, is never mentioned in the description, and its 'allow replacing existing media' semantics sit oddly on a tool declared read-only, leaving an unresolved ambiguity.

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 — read and summarize a workflow render receipt / dry-run workflow_plan artifact / layer_plan receipt — and enumerates the accepted receipt variants (v1 legacy lacking receipt_kind, v2). It also states what it does not do ('Nothing is rendered or modified'), implicitly separating it from the render/plan siblings. It never names a specific sibling (e.g. video_workflow_validate or video_rescue_inspect) to disambiguate, so it stops 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?

Gives clear context for use: point it at a receipt_path to get a normalized inspection, optionally with compare_path for a diff (N3). It explains the legacy tolerance (kind inferred from the tool field when receipt_kind is absent), which tells the agent this is safe on older artifacts. It does not say when to prefer video_workflow_validate, hyperframes_inspect, or video_rescue_inspect instead.

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