Loading ToolBench
Ableton Live integration through the Model Context Protocol
The Ableton MCP server has 28 tools with basic structure, but significant gaps in schema completeness and parameter documentation. Tools have simple descriptions (50-150 chars typical), but most lack detailed input parameter schemas, many parameters visible in the tool list have no type information visible in the source code provided. The server uses fastmcp framework (Python), which should generate schemas, but the actual schema definitions are not visible in the provided code excerpt (only the server.py code is partially shown, ending mid-function). Naming is verb-forward (get_, set_, create_, delete_, fire_, stop_) which is good. Descriptions exist but are generic and do not explain WHEN to use the tool or what it returns. Error handling and output schemas are not visible in the code. The destructive vs write vs read-only risk classification is helpful but not reflected in tool descriptions. Without seeing the complete schema definitions, per-tool scores must be conservative.
Add MIDI notes to a clip
Remove all notes from a clip
Create a new audio clip from a file
Create a new audio track in the session
Create a new MIDI clip in a track
Create a locator/marker in the arrangement view
Create a new MIDI track in the session
Output schemas not documented. Tools like get_session_info, get_session_snapshot, get_arrangement_clips do not specify what fields they return, forcing LLMs to guess at response structure and cannot plan downstream tool calls.
Parameter descriptions are generic or missing context. For example, add_notes_to_clip accepts 'notes' as an array but does not document the required fields (pitch, start_time, duration, velocity) or their valid ranges. LLMs cannot validate input without this.
No error handling or recovery guidance. The code shows socket timeouts and connection errors, but no tool-level error messages, error classifications (retryable vs user-fixable), or actionable next steps for LLM recovery.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 61 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Delete a clip from a track
Retrieve passive Live UI events that have occurred since last drain
Copy a clip from session view to arrangement view
Trigger playback of a clip
Get information about clips in the arrangement view
Retrieve the notes contained in a specific clip
Get the parameters of a device on a track
Retrieve metadata about the Ableton Remote Script including version and capabilities
Retrieve information about the current Ableton Live session including tracks, clips, and session state
Capture a complete snapshot of the current session state
Get detailed information about a specific track in the session
Load an instrument or effect plugin onto a track
Rename a clip in the session
Set the playhead position in the arrangement
Set the value of a parameter on a device
Set the tempo (BPM) of the song
Rename a track in the session
Start playback of the song
Stop playback of a clip
Stop playback of the song
Switch the view to arrangement mode
Destructive operations (delete_clip, clear_notes_from_clip) lack confirmation or dry-run support. Agents can delete clips without a safety checkpoint, risking data loss.
Ambiguous parameter naming. 'device_index' in get_device_parameters and load_instrument_or_effect is unclear: is it zero-based? does it mean 'position in the chain'? Tool descriptions do not clarify.
Many tools (start_playback, stop_playback, switch_to_arrangement_view, get_script_info) have very short descriptions (50 chars or less) that do not explain WHEN to use them or what they return. This violates the 10 - 1024 character baseline and requires LLMs to infer context.
Parameter range and enum constraints not documented. For example, set_tempo accepts a 'bpm' parameter with no stated minimum, maximum, or what happens if BPM is 0 or 9999. get_track_info and get_clip_notes require 'track_index' and 'clip_index' with no stated bounds.
Tool chaining broken: create_midi_track returns a track but no visible track_id or reference. Subsequent tools (get_track_info, set_track_name) require track_index, but it is unclear if the index returned by create_midi_track matches what get_track_info expects.
drain_passive_events has an unclear purpose. Description says 'Retrieve passive Live UI events that have occurred since last drain' but does not explain what 'passive events' are, what fields they contain, or why an LLM would call this over polling. Very low naming clarity (verb 'drain' is not standard agent terminology).
Missing pagination support. Tools like get_session_info and get_arrangement_clips could return large numbers of tracks or clips, but no limit, offset, or page parameters are visible, risking context window exhaustion.