Skip to main content
Glama

delete_device

Destructive

Remove a device and its settings from an Ableton Live track chain. Review the reported track, device name, class, and parameter count with confirm=false, then set confirm=true to complete the deletion.

Instructions

Delete one device from a track chain, its settings with it.

Requires confirm=True. With confirm=False it reports the name of the track, and
the device's name, class and parameter count, and changes nothing.

Returns:
    Dictionary reporting deletion status or pending loss report.

Note:
    The track is named in the report because a device name does not identify
    one. A device class like Utility or EQ Eight sits on several tracks in a
    normal set, so a loss report naming only the device reads the same whether
    the index points at the intended chain or at a neighbour's. Check the track
    name against the one you meant before confirming.

    Deleting shifts every later device in the chain down one index, so a second
    delete aimed at an index read before the first one lands on a different
    device. Read the chain again with get_devices between deletes.

    Two neighbouring intentions are not this tool. To reorder a chain nothing
    needs deleting: call ``song.move_device`` through lom_call. To swap the
    instrument on a track, load the replacement with load_device, which replaces
    the instrument already there in one step (measured). Deleting first only
    loses the settings earlier.

    ``kind`` reaches the return and main chains, which are addressed the same way
    get_devices addresses them. A return track carries its own index and the main
    track has none, so ``track`` is not read at all when kind is master.

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.
deviceYesDevice index in that track chain, counted from 0 left to right as Live draws it. get_devices lists the chain with its indices.
confirmNoTrue carries the removal out. False changes nothing and returns a report of what the call would remove, which is how to look before committing to it.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

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

  1. Changed1 schema field changedv0.1.4
    • addedInput schema / properties / kind
      Added value: +{
      +  "default": "track",
      +  "description": "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.",
      +  "enum": [
      +    "track",
      +    "return",
      +    "master"
      +  ],
      +  "title": "Kind",
      +  "type": "string"
      +}
  2. Changed3 schema fields changedv0.1.1
    • addedInput schema / properties / confirm / description
      Added value: +"True carries the removal out. False changes nothing and returns a report of what the call would remove, which is how to look before committing to it."
    • addedInput schema / properties / device / description
      Added value: +"Device index in that track chain, counted from 0 left to right as Live draws it. get_devices lists the chain with its indices."
    • addedInput schema / properties / track / description
      Added value: +"Track index in song.tracks, counted from 0."
  3. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations declare destructiveHint=true, but the description adds far more: the confirm=True/False safety gate with a no-op preview mode, the index-shifting side effect that makes repeated deletes land on different devices, and the rationale for why the track name appears in reports (device names are not unique across tracks). It also clarifies the return shape ('Dictionary reporting deletion status or pending loss report').

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 (~220 words) but front-loaded with the core action and confirm semantics, then organized into Returns and a structured Note with distinct points. Every section addresses a real failure mode, but the Returns line is mildly redundant with the confirm paragraph and the track-naming rationale could be tightened. Slightly verbose, never wasteful.

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 destructive, non-idempotent mutation tool with 4 parameters, this is complete: it covers the danger gate (confirm), post-call hazard (index shift) and its mitigation, equivalent alternatives, cross-tool addressing consistency (get_devices), and a parameter edge case (master ignores track). The output schema exists, so return details need no further elaboration.

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 genuine behavioral nuance beyond the schema: that 'track' is not read at all when kind is master, that kind addresses return/main chains the same way get_devices does, and how confirm=False frames the report as a look-before-committing preview. This exceeds the baseline.

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 line names a specific verb ('Delete'), a precise resource ('one device from a track chain'), and the scope of the effect ('its settings with it'). It unambiguously distinguishes this from sibling deletion tools like delete_track and delete_clip, and from non-destructive neighbors like load_device.

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 rules out neighboring intentions: reordering a chain should use song.move_device via lom_call, and swapping an instrument should use load_device because 'Deleting first only loses the settings earlier.' It also instructs the agent to re-read the chain with get_devices between deletes—concrete operational guidance for correct sequencing.

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