Skip to main content
Glama

set_parameter

Idempotent

Set a device parameter by index or name and verify the read-back in Ableton Live. Uses normalised values, reports clamps for quantized steps.

Instructions

Set one device parameter by index or name and verify the read-back.

Returns:
    Dictionary reporting the write, the parameter index it resolved to, the
    read-back value, and the display string where the device offered one.

Note:
    Parameter values are normalised, not the unit the device displays. Read ``min``
    and ``max`` (``describe`` with ``with_parameters=True``) rather than assuming
    a range.

    The curve from 0..1 onto the displayed unit is not linear and differs per
    device. On one third-party compressor Attack is ``v^4 * 1000 ms``, so writing
    "10 ms" linearly lands at 316 ms, a factor of 30, silently. Where the device
    reports a display, aim with the display. Where it does not (all VST2), write
    normalised and calibrate by eye once.

    A parameter that shows a display also answers ``str_for_value``: lom_call with the
    parameter path, ``method='str_for_value'`` and one value returns the string that
    value would display, and moves nothing. That maps a unit onto the scale without
    deriving the taper by trial (catalog row param.str_for_value).

    A quantized parameter takes discrete steps, so a written 0.5 can legitimately read
    back as something else, and that is reported as a clamp rather than as a failure.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kindNoWhich collection the track index counts in: 'track' for song.tracks, 'return' for song.return_tracks, 'master' for the master track, where the track index is ignored.track
trackYesTrack index in song.tracks, counted from 0.
valueYesTarget value in the parameter own units, which are normalised and device-specific rather than the unit the device displays. Read ``min`` and ``max`` with ``describe`` first: the range is whatever the device declares and is often not 0..1.
deviceYesDevice index in that track chain, counted from 0. get_devices lists the chain with its indices.
parameterYesWhich parameter, either its index as a string ('1') or its name, which may be a glob ('Attack*'). A name that matches more than one parameter is refused rather than guessed at. ``describe`` with with_parameters=True lists the names.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed6 schema fields changedv0.1.1
    • addedInput schema / properties / device / description
      Added value: +"Device index in that track chain, counted from 0. get_devices lists the chain with its indices."
    • addedInput schema / properties / kind / description
      Added value: +"Which collection the track index counts in: 'track' for song.tracks, 'return' for song.return_tracks, 'master' for the master track, where the track index is ignored."
    • addedInput schema / properties / kind / enum
      Added value: +[
      +  "track",
      +  "return",
      +  "master"
      +]
    • addedInput schema / properties / parameter / description
      Added value: +"Which parameter, either its index as a string ('1') or its name, which may be a glob ('Attack*'). A name that matches more than one parameter is refused rather than guessed at. ``describe`` with with_parameters=True lists the names."
    • addedInput schema / properties / track / description
      Added value: +"Track index in song.tracks, counted from 0."
    • addedInput schema / properties / value / description
      Added value: +"Target value in the parameter own units, which are normalised and device-specific rather than the unit the device displays. Read ``min`` and ``max`` with ``describe`` first: the range is whatever the device declares and is often not 0..1."
  2. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false), the description discloses critical behaviors: values are normalized rather than displayed units, the curve is nonlinear and device-specific, quantized parameters can legitimately clamp, and ambiguous names are refused. This is rich, honest behavioral context that prevents silent misconfiguration.

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 front-loaded with the core purpose and return summary, then organized into a focused Note section. While lengthy, each sentence addresses a real operational pitfall (normalized units, nonlinear curves, quantization, str_for_value). It is longer than minimal but justified by the tool's subtle failure modes.

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

Completeness5/5

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

Given the tool's complexity and the rich output schema, the description covers all essential operational context: value normalization, how to discover valid ranges, how to handle nonlinearity, quantization behavior, and ambiguous names. An agent has enough to call it correctly and interpret results without missing surprises.

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?

Schema coverage is 100%, so the baseline is 3. The description adds meaningful semantics beyond the schema: it explains normalization, non-linear scaling, the meaning of the value parameter in device-specific terms, and the glob/refusal behavior of the parameter name. This goes beyond what the schema already states without repeating it.

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 opens with a specific verb and resource: 'Set one device parameter by index or name and verify the read-back.' This clearly distinguishes it from sibling tools like set_mix, set_tempo, and lom_set by focusing on device parameters and read-back verification. The purpose is unambiguous and immediately actionable.

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 gives explicit usage guidance: read min/max with describe before writing, use the device display when available, and use str_for_value to map units without trial. It stops short of naming alternatives or saying when not to use this tool, so it lacks explicit exclusions, but the context is strong and practical.

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

Latest Blog Posts

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/romanstark/live-maestro'

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