Skip to main content
Glama

set_parameter_display

Idempotent

Set a device parameter by the display reading you want (e.g. -26 dB, 8 kHz) instead of a raw value. It probes the device's display curve, writes the matching value, and verifies the result.

Instructions

Set a device parameter by the reading it should show, not by its raw value.

Returns:
    Dictionary reporting the value written, the display it produced, the residual
    error against the target, the unit, and how many probes and round trips it
    took. On refusal, why - including the case where the device reports no units.

Note:
    The inverse of ``set_parameter``, and there is no formula to invert: the curve from
    the raw range onto the displayed unit differs per parameter and is rarely linear. On
    one measured third-party compressor Attack is ``v^4 * 1000 ms``, Ratio is ``20^v``
    and Threshold about ``40 * log10(v)``, so writing 10 at a parameter that displays
    milliseconds lands at 316 ms, a factor of 30, and reports success.

    The taper is sampled, not computed: one batch of probes asks what each raw value
    would read as, the answers are bracketed around the target, a second batch refines
    inside that bracket, and only then is a single value written and read back. Two
    round trips, and nothing in the set moves until that last step. Probing with real
    writes has been measured leaving Delay Feedback at 100 % (self-oscillation) and
    Saturator Drive at 100 % across 20 parameters (catalog row
    return_device.str_for_value); the probes here write nothing. They also stay strictly
    inside the range and never ask at ``min`` or ``max``, where a plug-in's own
    formatting code has crashed Live in native code no try/except reaches
    (docs/limits.md, 'Asking for a display string at an endpoint (Live)').

    Where the device reports no unit this refuses instead of aiming: every VST2 reports
    a bare number (0 of 36 measured), so a display-driven search there would walk the
    control to its end stop and call it a result. Use ``set_parameter`` with a
    normalised value for those and calibrate by ear once. The result is the stored value
    and its display, which is not audibility: a parameter on a device that is switched
    off reads back exactly the same.

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
unitNoWhich unit the target is in: 'dB', 'Hz', 'ms', '%', 'ratio', 'st', 'cents' or 'x'. Give kHz as Hz and seconds as ms. Optional: when omitted the unit the device reports is used, and a device reporting a different unit than you expected is a refusal, not a guess.
trackYesTrack index in song.tracks, counted from 0.
deviceYesDevice index in that track chain, counted from 0. get_devices lists the chain with its indices.
targetYesThe reading you want, as a bare number in the base unit: -26 for -26 dB, 8000 for 8 kHz, 150 for 150 ms, 4 for a 4:1 ratio. Not the normalised value - that is set_parameter.
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.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.4

TDQS

A4.8/5.0
Behavior5/5

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

Very rich behavioral disclosure: probes write nothing, nothing moves until a final single write, range is strictly bounded to avoid crashing Live, refusal occurs when a device reports no unit, and the stored value is not audibility. This far exceeds what annotations (destructiveHint=false, idempotentHint=true) convey and adds critical operational context.

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 long but front-loaded with a clear one-sentence purpose. Returns and Note sections are dense, not padded, and almost every sentence earns its place. Some internal references like 'catalog row return_device.str_for_value' and the measured third-party examples are slightly over-specific but still support the safety argument.

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?

For a tool with an output schema, 6 params, and a subtle domain, this is complete. It covers failure modes (no-unit refusal, name ambiguity refusal), safety behavior (range bounds, no writes during probing), helper routing to set_parameter, and the semantics of the returned display. Nothing needed to invoke it correctly is missing.

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 baseline is 3. The description adds real extra meaning by clarifying target is a display reading not a normalised value, giving concrete examples like -26 dB and 8000 for 8 kHz, and explaining refusal semantics when units mismatch. The v^4 * 1000 ms example makes the non-linear mapping tangible.

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 opening sentence states a specific verb+resource+semantic: 'Set a device parameter by the reading it should show, not by its raw value.' This immediately distinguishes the tool from its sibling set_parameter. The Returns section and Note section continue to reinforce what the tool does and what it refuses to do, 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 Guidelines5/5

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

The description explicitly says when to use this tool (when aiming at display reading, when units are known) and when not to: 'Use set_parameter with a normalised value for those' VST2/no-unit devices. It also names the inverse relationship and explains why the inverse is necessary, giving clear routing between sibling tools.

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