Skip to main content
Glama
ntworm

Ableton MCP Server

set_plugin_preset

Select a plugin preset by index or exact name on a track device and verify the readback. Unknown names or out-of-range indexes return structured errors.

Instructions

Select one plugin preset by index or exact name and verify the readback.

Side effects: switches the plugin preset in one Live undo step. Example: set_plugin_preset(2, 2, preset_name="Rock Kit") selects a preset without the Configure step set_parameter_value needs. Edge cases: pass exactly one selector; unknown names, out-of-range indexes, and plugins that expose no presets return structured errors.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
preset_nameNo
track_indexYes
device_indexYes
preset_indexNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.7.0

TDQS

A4.4/5.0
Behavior4/5

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

Without annotations, the description carries the full behavioral burden. It discloses the key side effect (switches preset in one Live undo step) and states that edge cases return structured errors. It does not, however, describe any permission or state prerequisites beyond the error cases.

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 front-loaded with the main action, then uses clear labels for side effects, example, and edge cases. Every sentence adds distinct value with no redundant phrasing.

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?

With no output schema, the description should cover returns, and it mentions verifying the readback but does not detail the return shape. It adequately covers purpose, side effects, example, and errors, but gaps remain for track_index and device_index semantics given the total lack of schema descriptions.

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 the description must compensate. It clarifies that preset_name is an exact name, that either preset_index or preset_name may be used, and that exactly one selector must be passed. It does not explain track_index or device_index at all, leaving those parameters undocumented.

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 states a specific verb (Select), resource (plugin preset), and selection methods (by index or exact name). It distinguishes itself from set_parameter_value by noting it skips the Configure step, making its purpose unmistakable relative to that key sibling.

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?

It explicitly names set_parameter_value as an alternative and gives the condition under which this tool is preferred: no Configure step needed. It also gives the usage rule to pass exactly one selector and specifies error conditions for unknown names and out-of-range indexes.

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

Deploy Server

Other Tools