Loading ToolBench
Local-first MCP server and CLI that turns a YouTube link or a local audio file into a structured sonic signature: BPM, section-by-section key, production profile, and a 512-dim CLAP vibe embedding
Four tools with basic descriptions and no visible input schemas in source. Tool names follow verb_noun pattern (get_*, list_, check_) which is good. Descriptions exist but are brief (20-100 chars) and lack LLM-optimized detail about WHEN to use each tool, prerequisites, or error recovery. No parameter descriptions visible in source code, only parameter names and types inferred from docstrings. No output schemas documented. No error handling guidance. The async job pattern (submit → poll) is sound but not explained to LLMs. Missing idempotency hints, retry guidance, and field-level documentation.
Performs system health check verifying environment dependencies (FFmpeg, libraries).
Returns the current status and payload of a previously submitted job.
Submits a YouTube URL for sonic analysis and returns immediately. The pipeline runs in the background — poll get_job_status(job_id) for results. Typical processing: 20-30s on GPU, ~6-8 min on CPU (Demucs separation dominates).
Lists all in-progress and completed jobs with their current status.
No input schemas visible in source code. Tool definitions show parameter names and types only in docstrings, not in explicit JSON Schema registration. Cannot verify schema completeness, type constraints, or enum values.
Descriptions lack LLM-optimized context. 'Returns the current status and payload of a previously submitted job' (45 chars) does not explain WHEN to call this vs other tools, what 'payload' contains, or how to interpret status values. Baseline: 194 chars average for A+ tools.
No output schema documentation. LLMs cannot plan downstream calls or extract fields without knowing what get_sonic_signature returns. Baseline: 100% of A+ tools document return types.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 42 | <=2025-11-25 | v2 |
Async job pattern not explained to LLMs. get_sonic_signature description mentions '20-30s on GPU, ~6-8 min on CPU' but does not explicitly state 'This tool returns immediately; poll get_job_status(job_id) to retrieve results.' Agents may not understand the polling requirement.
No error handling guidance. If a YouTube URL is invalid, a job fails, or health check detects missing FFmpeg, the tool descriptions do not tell LLMs what to do next or how to recover.