Loading ToolBench
FFmpeg-based Model Context Protocol server for video processing, music video generation, and media file operations with LLM-optimized command generation
This MCP server has significant definition quality gaps across nearly all dimensions. Of 17 tools, only a handful have adequate schema documentation, and many descriptions are either missing critical details or rely on vague marketing language rather than operational clarity. The server mixes tools from multiple frameworks (fastmcp, haiku-mcp-ts, Komposteur integration) with inconsistent quality. Several tools expose file paths as parameters despite claiming to use 'file IDs for secure file referencing', creating a contradiction. Parameter descriptions are often generic or missing type information. Error handling is not visible in the provided code. The naming convention is reasonable (verb_noun style), but schema completeness is poor across the board.
Create detailed analysis comparison between two videos with difference calculation and recommendations.
Create a music video by combining video and audio files using LLM-generated FFMPEG commands
Create side-by-side comparison of two videos with configurable layout, audio synchronization, and optional text labels.
Download audio from YouTube video using optimized yt-dlp commands
Download video from YouTube using optimized yt-dlp commands
Get detailed information about a file by its ID
Get current LLM usage statistics and cost estimates
Duplicate tool name: 'list_files' appears twice (once in haiku-mcp-ts/src/server.ts, once in integration/komposteur/). MCP spec requires unique tool names. One must be renamed (e.g. 'list_files_from_komposteur') or merged into a single implementation.
File ID abstraction violated: komposteur_process_kompost and uber_kompost_process_json accept file PATHS as parameters, contradicting the server's claim to use 'file IDs for secure file referencing'. LLMs will pass unsanitized paths, risking directory traversal attacks.
Missing output schemas: 17 tools lack documented return types. LLMs cannot plan downstream tool calls or extract relevant data. Examples: komposteur_beat_sync (what is returned? file ID? path? metadata?), create_analysis_comparison (what fields in the comparison?), get_llm_stats (what statistics exactly?).
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 43 | - | v1 |
Get current registry status and statistics
Beat-synchronize video using Komposteur's production-proven algorithm. Uses the 120 BPM = 8s per 16 beats formula for precise synchronization. Handles video/audio alignment with microsecond precision.
Calculate precise duration for beat-based video timing using Komposteur's production formula: 120 BPM = 8s per 16 beats for consistent timing calculations across the system.
Extract video segment with microsecond-precise timing using Komposteur's frame-perfect extraction algorithms for precise segment boundaries without frame loss.
Process a kompost.json file using Komposteur's curated FFMPEG workflows. This is the primary integration point for processing kompost.json files containing curated FFMPEG effects and beat-synchronized video workflows.
Comprehensive media validation using Komposteur's pipeline. Performs deep analysis of media files including format validation, quality assessment, and compatibility checks.
🎬 CORE WORKFLOW - List available source files with smart suggestions and quick actions. This is the ONLY way to discover available files. Returns file IDs (not paths) for secure file referencing.
List all files in the registry with their IDs and metadata
Process a video file with specified operation using LLM-optimized FFMPEG commands
Process kompost.json using uber-kompost JAR with JSON API. This is the primary tool for the uber-kompost integration that processes kompost.json files and creates actual video output using the Java library.
'operation' parameter in process_video_file is a free-form string with examples ('resize', 'trim', 'convert', 'extract_audio') in the description rather than an enum constraint. LLMs will hallucinate unsupported operations. No validation of sub-parameters in 'parameters' object.
Parameter validation rules missing across all tools. Examples: komposteur_beat_sync has no min/max for BPM (is 0.5 BPM valid?), komposteur_extract_segment has no constraint that end_time > start_time, download_youtube_audio/video lack format enums. LLMs will pass invalid values and tools will fail with unhelpful errors.
Marketing language in descriptions instead of operational clarity. Examples: 'microsecond precision' (komposteur_beat_sync), 'production-proven algorithm', 'frame-perfect extraction'. These convey nothing actionable to LLMs about when to use the tool or what it returns. Descriptions should state WHAT the tool does, WHEN to use it, and WHAT it returns.
Two nearly identical tools (komposteur_process_kompost vs uber_kompost_process_json) with no documented distinction. LLMs will guess which to call, risking wrong choice. Description must explain: What is the difference? When should I use one vs the other? Do they produce different outputs?
Examples in parameter descriptions (e.g., file_id example 'file_14af0abf' in get_file_info) are anti-patterns. LLMs tend to reuse example values literally, causing tool calls with placeholder IDs. Use enums and regex patterns instead.
Generic tool names: 'process' (in process_video_file) is too vague. Specific names like 'resize_video', 'trim_video', 'extract_audio' help LLMs disambiguate. Current name invites the LLM to guess what operation to pass.
No error handling or recovery guidance visible in tool definitions. E.g., download_youtube_audio has no description of what happens if the URL is invalid, the video is not accessible, or max_duration is exceeded. LLMs need 'If you get an error, try...' guidance.