ableton-mcp

Overview Schema Source Related Servers Discussions Admin

show_live_object

Destructive

Selects and reveals an exact track, Session or Arrangement clip, or device in Ableton Live native views using confirm-to-execute plans that preserve focus.

Instructions

Select and show an exact track, Session slot/clip, Arrangement clip or device in native Live views. Omit clipId/deviceId for the track. Plans preserve focus; confirmation changes selection and control-surface focus and may unfold Group ancestors, expand devices and reveal Rack chains. No playback or musical writes requested. Recording must be off. Native view readback does not prove desktop activation, timeline scrolling or plug-in editor visibility. All profile.

Input Schema

Name	Required	Description
`view`	Yes	Requested main view; Session slots require Session and Arrangement clips require Arranger.
`clipId`	No	list_clips Session ID or supported list_arrangement_clips ID.
`dryRun`	No	False executes with token and hash.
`trackId`	Yes	track-N from list_tracks, return-N from get_set_mixer, or master.
`deviceId`	No	ID from list_devices.
`planHash`	No	Plan hash.
`confirmationToken`	No	Single-use plan token.
`expectedStateVersion`	Yes	Observed stateVersion.
`expectedSetFingerprint`	Yes	Current Set fingerprint from get_live_state.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv0.3.1Oct 23, 2026

changedInput schema / properties / clipId / description

Previous value: -"Session ID from list_clips; Arrangement ID from list_arrangement_clips where supported."New value: +"list_clips Session ID or supported list_arrangement_clips ID."

removedOutput schema / additionalProperties
```
Removed value: -true
```

addedOutput schema / anyOf

Added value: +[
+  {
+    "oneOf": [
+      {
+        "properties": {
+          "confirmation": {
+            "properties": {
+              "expiresAt": {
+                "type": "number"
+              },
+              "planHash": {
+                "pattern": "^[a-f0-9]{64}$",
+                "type": "string"
+              },
+              "token": {
+                "minLength": 1,
+                "type": "string"
+              }
+            },
+            "required": [
+              "token",
+              "planHash",
+              "expiresAt"
+            ],
+            "type": "object"
+          },
+          "dryRun": {
+            "const": true
+          },
+          "plan": {
+            "type": "object"
+          }
+        },
+        "required": [
+          "dryRun",
+          "plan",
+          "confirmation"
+        ],
+        "type": "object"
+      },
+      {
+        "properties": {
+          "dryRun": {
+            "const": false
+          },
+          "operationOutcome": {
+            "properties": {
+              "evidence": {
+                "items": {
+                  "type": "string"
+                },
+                "type": "array"
+              },
+              "reason": {
+                "type": "string"
+              },
+              "schemaVersion": {
+                "const": 1
+              },
+              "status": {
+                "enum": [
+                  "applied",
+                  "outcome_unknown",
+                  "postconditions_failed",
+                  "pending_postconditions",
+                  "pending_user_action"
+                ]
+              }
+            },
+            "required": [
+              "schemaVersion",
+              "status",
+              "reason",
+              "evidence"
+            ],
+            "type": "object"
+          }
+        },
+        "required": [
+          "dryRun",
+          "operationOutcome"
+        ],
+        "type": "object"
+      }
+    ],
+    "properties": {
+      "dryRun": {
+        "type": "boolean"
+      }
+    },
+    "required": [
+      "dryRun"
+    ],
+    "type": "object"
+  },
+  {
+    "properties": {
+      "error": {
+        "properties": {
+          "message": {
+            "type": "string"
+          },
+          "outcome": {
+            "enum": [
+              "unknown",
+              "not_executed"
+            ]
+          }
+        },
+        "required": [
+          "message",
+          "outcome"
+        ],
+        "type": "object"
+      }
+    },
+    "required": [
+      "error"
+    ],
+    "type": "object"
+  }
+]

Addedv0.3.0Oct 19, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Beyond the destructive/non-idempotent annotations, the description discloses concrete side effects: confirmation changes selection and control-surface focus, may unfold Group ancestors, expands devices, and reveals Rack chains. It also states that recording must be off and that native view readback does not prove desktop activation, timeline scrolling, or plug-in editor visibility, which is unusually rich behavioral 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 dense but front-loaded: purpose comes first, followed by side effects and limitations. Most sentences earn their place, though the closing phrase 'All profile.' is cryptic and some behavioral clauses are packed together rather than structured for easy scanning.

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?

This is a complex mutation/selection tool with nine parameters, an output schema, and annotations, and the description covers the key behavioral context: what is selected, plan-versus-confirmation effects, recording prerequisites, and readback limitations. Because an output schema exists, it does not need to explain return values, and the schema handles most parameter-level details.

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 schema already carries most parameter meaning. The description adds useful semantics by explaining that clipId/deviceId should be omitted for a track and by naming the object types those IDs target, though it does not add detail for expectedStateVersion, expectedSetFingerprint, planHash, confirmationToken, or dryRun 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 uses a specific verb and resource set: it selects and shows an exact track, Session slot/clip, Arrangement clip, or device in native Live views. It also clarifies the exact-object behavior by saying to omit clipId/deviceId for a track, letting an agent distinguish the target types without opening the schema.

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?

It provides relevant preconditions and behavior: recording must be off, plans preserve focus, and confirmation changes selection and focus. However, it does not explicitly compare this tool with alternatives such as get_selection_context, list_tracks, launch_clip, or the many other selection-related tools, so usage is mostly implied.

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

Deploy Server