Loading ToolBench
The server defines 5 tools with complete input schemas and descriptions. Naming follows verb_noun convention and is action-oriented. Descriptions are moderately detailed (120-180 chars typical) and explain what each tool does. However, there are notable gaps: output schemas are completely undocumented, parameter descriptions lack constraint details (e.g., no regex patterns or explicit format guidance for filenames), and error handling is minimal. The tool 'check_processing_status' and 'get_files_info' have empty input schemas but still declare them explicitly. File paths are exposed directly without sanitization guidance, and destructive operations (speed_up_video, increase_keyframes, concatenate_videos) lack confirmation patterns or dry-run support. The server tracks background jobs but does not communicate this capability in tool descriptions or error recovery guidance.
Check the status of background video processing operations.
Concatenate multiple video files into one output video. Creates temporary text file, processes videos, and cleans up automatically.
Get a list of all files in the configured video folder with their names and modification dates.
Increase the number of keyframes in a video by setting GOP (Group of Pictures) value. Lower GOP = more keyframes.
Speed up a video by a given factor (e.g., 50 = 50x faster). For large files, processing starts in background.
Output schemas completely undocumented. Tool definitions declare inputSchema but never document what each tool returns. LLMs cannot plan downstream calls or extract required fields (e.g., job_id from speed_up_video, status from check_processing_status, file list from get_files_info). This violates the requirement that 100% of A-tier tools document return types.
Parameter 'filename' lacks format/validation guidance. Description says 'Name of the video file (e.g., "GX010412.MP4")' but does not specify: allowed extensions, max length, path traversal prevention, or character restrictions. LLMs may pass invalid filenames or attempt path traversal (../../../etc/passwd). Descriptions should state constraints explicitly per pattern:constrained-input.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 54 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Destructive operations lack confirmation or dry-run support. speed_up_video, increase_keyframes, and concatenate_videos all modify or create files, but there is no mechanism for the LLM to preview changes or request confirmation. Pattern:confirmation-request recommends supporting dry-run or explicit confirmation for irreversible operations.
Error handling provides no recovery guidance. In server.js, catch blocks throw generic McpError with only the error message. A tool throwing 'Input file not found: /path/to/file.mp4' gives the agent no actionable next step. Per pattern:recovery-guide, errors should suggest alternatives ('File not found. Use get_files_info() to see available videos.') and classify whether the error is retryable.
check_processing_status and get_files_info have empty required arrays but no documentation of what they return. A tool with zero required parameters should prominently explain what data it discovers. Currently 'Check the status of background video processing operations.' provides no hint about the structure or fields the LLM will receive.
No pagination or result limits declared. get_files_info lists 'all files in the configured video folder' with no mention of pagination, limits, or result caps. Per pattern:paginated-result and baseline mxe:enforce-result-limits, tools returning lists should declare max result size and pagination support. A folder with thousands of files could exhaust context.
No explicit audit trail or logging declarations. Tools perform file I/O and video processing but provide no mechanism to log who called what or when. Pattern:audit-trail requires agent-initiated actions to be traceable. The server logs to stderr but does not communicate security posture or audit capability to clients.