How do I use io.github.peterkolbe/ableton-for-ai?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@io.github.peterkolbe/ableton-for-ai What's the current tempo and track list?" 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.

io.github.peterkolbe/ableton-for-ai

by peterkolbe

Overview Schema Related Servers Score Discussions

Python

Local

Ableton for AI

IMPORTANT

For AI Agents: Please read AGENTS.md for detailed technical context and protocol specifications before working on this project.

Ableton for AI is the bridge between your DAW and AI models. It makes Ableton projects hearable and visible to AI models by implementing the Model Context Protocol (MCP) and exporting detailed project data.

What can it do?

Connect Ableton Live directly to MCP-capable AI clients (like Claude Desktop, Cursor, or Cline). The AI can inspect, analyze, and even modify your project in real-time.

Included Tools:

get_overview: SESSION DISCOVERY. Provides tempo, locators, and a list of all tracks with their current mixer state (volume, panning, etc.).
get_track: TRACK INSPECTION. Comprehensive data for a single track: metadata, complete device chain, and all device parameters (with UI-readable strings).
get_tracks: BULK TRACK INSPECTION. Query full data for a range of tracks in a single parallelized call.
analyze_stems: DEEP AUDIO ANALYSIS. Triggers generation of audio summaries (.summary.json) and spectrograms (.spectrogram.webp) for all tracks.
set_track_volume / set_track_panning: MIXER CONTROL. Remotely adjust track faders and panning.
set_device_parameter: REMOTE CONTROL. Precisely adjust any parameter of any device in the project.

Included Resources:

ableton://stems/{track_name}/summary: AUDIO SUMMARY. Compact analysis (JSON) containing LUFS, Peak, RMS, 10ms-frames, detected transients, and a legend field.
ableton://stems/{track_name}/spectrogram: VISUAL ANALYSIS. Log-frequency spectrogram image (WebP) for visual frequency inspection.
ableton://stems/available/summaries: Discovery resource for all tracks with available audio summaries.
ableton://stems/available/spectrograms: Discovery resource for all tracks with available spectrograms.

Related MCP server: ableton-mcp-server

How do I get started?

1. Prepare your environment

Install AbletonOSC

This project relies on AbletonOSC to communicate with Ableton Live.

Download and install AbletonOSC.
Follow the instructions there to add it as a Control Surface in Ableton Live's Link/Tempo/MIDI settings.

Install ableton-for-ai

Option A: uv (Recommended)

uv lets you run the server directly without installing anything globally:

brew install uv          # macOS (Homebrew)
# or: curl -LsSf https://astral.sh/uv/install.sh | sh   (macOS/Linux)
# or: powershell -c "irm https://astral.sh/uv/install.ps1 | iex"  (Windows)

Option B: pip

Requires Python 3.11+ (python.org or brew install python):

pip install ableton-for-ai

2. Connect to your Chatbot (MCP Client)

Add the server to your MCP client configuration (e.g. Claude Desktop, Cursor, or Cline).

Via uvx (if you installed uv)

{
  "mcpServers": {
    "ableton-for-ai": {
      "command": "uvx",
      "args": ["ableton-for-ai"],
      "env": {
        "STEMS_SOURCE_DIR": "/path/to/your/exported/stems"
      }
    }
  }
}

Via pip (if you installed with pip)

{
  "mcpServers": {
    "ableton-for-ai": {
      "command": "ableton-for-ai",
      "env": {
        "STEMS_SOURCE_DIR": "/path/to/your/exported/stems"
      }
    }
  }
}

NOTE

STEMS_SOURCE_DIR must point to the folder where your exported audio stems are located. You need to export stems manually from Ableton Live (e.g. via "Export Audio/Video" with individual tracks selected), as there is currently no OSC API for triggering exports. The audio analysis tools (analyze_stems) will look for files in this directory.

Where to put this config

Claude Desktop (macOS): ~/Library/Application Support/Claude/claude_desktop_config.json
Claude Desktop (Windows): %APPDATA%\Claude\claude_desktop_config.json
Cursor / Cline: See their respective MCP documentation.

Restart your MCP client after saving the config.

3. Use it

Once connected, you can ask the AI about your project state. The AI will use the included tools and resources to fetch data directly from Ableton.

For audio analysis: Export your stems from Ableton Live first (e.g. via File → Export Audio/Video with individual tracks selected) into your configured STEMS_SOURCE_DIR. This step must be done manually, as there is no API for triggering exports.

For complex tasks (e.g. mix feedback): Give the chatbot context about your project. A good starting prompt includes genre, goal, and where your exported stems start (beat or locator). See agent-templates/mix-engineer.md for a ready-to-use prompt template.

Example prompts:

"What is the current tempo and how many tracks do I have?"
"Check the EQ settings on my Lead Synth track."
"Show me an overview of the mixer state."
"Analyze the stems and tell me if there are any frequency clashes."
"Show me the spectrogram for the 'Kick' track."

⚙️ Configuration

You can customize the server behavior by setting environment variables or editing config.py (when running from source).

Variable	Default Value	Description
`LOG_LEVEL`	`"INFO"`	Logging verbosity (`INFO` or `DEBUG`).
`BASE_OUT_DIR`	auto	Where analysis output is stored. Defaults to `{STEMS_SOURCE_DIR}/ableton-for-ai-out` if stems dir is set, else `~/.ableton-for-ai/out`. Override with an absolute path.
`STEMS_SOURCE_DIR`	`"./stems"`	Path where exported stems are located.
`PREFERRED_AUDIO_FORMAT`	`"mp3"`	Audio format to analyze (`mp3` or `wav`).
`SPECTROGRAM_QUALITY`	`90`	Quality of WebP spectrograms (1-100).
`RELEVANT_DEVICE_CLASSES`	`{"Eq8", "Compressor", ...}`	List of Ableton device classes to include in extraction.
`RELEVANT_DEVICE_NAMES`	`{"Pro-Q 4"}`	List of specific plugin names to include.

🔌 Using Custom VSTs / Plugins

1. Register the Plugin Name

In config.py, add the exact name of the plugin as it appears in Ableton to RELEVANT_DEVICE_NAMES.

2. Auto-Populate Parameters (The `Options.txt` Trick)

By default, Ableton Live only exposes the parameters of a third-party plugin, if the overall parameter number threshold (_PluginAutoPopulateThreshold) is below 64 ( default), see here. You can change this to 128 and hope that your favorite custom VSTs will be exposed. If they are still not exposed, because there are too many (e.g. Fab Filter Pro Q 4), you have to configure the parameters within ableton.

Force Ableton to automatically expose parameters by adding -_PluginAutoPopulateThreshold=128 to your Options.txt:

Mac: ~/Library/Preferences/Ableton/Live [Version]/Options.txt
Windows: %AppData%\Ableton\Live [Version]\Preferences\Options.txt

Mac Terminal Commands

To quickly set this up on a Mac, you can use these commands (replace [Version] with your actual Live version, e.g., 12.3.6):

# 1. Navigate to the Preferences folder
cd ~/Library/Preferences/Ableton/Live\ 12.3.6/

# 2. Create the Options.txt file (if it doesn't exist)
touch Options.txt

# 3. Append the setting to the end of the file
echo "-_PluginAutoPopulateThreshold=128" >> Options.txt

OR open the file in a text editor and add the setting manually, e.g.

idea ~/Library/Preferences/Ableton/Live\ 12.3.6/Options.txt

📂 CLI: Analyze & Upload (No MCP required)

This method is ideal for LLMs that don't support MCP directly (like ChatGPT or the Claude Web Interface). It runs the same analysis pipeline locally and exports the results as files you can upload to any chatbot.

Available Commands

Full audio analysis (summaries + spectrograms + full analysis JSONs):

ableton-for-ai-cli analyze_stems

Extract Ableton project metadata only (tracks, devices, parameters):

ableton-for-ai-cli extract_ableton_project_data

Full pipeline (audio analysis AND project data extraction):

ableton-for-ai-cli analyze_stems_and_extract_ableton_project_data

NOTE

The OSC daemon starts automatically — no need to launch it manually.

Output

The results will be stored in the ./out directory, organized into subfolders:

./out/project/: Contains the Ableton project JSON file.
./out/summaries/: Contains compressed audio analysis JSONs (optimized for AI).
./out/spectrograms/: Contains spectrogram WebP images for each stem.
./out/analyses/: Contains full high-resolution analysis JSONs.

Mixing with AI (Manual Upload)

Export your stems from Ableton into your STEMS_SOURCE_DIR.
Run ableton-for-ai-cli analyze_stems to generate analysis files.
Drag and drop the files from your out folder into the chatbot (spectrograms .webp + analysis .json).
Use a prompt like this:

I have attached several audio analysis files (spectrograms and energy analysis).
The given files only reflect a part of the project timeline, see below in Part.

Genre: Drum and Bass
Goal: Improve the clarity of the lead synth and make sure it doesn't clash with the vocals.
Part: The *.analysis.json and *.spectrogram.webp ONLY reflect the part starting at beat 113.

Please analyze the attached files and provide concrete mixing advice.

🛠️ Development & Contributing

Local Setup (from source)

git clone https://github.com/peterkolbe/ableton-for-ai.git
cd ableton-for-ai
uv sync

Run the MCP server from source:

{
  "mcpServers": {
    "ableton-for-ai": {
      "command": "uv",
      "args": [
        "--directory",
        "/absolute/path/to/ableton-for-ai",
        "run",
        "mcp_server_ableton.py"
      ],
      "env": {
        "STEMS_SOURCE_DIR": "/path/to/your/stems"
      }
    }
  }
}

Run CLI commands from source:

uv run ableton_client.py analyze_stems
uv run ableton_client.py extract_ableton_project_data
uv run ableton_client.py analyze_stems_and_extract_ableton_project_data

MCP Inspector (Debugging)

The MCP Inspector is useful for testing and debugging the MCP server during development.

Start it directly via terminal:

npx -y @modelcontextprotocol/inspector uv '--directory /absolute/path/to/ableton-for-ai run mcp_server_ableton.py'

Or start the Inspector without presets and configure it manually:

npx -y @modelcontextprotocol/inspector

Then enter the following in the Inspector UI:

Command: uv
Arguments: --directory /absolute/path/to/ableton-for-ai run mcp_server_ableton.py

Linting & Formatting

uv run ruff check .
uv run ruff format .

Publishing to MCP Registry

To publish a new version to the official MCP Registry:

brew install mcp-publisher
mcp-publisher login github
mcp-publisher publish

Verify the publication:

curl "https://registry.modelcontextprotocol.io/v0/servers?search=io.github.peterkolbe/ableton-for-ai"

Make sure to update the version in both server.json and pyproject.toml before publishing.

⚠️ Known Limitations & Troubleshooting

Automation Tracking

Not Supported: Automation data is not included in the exports.
Technical Reason: The underlying AbletonOSC script does not reliably expose automation status or points in its current version.

📄 License

This project is licensed under the MIT License.

Available Tools

12 tools

analyze_stemsA

DEEP AUDIO ANALYSIS: Triggers the generation of summaries and spectrograms for all tracks.

This is a heavy operation that:

Generates '.summary.json' (Frames, Transients, LUFS) for AI consumption.
Generates '.spectrogram.webp' (Log-frequency visualizations).
Generates '.analysis.json' (Full resolution data for internal use).

ACTION: Use this when you need fresh audio data (e.g., after the user recorded new parts or changed audio effects that significantly alter the sound).

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses the operation is heavy and lists generated artifacts, but with no annotations, it provides limited behavioral detail such as idempotency, failure modes, or prerequisites.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, well-structured with a clear header, bullet points for generated files, and a usage guidance sentence, all without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers purpose, generated artifacts, and usage context, but lacks prerequisite information or potential side effects on previously generated analysis.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With zero parameters, the description adds meaning about the scope (all tracks) and the generated files, which is sufficient and goes beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool triggers deep audio analysis generating specific file types (summaries, spectrograms, analysis) for all tracks, distinguishing it from the read-only and parameter-setting siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly tells when to use (after recording or effect changes) and labels it a heavy operation, but does not mention when not to use or alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_overviewA

SESSION DISCOVERY: Returns a high-level overview of the current Live set.

Includes:

Tempo and Locators (Song structure).
Simplified Track list with mixer states (Index, Name, Volume, Panning, Mute, Solo).

Use this for initial navigation and to identify track indices for further 'get_track' calls.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It describes what the tool returns (overview) but does not explicitly state read-only behavior, safety, or side effects. However, the name and description imply no modifications, so adequate but not detailed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is concise with bullet points, front-loaded with 'SESSION DISCOVERY'. Clear and efficient, though could be slightly more structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no parameters and an existing output schema, the description sufficiently covers what the tool returns and how to use it. Lacks mention of error conditions, but acceptable for a simple overview tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, and schema coverage is 100%. Description adds no param info, which is fine. Baseline for zero params is 4, and the description is clear about what is returned.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it returns a high-level overview of the Live set, specifying included elements (tempo, locators, track list with mixer states). Distinguishes from siblings like get_track (single track) and get_tracks (multiple tracks).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly recommends use for initial navigation and to identify track indices for further get_track calls. Provides clear context for when to use it, though does not explicitly state when not to use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_trackA

TRACK INSPECTION: Returns comprehensive data for a single track.

Includes:

Mixer state (Volume, Panning, etc.).
Complete Device Chain.
All Device Parameters (including UI-readable strings like "-12.0 dB" or "1500 Hz").

Use this when you need to understand exactly how a specific track is processed or which parameters are available for manipulation.

ParametersJSON Schema

Name	Required	Description	Default
`track_index`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description fully explains the return content (mixer state, device chain, UI-readable parameter strings). Since no annotations are provided, it carries the full burden and does so well, though it could explicitly note it is a non-destructive read operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, uses a clear heading, bullet points for included data, and a usage directive. Every sentence adds value with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter tool with an output schema, the description covers the essential aspects: what it does, what it returns, and when to use it. It does not mention error handling or index validation, but these are minor omissions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description does not explain the 'track_index' parameter. The parameter name is self-explanatory, but given the lack of any additional semantic guidance, the score is low.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses 'TRACK INSPECTION' as a verb-resource pair and lists specific data returned (mixer state, device chain, parameters). This clearly distinguishes it from siblings like 'get_tracks' (plural) and 'set_*' tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says 'Use this when you need to understand exactly how a specific track is processed or which parameters are available for manipulation.' This provides clear context but does not mention when not to use it or alternative tools for different needs.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_tracksA

BULK TRACK INSPECTION: Query full data for multiple tracks in a single call.

Parameters:

index_min: Starting track index.
index_max: Ending track index.

Returns an array of track objects, identical in structure to 'get_track'. Highly efficient for analyzing groups of tracks (e.g., all drum tracks).

ParametersJSON Schema

Name	Required	Description	Default
`index_min`	Yes
`index_max`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description clearly indicates a read operation (query) with no side effects, which is obvious from the context. However, lacking annotations, it does not explicitly confirm non-destructiveness or mention any rate limits, though the absence of such hints is acceptable for a simple 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise, using a bold header 'BULK TRACK INSPECTION' for immediate attention, followed by a brief purpose, parameter list, return type mention, and a usage example. Every sentence adds value with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists, the description covers essential aspects: purpose, parameters, return type (identical to get_track), and a usage example. It lacks explicit details on index bounds or behavior for invalid inputs, but overall it sufficiently equips an agent for correct use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With schema description coverage at 0%, the description compensates by defining both parameters: index_min as start index and index_max as end index. This adds clear meaning beyond the bare integer type in the schema, though it could specify whether indices are zero-based.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states 'Query full data for multiple tracks in a single call,' providing a specific verb (query) and resource (tracks). It distinguishes from the sibling 'get_track' by focusing on bulk retrieval and mentions an example (all drum tracks), making the purpose unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description guides usage by stating it is 'highly efficient for analyzing groups of tracks,' implying it should be used when multiple tracks are needed. It contrasts with 'get_track' for single tracks but does not explicitly state when not to use it or mention alternatives like 'list_resources' for obtaining track indices.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_resourcesB

List resources available on the server.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description implies a read-only operation (listing), but no annotations are provided to confirm non-destructive behavior. It does not mention side effects or permissions, but the tool name and simple description adequately convey safety for a listing operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise with one sentence that is front-loaded. However, it could be slightly more informative without becoming verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that the tool has no parameters and an output schema exists, the description is sufficient for an agent to understand it returns a list of resources. It is complete enough for a simple listing tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has no parameters, and the schema coverage is 100% (trivially). Per guidelines, baseline for 0 parameters is 4. The description adds no param info, but none is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'list' and the resource 'resources', indicating the tool lists available resources. It is distinct from sibling tools which perform specific operations like analyzing stems or getting individual tracks, but it does not explicitly differentiate its purpose from the general listing context.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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. With many sibling tools performing specific actions, the description lacks context for the agent to decide when listing is appropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

read_resourceC

Read a resource available on the server.

ParametersJSON Schema

Name	Required	Description	Default
`uri`	Yes	The URI of the resource to read.

Output Schema

ParametersJSON Schema

Name	Required	Description
`contents`	Yes
`meta`	No

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description must fully disclose behavioral traits. It only states the basic action, omitting details like idempotency, error handling, or side effects. The read nature is implied but not explicitly confirmed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that directly states the purpose with no extraneous words. It is concise and front-loaded, though it could include more detail without sacrificing brevity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple input with one parameter and the existence of an output schema, the description is adequate for a basic read operation. However, it does not clarify what types of resources are accessible or handle potential error conditions, leaving some gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% (the 'uri' parameter has a description). The tool description does not add any parameter information beyond the schema, so it meets the baseline of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Read') and a resource type ('resource available on the server'), making the purpose clear. However, it does not differentiate from sibling tools like get_track or list_resources, which also read resources, so it loses a point.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 specify prerequisites, when not to use it, or any context for selection among siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

set_device_parameterA

REMOTE CONTROL: Sets a specific device parameter.

Parameters:

track_index: The index of the track.
device_index: The index of the device in the chain.
parameter_index: The index of the parameter to change.
value: The new normalized value (0.0 to 1.0).

Note: For UI-readable values (like dB or Hz), check 'get_track' output first, but always send the normalized 0.0-1.0 value for the actual change.

ParametersJSON Schema

Name	Required	Description	Default
`track_index`	Yes
`device_index`	Yes
`parameter_index`	Yes
`value`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Describes the expected value range (0.0 to 1.0) and mentions the need for normalized values. No annotations are provided, so the description carries the burden. It does not disclose side effects or error behavior, which is acceptable for a simple setter.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with two clear paragraphs. The first states the action, the second lists parameters and a usage note. It is well-structured, though slightly verbose with the note formatting.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema (not shown), the description does not need to explain return values. It covers the basic operation and parameter details. However, it lacks information about error handling or what happens if indices are out of range.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, but the description fully explains each parameter, including the normalization of 'value'. This compensates completely for the schema gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Sets a specific device parameter,' which is a specific verb and resource. It distinguishes from siblings like 'set_device_parameters' and other set_track_* tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides guidance on when to check 'get_track' for UI-readable values and emphasizes using normalized values. However, it does not explicitly state when not to use this tool or list alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

set_device_parametersA

BULK REMOTE CONTROL: Sets multiple parameters for a device at once.

Parameters:

values: A list of floats representing the new values for ALL parameters of the device.

Recommended for loading 'presets' or making simultaneous multi-parameter adjustments.

ParametersJSON Schema

Name	Required	Description	Default
`track_index`	Yes
`device_index`	Yes
`values`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full behavioral disclosure burden. It states the tool sets multiple parameters but does not mention side effects, validation behavior (e.g., what if the values list length mismatches), or whether changes are reversible. The explanation that values are for 'ALL parameters' is helpful but incomplete.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise: two short paragraphs and a bullet. The heading 'BULK REMOTE CONTROL' front-loads the purpose. Every sentence adds value with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has an output schema (implied) but the description does not mention return values, which is acceptable per rules. However, it lacks behavioral completeness: no error handling, prerequisites, or confirmation of action. For a simple 3-parameter bulk operation, it is minimally adequate but could be more thorough given no annotations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description must compensate. It explains the 'values' parameter as 'new values for ALL parameters', but does not describe 'track_index' or 'device_index' beyond their parameter names. Missing details like allowed ranges or how they identify devices.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'Sets multiple parameters for a device at once.' The 'BULK REMOTE CONTROL' heading immediately indicates batch operation, distinguishing it from the sibling tool 'set_device_parameter' which handles single parameters.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly recommends use cases: 'Recommended for loading 'presets' or making simultaneous multi-parameter adjustments.' This provides clear guidance on when to use this tool versus the alternative single-parameter tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

set_track_muteC

Toggles the mute status of a track (True=Muted, False=Active).

ParametersJSON Schema

Name	Required	Description	Default
`track_index`	Yes
`mute`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description carries full burden. It explains the boolean meaning but does not disclose any potential side effects, destructive behavior, required permissions, or what happens on failure. The description is minimal.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that is direct and front-loaded, containing no redundant or unnecessary information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the 0% schema coverage and lack of annotations, the description is insufficient. It fails to explain parameters or the output schema, leaving the agent with incomplete context for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description adds no meaning beyond the schema. It does not explain what 'track_index' or 'mute' represent, nor their expected values or formats.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('toggles') and the resource ('mute status of a track'), and explains the boolean mapping. It effectively distinguishes itself from sibling tools like 'set_track_solo' or 'set_track_volume'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 vs alternatives. Sibling tools like 'set_track_solo' and 'set_track_volume' exist but the description does not offer any context for choosing between them.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

set_track_panningA

MIXER CONTROL: Sets the panning of a track.

value: -1.0 (Left) to 1.0 (Right), 0.0 is Center.

ParametersJSON Schema

Name	Required	Description	Default
`track_index`	Yes
`value`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description explains the effect (panning) and the value range, providing sufficient transparency for a simple setter with no annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise, front-loaded purpose, and every word adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple tool and existence of output schema, the description adequately covers core functionality, but lacks details on possible errors or edge cases.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds context for the 'value' parameter (range and meaning), but does not describe 'track_index' beyond it being the target track, which is partially derived from context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool sets track panning and defines the value range, distinguishing it from sibling tools like set_track_volume.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use or avoid this tool; the context is implied by the tool's purpose, but alternatives are not mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

set_track_soloC

Toggles the solo status of a track (True=Solo, False=Normal).

ParametersJSON Schema

Name	Required	Description	Default
`track_index`	Yes
`solo`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The term 'Toggles' is misleading because the parameter sets solo to a specific boolean value, not inverts an existing state. With no annotations, the description fails to disclose side effects, prerequisites (e.g., track must exist), or error behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very short (one sentence) and front-loaded, but it sacrifices necessary detail for brevity. It could be more accurate and informative without adding much length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having an output schema, the description provides no context on return values or success indicators. It also lacks information about required preconditions (e.g., track existence) or constraints. The tool's complexity is low, but the description remains incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%. The description explains the 'solo' parameter well but leaves 'track_index' completely undefined—no indication of valid range, required format, or meaning. Only one of two parameters gains meaning from the description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (toggles solo status) and the resource (track), and the parenthetical clarifies the mapping for the boolean parameter. It distinguishes itself from siblings like set_track_mute by specifying 'solo' specifically.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 set_track_mute or set_track_volume. The context of toggling versus setting is implied but not explicitly clarified, and no when-not-to-use scenarios are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

set_track_volumeB

MIXER CONTROL: Sets the volume of a track.

value: 0.0 to 1.0 (corresponds to Ableton's internal fader scaling).

ParametersJSON Schema

Name	Required	Description	Default
`track_index`	Yes
`value`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must disclose behavior fully. It mentions value scaling but omits prerequisites, side effects, error handling, or whether changes are permanent. Important behavioral traits are missing.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short and efficient, with a front-loaded context label. Every sentence adds value, though the 'MIXER CONTROL:' prefix is slightly redundant with the tool's purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simplicity (2 parameters, no nested objects) and presence of an output schema, the description provides a minimal but functional explanation. However, it lacks details about return values and preconditions, making it only adequately complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so description must compensate. It explains 'value' semantics (range and scaling) but provides no information on 'track_index', leaving half the parameters undocumented. Partial improvement over schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool sets track volume, includes the value range (0.0 to 1.0) and references Ableton's internal fader scaling, distinguishing it from sibling mixer tools like set_track_mute or set_track_panning.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies mixing context via 'MIXER CONTROL:' but does not explicitly state when to use this tool versus alternatives or provide any exclusion criteria. It is adequate but lacks explicit guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Disambiguation5/5

Each tool targets a distinct action or resource: analysis, session overview, single/bulk track inspection, device parameter control (single and bulk), and individual mixer controls. No overlapping purposes; descriptions clearly differentiate them.

Naming Consistency4/5

All tool names use snake_case and follow a verb_noun pattern, but verbs vary (get_, set_, list_, read_, analyze_). While readable, the mix is slightly inconsistent; e.g., list_resources vs get_track.

Tool Count5/5

12 tools is well-scoped for an Ableton Live MCP server covering session discovery, track inspection, device parameter control, mixer control, and audio analysis. No unnecessary tools; each serves a clear purpose.

Completeness4/5

The set covers core inspection, parameter control, and mixer operations. Minor gaps exist (e.g., no track/device creation or deletion, no transport control), but the domain focus on AI-driven adjustment and analysis makes it acceptably complete.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

mcp-producer
io.github.AceDataCloud
MCP server for Producer/Riffusion AI music generation
Audio Processing AI & Machine Learning
22
strata
ai.klavis
MCP server for progressive tool usage at any scale (see https://klavis.ai)
Agent Orchestration Autonomous Agents Developer Tools
25,748
mcp-server
com.niftypm
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Project Management Communication File Systems
2
Keyboardia A
io.github.adewale
Create, co-edit, analyze, publish, and export collaborative step-sequencer sessions through MCP.
Audio Processing Multimedia Processing
713

Related MCP Servers

Ableton Copilot MCP
App Automation Multimedia Processing Audio Processing
xiaolaa2
A
license
C
quality
B
maintenance
A Model Context Protocol server that enables real-time interaction with Ableton Live, allowing AI assistants to control song creation, track management, clip operations, and audio recording workflows.
Updated a month ago (2026-07-29 08:01 UTC)
23
28
91
MIT
ableton-mcp-server
Multimedia Processing Audio Processing
giuliobracci
F
license
Not graded
quality
C
maintenance
MCP server that enables AI agents to read and edit Ableton Live sets, including tracks, clips, MIDI notes, devices, and scenes.
Updated 3 months ago (2026-06-02 23:31 UTC)
1
ableton-mind
Audio Processing Multimedia Processing
Pantani
A
license
A
quality
B
maintenance
MCP server for Ableton Live that exposes the Live Object Model to LLMs, enabling natural language control of music production.
Updated 2 months ago (2026-06-24 01:55 UTC)
36
99
5
MIT
ableton-mcp
Audio Processing Multimedia Processing
amamparo
F
license
B
quality
D
maintenance
MCP server for controlling Ableton Live, enabling AI assistants to interact with Live sessions through tools for track/clip/scene management, playback control, and device parameter adjustments.
Updated 7 months ago (2026-02-12 02:40 UTC)
48

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/peterkolbe/ableton-for-ai'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

Ableton for AI

What can it do?

How do I get started?

1. Prepare your environment

Install AbletonOSC

Install ableton-for-ai

Option A: uv (Recommended)

Option B: pip

2. Connect to your Chatbot (MCP Client)

Via uvx (if you installed uv)

Via pip (if you installed with pip)

Where to put this config

3. Use it

⚙️ Configuration

🔌 Using Custom VSTs / Plugins

1. Register the Plugin Name

2. Auto-Populate Parameters (The Options.txt Trick)

Mac Terminal Commands

📂 CLI: Analyze & Upload (No MCP required)

Available Commands

Output

Mixing with AI (Manual Upload)

🛠️ Development & Contributing

Local Setup (from source)

MCP Inspector (Debugging)

Linting & Formatting

Publishing to MCP Registry

⚠️ Known Limitations & Troubleshooting

Automation Tracking

📄 License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

2. Auto-Populate Parameters (The `Options.txt` Trick)