The AbletonMCP server enables AI models to directly control and interact with Ableton Live for music production, acting as a bridge between AI prompts and Live's functionality.
Session Management: Retrieve session info, set tempo, start/stop global playback.
Track Control: Create MIDI tracks, rename tracks, and get detailed track info.
Clip Control: Create MIDI clips, add notes (pitch, start time, duration, velocity, mute state), rename, fire, and stop clips.
Instrument & Effects Loading: Load instruments, audio/MIDI effects, drum racks, and drum kits onto tracks using their browser URIs.
Browser Access: Explore Ableton's content browser by retrieving category trees (instruments, sounds, drums, effects) and navigating to specific paths.
Full Arrangement: Combine all of the above to build complete songs with structured sections (intro, buildup, drop, etc.).
Provides a community platform for users to give feedback, get inspired, and build on top of the MCP integration
Enables communication with Ableton Live through MIDI Remote Scripts for track manipulation, instrument and effect selection, clip creation, and session control
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@AbletonMCP add a synth pad to track 3 and set it to play chords"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Connect Ableton Live to Claude AI
Prompt-assisted music production, end-to-end track creation, and Live session and arrangement manipulation — driven by AI.
Setup Video · Discord · Issues
Three steps: install uv, point your MCP client at the server, install the Ableton Remote Script.
1. Install uv
# macOS
brew install uvOtherwise, install from uv's official website.
Warning: Do not proceed before installing uv.
2. Add the MCP server to your client
{
"mcpServers": {
"AbletonMCP": {
"command": "uvx",
"args": [
"ableton-mcp"
]
}
}
}Paste this as a command:
uvx ableton-mcpWarning: Only run one instance of the MCP server (either on Cursor or Claude Desktop), not both.
3. Install the Ableton Remote Script
uvx --from ableton-mcp ableton-mcp-install-script
uvx --from ableton-mcp ableton-mcp-install-script --list-targets # preview target folders first4. Connect
Launch Ableton Live
Go to Settings/Preferences → Link, Tempo & MIDI
In the Control Surface dropdown, select AbletonMCP
Set Input and Output to None
That's it — ask Claude to build something.
Related MCP server: AbletonMCP
Two-way communication | Connect Claude AI to Ableton Live through a socket-based server |
Track manipulation | Create, modify, and manipulate MIDI and audio tracks |
Instrument and effect selection | Claude can access and load the right instruments, effects and sounds from Ableton's library |
Clip creation | Create and edit MIDI clips with notes |
Arrangement view composition | Build full songs autonomously in Arrangement View, including sections like intro, buildup, drop, breakdown, and outro |
Session control | Start and stop playback, fire clips, and control transport across Session View and Arrangement View |
Anonymous telemetry | Usage tracking to help improve the tool (can be disabled) |
The system consists of two main components:
Ableton Remote Script (Ableton_Remote_Script/__init__.py) — a MIDI Remote Script for Ableton Live that creates a socket server to receive and execute commands
MCP Server (server.py) — a Python server that implements the Model Context Protocol and connects to the Ableton Remote Script
Ableton Live 10 or newer
Python 3.8 or newer
uv package manager
If you're on Mac, please install uv as:
brew install uvOtherwise, install from uv's official website
Warning: Do not proceed before installing uv.
Follow along with the setup instructions video
Go to Claude → Settings → Developer → Edit Config → claude_desktop_config.json to include the following:
{
"mcpServers": {
"AbletonMCP": {
"command": "uvx",
"args": [
"ableton-mcp"
]
}
}
}Run ableton-mcp without installing it permanently through uvx. Go to Cursor Settings → MCP and paste this as a command:
uvx ableton-mcpWarning: Only run one instance of the MCP server (either on Cursor or Claude Desktop), not both.
In the terminal, run:
claude mcp add AbletonMCP uvx ableton-mcpFollow along with the setup instructions video
Install the Remote Script with:
uvx --from ableton-mcp ableton-mcp-install-script
uvx --from ableton-mcp ableton-mcp-install-script --list-targets # preview target folders firstIf you installed the package with
piporpipx, the command is on your PATH directly — just runableton-mcp-install-script.
This copies the matching Remote Script into your Ableton User Library's Remote Scripts folder — the location Live (10.1.13+) scans for third-party control surface scripts. The installer reads the User Library location from Live's Library.cfg, falling back to the default (~/Music/Ableton/User Library on macOS, Documents\Ableton\User Library on Windows). If a different version of the script is already there, the existing file is backed up to __init__.py.bak before being replaced.
If your User Library lives somewhere non-standard and isn't detected, point the installer at it directly:
uvx --from ableton-mcp ableton-mcp-install-script --target "/path/to/User Library/Remote Scripts"The legacy
Preferences/User Remote Scriptsfolder (used for instant-mapping configs, not Python control surfaces) is no longer targeted by default; pass--legacyif you need it for an old Live version.
Then restart Ableton (or re-select the AbletonMCP control surface) so Live loads it. Re-run the command after upgrading the package — the server logs a warning when the loaded script version doesn't match what it expects.
Note: The server does not install the script on startup. Writing into Ableton's preferences directory is an explicit action, not a side effect of launching a server.
First-time Ableton setup:
Run uvx --from ableton-mcp ableton-mcp-install-script
Launch Ableton Live
Go to Settings/Preferences → Link, Tempo & MIDI
In the Control Surface dropdown, select AbletonMCP
Set Input and Output to None
macOS: ~/Music/Ableton/User Library/Remote Scripts/AbletonMCP/
Windows: C:\Users\[Username]\Documents\Ableton\User Library\Remote Scripts\AbletonMCP\
If you've moved your User Library, use its actual location (shown in Live under Preferences → Library → Location of User Library), and create the Remote Scripts folder inside it if it doesn't exist yet.
The MCP server and Remote Script share a version handshake (get_remote_script_info). If they diverge, newer tools degrade gracefully until Live is restarted.
Ensure the Ableton Remote Script is loaded in Ableton Live
Make sure the MCP server is configured in Claude Desktop or Cursor
The connection should be established automatically when you interact with Claude
Once the config file has been set on Claude, and the remote script is running in Ableton, you will see a hammer icon with tools for the Ableton MCP.
Get session and track information
Create and modify MIDI and audio tracks
Create full song arrangements from start to finish in Arrangement View
Create, edit, and trigger clips
Control playback
Load instruments and effects from Ableton's browser
Add notes to MIDI clips
Change tempo and other session parameters
Here are some examples of what you can ask Claude to do:
Prompt | Demo |
"Create an 80s synthwave track" | |
"Create a Metro Boomin style hip-hop beat" | |
"Create a full arrangement with an intro, buildup, drop, breakdown, and outro" | |
"Create a new MIDI track with a synth bass instrument" | |
"Add reverb to my drums" | |
"Create a 4-bar MIDI clip with a simple melody" | |
"Get information about the current Ableton session" | |
"Load a 808 drum rack into the selected track" | |
"Add a jazz chord progression to the clip in track 1" | |
"Set the tempo to 120 BPM" | |
"Play the clip in track 2" |
Problem | Fix |
Connection issues | Make sure the Ableton Remote Script is loaded, and the MCP server is configured on Claude |
Timeout errors | Try simplifying your requests or breaking them into smaller steps |
Have you tried turning it off and on again? | If you're still having connection errors, try restarting both Claude and Ableton Live |
The system uses a simple JSON-based protocol over TCP sockets:
Commands are sent as JSON objects with a type and optional params
Responses are JSON objects with a status and result or message
Creating complex musical arrangements might need to be broken down into smaller steps
The tool is designed to work with Ableton's default devices and browser items
Always save your work before extensive experimentation
AbletonMCP collects usage data to help improve the tool. This includes:
Anonymous tool usage statistics (which features are used)
Anonymous session start information (for daily/monthly active user counts)
Anonymous rates and performance metrics
Prompts, MIDI notes, track and clip names, and device settings
Telemetry is on by default. To see exactly what data is collected, see the Terms & Data Use.
To disable telemetry, set one of these environment variables before starting the MCP server:
export ABLETON_MCP_DISABLE_TELEMETRY=trueOr use any of these alternatives:
DISABLE_TELEMETRY=true
MCP_DISABLE_TELEMETRY=true
For Claude Desktop, add the environment variable to your config:
{
"mcpServers": {
"AbletonMCP": {
"command": "uvx",
"args": ["ableton-mcp"],
"env": {
"ABLETON_MCP_DISABLE_TELEMETRY": "true"
}
}
}
}Give feedback, get inspired, and build on top of the MCP: Discord
Contributions are welcome! Please feel free to submit a Pull Request.
This is a third-party integration and not made by Ableton. Made by Siddharth.
If Ableton MCP is useful to you, consider starring the repo
Add MIDI notes to a clip.
Parameters:
track_index: The index of the track containing the clip
clip_index: The index of the clip slot containing the clip
notes: List of note dictionaries, each with pitch, start_time, duration, velocity, and mute
| Name | Required | Description | Default |
|---|---|---|---|
| track_index | Yes | ||
| clip_index | Yes | ||
| notes | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states what the tool does without explaining side effects, whether notes are appended or replace existing ones, whether the clip is modified in place, or any error conditions. This leaves significant ambiguity for an agent invoking the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded. It opens with a one-sentence purpose, then lists parameters with short explanations. Every sentence adds value and there is no redundancy or wasted words. This is an efficient structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is incomplete. It does not explain what happens after notes are added (e.g., return value, visual undo), any limitations (e.g., only applies to MIDI clips), or how the notes array is processed (append vs replace). Given the complexity of a MIDI editing tool, more behavioral context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It does so by explaining each parameter: track_index and clip_index refer to the containing track and clip slot, and notes are described as a list of dictionaries with pitch, start_time, duration, velocity, and mute. This adds meaning beyond the schema, which only provides types. However, it lacks units or value ranges, which would further improve clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Add MIDI notes to a clip.' This is a specific verb+resource pair that distinguishes it from siblings like create_clip (creating a clip) or fire_clip (triggering playback). It is unambiguous and immediately understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as create_clip or fire_clip. It does not state prerequisites (e.g., the target clip must exist and be a MIDI clip) or situations where it should be avoided. The usage context is only implied by the tool's name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new MIDI clip in the specified track and clip slot.
Parameters:
track_index: The index of the track to create the clip in
clip_index: The index of the clip slot to create the clip in
length: The length of the clip in beats (default: 4.0)
| Name | Required | Description | Default |
|---|---|---|---|
| track_index | Yes | ||
| clip_index | Yes | ||
| length | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavior. It only states the basic creation action and parameters, but does not address side effects (e.g., whether an existing clip in the slot is overwritten), required permissions, undo behavior, or any other behavioral traits. The description adds no context beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: one sentence defining the purpose followed by a short, well-organized parameter list. Every line contributes useful information, with no redundancy or filler. The key action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple creation tool with no output schema and no annotations, the description covers the what and how, including the default for length. However, it omits context such as whether the clip is empty, whether it overwrites an existing clip in the slot, or any track prerequisites. Minor gaps, but overall adequate for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only types and defaults (0% schema_description_coverage). The description compensates by clearly explaining each parameter: track_index is the track index, clip_index is the slot index, and length is in beats with a default value. This adds meaningful semantics beyond the schema's bare properties, though it could be even more detailed (e.g., valid ranges).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create'), the resource ('a new MIDI clip'), and the target ('in the specified track and clip slot'). This verb+resource+location phrasing is specific and distinguishes it from sibling tools like fire_clip or stop_clip.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage ('when you want to create a new clip') but does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. No sibling differentiation or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new MIDI track in the Ableton session.
Parameters:
index: The index to insert the track at (-1 = end of list)
| Name | Required | Description | Default |
|---|---|---|---|
| index | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'create a new MIDI track' without explaining side effects, undo behavior, permissions, or what happens to existing tracks. This is a significant lack of transparency for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the main purpose, and includes a clear parameter explanation. Every sentence earns its place; there is no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only one parameter, and the description covers its purpose and parameter semantics. However, it lacks usage guidelines and behavioral context (e.g., what happens on creation), so it is not fully complete for an agent operating autonomously.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a title and default for the 'index' parameter with no description, so the description's explanation ('The index to insert the track at (-1 = end of list)') adds crucial semantic meaning. This fully compensates for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a clear verb+resource combination: 'Create a new MIDI track in the Ableton session.' It unambiguously states the tool's function and is distinct from sibling tools like create_clip, which creates clips rather than tracks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives, nor any exclusions. While it is implicit that this is for creating MIDI tracks, the description does not mention prerequisites, typical scenarios, or contrast with related tools like create_clip.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start playing a clip.
Parameters:
track_index: The index of the track containing the clip
clip_index: The index of the clip slot containing the clip
| Name | Required | Description | Default |
|---|---|---|---|
| track_index | Yes | ||
| clip_index | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only states the action without contextual details such as whether it stops other clips, requires a running transport, or what happens on invalid indices. This is minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded with the purpose, followed by a clear parameter list. Every sentence earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool, the description covers the basics: what it does and what the indices mean. However, it lacks any mention of side effects, error conditions, or how it interacts with overall playback state. Given no output schema, some extra context would be warranted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameters are explained in the description ('The index of the track containing the clip' and 'The index of the clip slot containing the clip'), adding significant meaning beyond the schema's bare integer definitions. Both required parameters are covered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Start playing a clip.' This is a specific verb+resource combination that distinguishes it from siblings like stop_clip (which stops a clip) and start_playback (which likely starts general transport).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. It does not mention conditions, prerequisites, or exclusions relative to siblings. The status quo is clear but unstated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get browser items at a specific path in Ableton's browser.
Parameters:
path: Path in the format "category/folder/subfolder" where category is one of the available browser categories in Ableton
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'gets' items, implying read-only, but does not describe potential error behavior, return format, or any side effects. Given the lack of annotations, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: one clear sentence plus a short parameter explanation. Every word earns its place, and the front-loaded purpose makes it immediately clear what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with one parameter and no output schema, the description is mostly adequate. It explains the path format, which is the key input. However, it lacks information about return structure, error handling, and how it relates to sibling tools, leaving some context missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines `path` as a string with no description. The description compensates by specifying the required format 'category/folder/subfolder' and clarifying that `category` must be one of Ableton's browser categories. This adds meaningful meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get browser items at a specific path in Ableton's browser.' The verb 'Get' is specific, the resource is the browser, and the scope is a specific path. This distinguishes it from the sibling tool `get_browser_tree`, which retrieves the entire tree.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit usage guidance is provided. The description does not say when to use this tool versus alternatives like `get_browser_tree`, nor does it mention any prerequisites or edge cases. The path format is explained, but the 'when' is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a hierarchical tree of browser categories from Ableton.
Parameters:
category_type: Type of categories to get ('all', 'instruments', 'sounds', 'drums', 'audio_effects', 'midi_effects')
| Name | Required | Description | Default |
|---|---|---|---|
| category_type | No | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description only states what it returns (a hierarchical tree) but does not disclose whether it is read-only, any permissions needed, or how the tree is structured. It adds no behavioral details beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the purpose, and includes a clean parameter listing. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter getter, the description covers the purpose and parameter values. It does not mention the default 'all' or what the tree nodes look like, but given the simplicity, it is mostly complete. However, it could state that it is a read-only operation or return format, which would help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explicitly lists the category_type parameter, explains its meaning ('Type of categories to get'), and enumerates allowed values ('all', 'instruments', etc.). This significantly adds to the schema, which only has the property name and default with no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets a hierarchical tree of browser categories from Ableton, using specific verb 'get' and resource. It does not explicitly contrast with the sibling get_browser_items_at_path, but the 'hierarchical tree' phrasing implies a structural overview.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool over alternatives, such as get_browser_items_at_path, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about the current Ableton session
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description alone must disclose behavioral traits. It only restates the tool's name with slightly more words and does not mention that the operation is read-only, what information is returned, or any potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the primary verb and resource. It contains no redundant phrasing or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's simplicity (no parameters, no output schema), the description fails to specify what 'detailed information' includes or how it relates to other getter tools. The agent is left without a clear picture of the return value or the scope of 'session info'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, which gives a baseline score of 4. The description neither contradicts the schema nor needs to explain parameter meanings since there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'get' and identifies the resource as 'detailed information about the current Ableton session', clearly distinguishing it from sibling tools like set_tempo or fire_clip. It is unambiguous about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as get_track_info or get_mixer. There is no mention of appropriate contexts, exclusions, or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific track in Ableton.
Parameters:
track_index: The index of the track to get information about
| Name | Required | Description | Default |
|---|---|---|---|
| track_index | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full behavioral burden. It only says 'Get detailed information' without disclosing whether the operation is read-only, what side effects might occur, or how errors like an invalid track_index are handled. This is a significant gap for a data-retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the primary purpose. The parameter explanation is somewhat redundant with the parameter name, but it does not add unnecessary length, making it appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description needs to explain what 'detailed information' includes. It does not mention the return structure, possible fields, or any behavior, leaving the agent to guess. Even for a simple getter, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains track_index as 'the index of the track', which adds a basic role but not critical details such as range, base (0 or 1), or ordering. Since schema description coverage is 0%, the description is the only source of parameter meaning but fails to provide enough context for confident usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and names the resource 'a specific track in Ableton', which clearly differentiates from siblings like get_mixer or get_session_info. However, 'detailed information' is vague about what exactly is included, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_mixer or get_session_info. There is also no mention of track indexing conventions (e.g., zero-based vs one-based) or prerequisites, leaving the agent without explicit usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load a drum rack and then load a specific drum kit into it.
Parameters:
track_index: The index of the track to load on
rack_uri: The URI of the drum rack to load (e.g., 'Drums/Drum Rack')
kit_path: Path to the drum kit inside the browser (e.g., 'drums/acoustic/kit1')
| Name | Required | Description | Default |
|---|---|---|---|
| track_index | Yes | ||
| rack_uri | Yes | ||
| kit_path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose side effects and behavior. It states a two-step process (load rack then kit) but does not describe what happens if the track already contains a rack, whether the operation is destructive, or what errors may occur. The lack of output schema also leaves return behavior unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct: one sentence for the action and three bullet-like parameter explanations with examples. No redundant information is present, and the structure is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core action and parameter meanings, but it lacks contextual details such as when to use the tool and behavioral side effects. It is adequate for a simple loading operation but incomplete for robust agent decision-making, especially with no annotations or output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description compensates for the 0% schema coverage by documenting each parameter: track_index, rack_uri (with example 'Drums/Drum Rack'), and kit_path (with example 'drums/acoustic/kit1'). This provides meaningful context beyond the bare schema, though it could further clarify indexing and path conventions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action: 'Load a drum rack and then load a specific drum kit into it.' This distinguishes it from the sibling tool 'load_instrument_or_effect' by focusing on drum kits. However, it does not explicitly contrast it with that sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not specify when to use this tool versus 'load_instrument_or_effect' or other loading tools, nor does it mention prerequisites like existing tracks or whether it replaces existing racks. This leaves the agent without clear selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load an instrument or effect onto a track using its URI.
Parameters:
track_index: The index of the track to load the instrument on
uri: The URI of the instrument or effect to load (e.g., 'query:Synths#Instrument%20Rack:Bass:FileId_5116')
| Name | Required | Description | Default |
|---|---|---|---|
| track_index | Yes | ||
| uri | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only states the action without any details on side effects (e.g., whether the load replaces existing devices), prerequisites (e.g., track must exist, URI valid), or failure modes. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise: one sentence stating the purpose, followed by a clear parameter list. No filler or redundancy. The structure front-loads the main action and then details the inputs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is incomplete for safe and correct invocation. It lacks information about return values, error conditions, what happens to existing track content, and whether any prerequisites exist. Given the absence of annotations and output schema, the tool description should be more thorough. It is minimally adequate for a simple load operation but leaves many operational questions unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the schema by explaining the purpose of each parameter. The track_index is described as 'the index of the track to load the instrument on', and uri is described with an example 'query:Synths#Instrument%20Rack:Bass:FileId_5116', which helps clarify the expected input format. Schema descriptions are 0%, so this compensates well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: 'Load an instrument or effect onto a track'. It distinguishes from most siblings (playback, tempo, mixer tools), though it doesn't explicitly differentiate from the very similar 'load_drum_kit'. The resource is specific enough for basic identification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like load_drum_kit or other track-modification tools. The usage scenario is implied by the name and description, but there are no explicit when/when-not conditions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the name of a clip.
Parameters:
track_index: The index of the track containing the clip
clip_index: The index of the clip slot containing the clip
name: The new name for the clip
| Name | Required | Description | Default |
|---|---|---|---|
| track_index | Yes | ||
| clip_index | Yes | ||
| name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavior. It only states the action 'set name' without mentioning side effects, whether the operation overwrites the existing name, potential errors, or any safety considerations. This is minimal and could mislead an agent about reversibility or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a one-line purpose followed by a bullet list of parameters. Every sentence is necessary and information-dense. It front-loads the core action and then lists parameters, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter mutation tool with no annotations and no output schema, the description is under-specified. It does not disclose expected return behavior, failure conditions, or whether the clip must exist. The description is adequate only for the most basic understanding but lacks critical context for safe operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only titles with 0% description coverage, so the description must add meaning. It does give brief explanations for each parameter (e.g., 'track_index: The index of the track containing the clip'), which clarifies their role. However, it does not go beyond obvious semantics and lacks constraints like valid ranges or format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Set the name of a clip' which is a specific verb + resource. It distinguishes from sibling tools like set_track_name by explicitly targeting clips, and from fire_clip/stop_clip by the action being a rename.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not mention that set_track_name should be used for tracks, nor does it provide any context about prerequisites or exclusions. The usage is only implied by the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the tempo of the Ableton session.
Parameters:
tempo: The new tempo in BPM
| Name | Required | Description | Default |
|---|---|---|---|
| tempo | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'Set the tempo' without mentioning side effects, constraints (e.g., Ableton tempo range), or whether changes apply immediately to live playback. This leaves significant behavioral ambiguity for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of one sentence plus a parameter listing. Every word earns its place, with no redundant information. This is a model of minimalism.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with a single parameter, the description covers the core meaning and parameter, but it lacks behavioral context such as side effects, error conditions, or return behavior. The absence of annotations and output schema means the description alone is not fully complete, though it is serviceable for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description supplies the crucial semantic that the tempo is 'in BPM', which is absent from the schema (which only provides type and title). This adds real value beyond the structured data. However, it does not specify allowed ranges or default values, which would be even more helpful, but for a single parameter this is adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Set the tempo of the Ableton session', which is a specific verb + resource. It clearly distinguishes from sibling tools (e.g., set_track_volume, start_playback) as none of them handle tempo manipulation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternative guidance is provided. The usage context is implied by the tool name and description, but the description does not state any exclusions or mention when to prefer this tool over others. Since no tempo-related sibling exists, the ambiguity is low, but clear guidance is still missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the name of a track.
Parameters:
track_index: The index of the track to rename
name: The new name for the track
| Name | Required | Description | Default |
|---|---|---|---|
| track_index | Yes | ||
| name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states the basic operation and lists parameters. There is no disclosure of side effects, error handling, index base (0-based vs 1-based), or return behavior. Since no annotations exist, the description carries this burden but fails to address it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with one sentence and two parameter bullets. Every word serves a purpose, and it is front-loaded with the core action. No extraneous information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with no annotations and no output schema, the description is minimal. It omits critical context such as whether the track index is zero-based, what happens on invalid input, and whether the change is immediately reflected. The agent may need to guess these details, making the description incomplete for safe usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to both parameters by specifying that track_index is 'the index of the track to rename' and name is 'the new name for the track'. This compensates for the schema's lack of property descriptions, but it does not clarify constraints like valid index ranges or name formatting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Set the name') on a specific resource ('a track'), which distinguishes it from sibling tools like set_track_volume or set_clip_name. However, it lacks additional context or scope, making it clear but not exceptionally helpful.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It simply describes the action without any exclusions, prerequisites, or contextual advice for an AI agent deciding between related setter tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start playing the Ableton session.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior, but it only states the action. It does not mention side effects (e.g., whether it resumes from current position), preconditions (e.g., an open session), or behavior if already playing. This is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that is immediately informative. Every word earns its place, and it is front-loaded with the action and target. No redundant or extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple transport control, the description gives the core function, but it lacks context about session state or how it differs from 'fire_clip'. Since there are no annotations and no output schema, the description should provide more behavioral context to be fully sufficient, yet the tool's simplicity keeps it from being inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is nothing to explain. According to rubric, a 0-parameter tool gets a baseline of 4. The description adds no parameter-specific information, but it doesn't need to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Start') and a clear resource ('Ableton session'), making the tool's function unambiguous. It naturally distinguishes itself from siblings like 'stop_playback' and 'fire_clip' by referring to the session-level transport.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool instead of related tools such as 'fire_clip' or 'stop_playback'. The expected context is implied by the name but not explicitly stated, offering no exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop playing a clip.
Parameters:
track_index: The index of the track containing the clip
clip_index: The index of the clip slot containing the clip
| Name | Required | Description | Default |
|---|---|---|---|
| track_index | Yes | ||
| clip_index | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It only states the action without revealing side effects, idempotency, whether the clip must be currently playing, or how it interacts with clip slot state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a single clear sentence and a simple parameter list. No unnecessary fluff, though the parameter descriptions could be integrated more naturally.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple stop operation, the purpose and parameters are covered. However, with no annotations, it lacks guidance on when to use it versus stop_playback and any behavioral context. Acceptable but incomplete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no descriptions for the parameters, but the description clarifies that track_index is 'the index of the track containing the clip' and clip_index is 'the index of the clip slot containing the clip'. This adds meaningful context beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Stop playing a clip' clearly specifies the action (stop) and the resource (a clip). It distinguishes from sibling tools like fire_clip (which starts a clip) and stop_playback (which stops global playback).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like stop_playback or fire_clip. The description does not mention relevant contexts or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop playing the Ableton session.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must convey behavior; it only states the stop action without disclosing side effects like whether the playhead resets or all clips are stopped.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence directly states the tool's function with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description is sufficient, though it could benefit from a note distinguishing session stop from clip stop.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the description cannot add param semantics; baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the verb 'stop' and the resource 'playing the Ableton session,' differentiating it from sibling tools like start_playback and stop_clip.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus stop_clip or other playback controls; it only states the action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
add_notes_to_clipcreate_clipcreate_midi_trackfire_clipget_browser_items_at_pathget_browser_treeget_session_infoget_track_infoload_drum_kitload_instrument_or_effectset_clip_nameset_temposet_track_namestart_playbackstop_clipstop_playbackScored across 16 tools
Most tools have distinct purposes targeting specific resources like clips, tracks, browser, or playback. However, fire_clip and start_playback could be slightly ambiguous as both initiate playback, though fire_clip targets a specific clip while start_playback affects the entire session. The descriptions help clarify this distinction.
All tool names follow a consistent verb_noun pattern with clear, descriptive actions (e.g., add_notes_to_clip, create_clip, get_session_info). There are no deviations in naming conventions, making the set predictable and easy to understand.
With 16 tools, this server is well-scoped for controlling Ableton Live, covering key areas like clip management, track operations, browser navigation, and playback control. Each tool serves a specific function without redundancy, making the count appropriate for the domain.
The toolset provides comprehensive coverage for core Ableton workflows, including creating and managing clips/tracks, loading instruments/effects, and controlling playback. Minor gaps exist, such as no tools for deleting clips or tracks, but agents can work around this by recreating or overwriting resources.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Generate AI music via the Lacuna Music API from MCP clients like Claude Desktop & Code.
Use AI models for chat, image, and video generation from Claude Code and other MCP hosts.
Talk to your public-facing AI from any MCP client — Claude, ChatGPT, Cursor, Cline, Windsurf.
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
