Loading ToolBench
Analyze audio files and produce AI-readable summaries plus annotated visualizations of beats, drops, volume surges and tonal content.
Three tools with clear, domain-specific names (analyze_audio, describe_audio, visualize_audio) and detailed descriptions (194 - 250 chars each). All parameters have type definitions and descriptions. However, output schemas are not formally documented in the code, descriptions mention schema names ('beatlyzer.analysis/v1') but no JSON Schema is visible. Error handling is minimal (only AudioLoadError → ValueError conversion). No parameter constraints (enums, ranges) or validation guidance. Tool composition is sound (each does one thing), but missing pagination/limits guidance and structured output documentation.
Analyze an audio file and return a structured JSON summary. Accepts mp3, wav, flac, ogg, m4a and more (mp3/m4a need ffmpeg on PATH). The JSON (schema ``beatlyzer.analysis/v1``) contains: metadata (duration, tempo BPM, estimated key), loudness & dynamic range, brightness, an energy index, structural sections (intro/build/drop/outro...), a downsampled energy profile over time, and a timeline of events — beat drops, volume surges and high-tone peaks — each with a timestamp in seconds and a 0..1 strength. It also includes a prose ``summary_text`` and an ``ai_notes`` field describing every field's meaning.
Return a short natural-language description of an audio file. Covers tempo, estimated key, overall energy and tone, the structural arc, and where the beat drops / bright moments are. Use this for a quick human-readable overview; use ``analyze_audio`` for full structured data.
Render an annotated visualization of the audio and return it as an image. Produces four stacked panels sharing one time axis: (1) waveform with shaded structural sections, (2) loudness in dB with beat-drop and volume-surge markers, (3) brightness (spectral centroid) with high-tone markers, and (4) a mel spectrogram with drop lines. The PNG is also saved to disk (next to the input file, or to ``output_path`` if given).
Output schemas not formally documented. Descriptions reference 'beatlyzer.analysis/v1' schema but no JSON Schema definition is visible in code. LLMs cannot infer field structure, types, or downstream chaining requirements.
No parameter constraints or validation guidance. 'sample_rate' and 'dpi' accept unbounded integers with no min/max documented. LLMs may pass absurd values (sample_rate=1, dpi=10000) that break analysis or produce unusable output.
Minimal error handling. Only AudioLoadError is caught and converted to ValueError. No guidance on recovery (e.g., 'File not found, check path or try a different format'). LLMs receive bare exceptions with no actionable next steps.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | 2026-07-28+ | v2 |
No idempotency or dry-run support. visualize_audio writes to disk with no confirmation. If called twice with same input, it silently overwrites the PNG. Agents cannot safely retry without side effects.
describe_audio returns unstructured prose (summary_text field). No structured output schema. LLMs must parse natural language to extract tempo, key, energy, and structural info, error-prone and wastes tokens.