Loading ToolBench
A video editing skill providing 6 bash scripts for video processing tasks including trimming, jump cuts, captioning, transcription, text overlays, and speed adjustment using FFmpeg and Whisper
This bash-based video editing toolkit has moderate naming clarity and reasonable descriptions, but critical gaps in schema definition, error handling, and parameter validation. All 6 tools follow verb_noun naming (trim, jumpcut, caption, transcribe, overlay-text, edit), which is good. However, input parameters lack formal JSON Schema type definitions and many parameter descriptions are vague or missing format constraints. The tools do not expose secrets in parameters (good), but lack comprehensive error recovery guidance, input validation clarity, and output schema documentation. The orchestrator tool (edit) compounds complexity by handling 15+ parameters with interdependencies that are underdocumented.
Burn SRT captions into video with style options (hormozi, standard, minimal)
Main orchestrator for video editing operations that chains trim, jumpcut, speed, captions, and overlays in sequence
Auto-remove silence/dead air from video using ffmpeg silencedetect
Add text overlays at specific timestamps with position, font size, and optional background
Transcribe video/audio to SRT using OpenAI Whisper
Trim video by start/end timestamps
No formal JSON Schema type definitions visible for any tool parameters. Input schemas in the brief reference types (string, boolean) but lack proper JSON Schema structure with required/optional declarations, minLength/maxLength, pattern constraints, and enum constraints.
Parameter descriptions lack format constraints and validation rules. E.g., 'Start time in HH:MM:SS or seconds format (default: 00:00:00)' states the format but does not specify minimum/maximum values, regex pattern, or what happens if format is invalid. LLMs will guess-and-fail.
No documented output schemas. Each tool description mentions output paths but does not specify return object structure, fields, or types. LLMs cannot plan downstream operations without knowing what fields are returned.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 46 | 2026-07-28+ | v2 |
Error handling is minimal and non-instructive. Scripts use 'set -euo pipefail' and simple exit 1 on errors (e.g., 'Error: Input video not found'). No recovery guidance, no error categorization (retryable vs fatal), no suggestions for the agent to take next. An LLM cannot recover from 'Error: SRT file not found: ...', should suggest 'Call transcribe() first to generate SRT.'
The 'edit' orchestrator tool has 15+ interdependent parameters (trim_*, jumpcut_*, caption_*, overlay_*) with undocumented relationships. E.g., if caption=true and caption_srt is not set, the tool auto-transcribes, but this is not stated in the edit tool description or parameter docs. Conditional parameter validity is not documented.
No enums for constrained values. E.g., 'style' parameter in caption accepts 'hormozi, standard, minimal' but is documented as free-form string in the schema brief. No formal enum constraint visible. Same for caption_style in edit, overlay_position, and model choices in transcribe.
Parameter naming inconsistency and ambiguity. The 'output' parameter is used across all tools but is optional with a default based on input filename and suffix. LLMs may assume 'output' means a directory, a file path, or a format specifier. No clear guidance on what values are valid (absolute vs relative paths, file extensions, etc.).
No documentation of idempotency. Are these tools safe to retry? If trim fails partway and is called again with the same input, does it overwrite the partially-trimmed output or fail? Agents need to know which operations are idempotent and which have side effects.
Tool composition is monolithic rather than modular. The 'edit' tool attempts to handle trimming, silence removal, captioning, overlays, and speed adjustment in a single invocation. This violates the single-responsibility principle and makes it hard for agents to compose partial workflows (e.g., just trim without captioning) or to handle partial failures.
Parameter 'duration' in trim is ambiguous, it says 'Duration from start as alternative to --end' but does not clarify what happens if both duration AND end are provided, or if neither is provided (does it default to end of video?). Undocumented parameter relationships cause silent misuse.