Loading ToolBench
BeatScope MCP server: agents query Rhythm IR without reading source. Provides audio analysis, rhythm project management, visual state computation, and event querying for audio-reactive work.
BeatScope MCP demonstrates solid definition quality with well-structured tool schemas and comprehensive descriptions. All 6 tools have clear, detailed descriptions (avg 180+ chars) explaining WHAT they do and WHEN to use them. Input schemas are present and properly typed with JSON Schema. However, output schemas are not explicitly documented in the visible code, and some parameter descriptions lack constraint details (ranges, formats). Tool naming follows verb_noun convention consistently (list_, get_, analyze_, export_). Error handling guidance is minimal, descriptions state what tools do but not how to recover from failures. No tool annotations (readOnlyHint/destructiveHint) are visible despite clear risk classifications in the spec.
Analyze an audio file: measure BPM, beats, onsets, energy bands, bass notes, and structure. Returns a complete Rhythm IR schema v4 project. The file must be readable by the server (under an allowed root or in the cache). Paths are resolved relative to the server's working directory unless they are absolute and under an allowed root.
Export a project's rhythm facts as MIDI or CSV. The MIDI file carries beats, onsets, cues, and bass notes as note events; the CSV carries the same events as rows. Both use the project's BPM and grid origin. Subdivision controls the MIDI note grid (default 16 = sixteenth notes).
List BeatScope events in a time window (start, end]: beats, onsets (runtime boundary semantics), cues by type, pattern bars, whole-song segments, and structural boundaries - the measured facts the handoff carries, and nothing about a visual layer. Windows are capped at 600 s - split longer ranges into separate queries. Results are sorted by time and kind, then paginated. Set response_budget to select that many existing onsets by the optional response_relevance ordering value; timestamps never move, and the value is not probability or confidence.
Read one BeatScope project's measured facts. detail='summary' returns identity, counts, and compact per-segment mean low/mid/high energy when structure is available; 'timing' adds beats, tempo segments, patterns, and cues (no energy arrays); 'full' returns the complete schema v4 JSON unless it exceeds the response budget, in which case it points at the beatscope://projects/{id}/rhythm resource. Like the exported handoff, this view carries no visual layer: no compiled scene, transition, or recipe data is counted, named, or returned.
Output schemas not documented in visible code. Tool descriptions explain inputs but not return types, fields, or structure. LLMs cannot plan downstream calls without knowing what fields to extract.
Tool annotations (readOnlyHint, destructiveHint, idempotentHint) are absent despite clear risk classifications (READ_ONLY vs WRITE). beatscope_analyze_audio is marked WRITE but has no destructiveHint annotation.
Parameter constraints lack specificity. 'time' in beatscope_get_visual_state has no min/max bounds; 'response_budget' in beatscope_get_events has no range guidance. Unbounded numeric params invite absurd LLM values.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | <=2025-11-25 | v2 |
The measured facts at one audio instant, computed by the shared JavaScript runtime: bar, beat, beatIndex, beat/bar phases, low/mid/high/all energy, onset impulse, accent, section. The same call the web player makes and the same one the exported handoff exposes as getVisualState(time), so both carriers agree exactly; null onset age or accent means no previous onset exists. The name follows that package function - it is the state a visualizer samples, not a visual language. The response carries no scene, transition, or composition data.
List cached BeatScope rhythm projects with identity, BPM, bars, duration, backend, and provenance. Supports a display-name/id query, backend filter, and offset pagination.
Error handling guidance is absent. Descriptions do not explain what to do if audio analysis fails, if a project is not found, or if time bounds are invalid. No recovery hints for LLMs.
beatscope_analyze_audio accepts 'audio_path' as a string with no validation rules stated. Description mentions 'allowed root' and 'working directory' but does not specify path format, absolute vs relative semantics, or what happens if the file is unreadable.