ableton-mcp

Overview Schema Source Related Servers Discussions Admin

set_browser_preview

Destructive

Controls Ableton browser previews: start an exact native item or stop globally, replacing or stopping any user preview; start requires recording/count-in off.

Instructions

Request start for an exact native browser item, or global stop. Can replace or stop a user preview. Guarded single native call; no loading, transport edits, ownership, active-state or audible verification. Start requires recording/count-in off. No automatic cleanup or replay. Updated bridge; all profile.

Input Schema

Name	Required	Description
`path`	No
`root`	No	Exact browser root for start only.
`action`	Yes
`dryRun`	No	False executes with token and hash.
`planHash`	No	Plan hash.
`confirmationToken`	No	Single-use plan token.
`expectedStateVersion`	Yes	Observed stateVersion.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.3.1Oct 23, 2026

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

A3.6/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=false, but the description adds real value beyond that: it discloses that this is a guarded single native call, that it does not load, edit transport, take ownership, verify active state, or verify audibility, and that there is no automatic cleanup or replay. The remaining gap is the dryRun/planHash/confirmationToken execution flow, which is only partially hinted at.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core constraints are front-loaded and dense in the first three sentences, which is good. But 'Updated bridge; all profile.' is cryptic filler that consumes space without conveying a usable constraint, and the telegraphic style makes several exclusions ambiguous in scope.

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?

This is a destructive, guarded mutation with an output schema, so the description's job is largely preconditions and negative scope, both of which it covers well ('no loading', 'no audible verification', 'no automatic cleanup or replay', recording/count-in requirement). Only the transactional confirmation flow and the state-version conflict behavior are left implicit for an agent to assemble.

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 71%, so the baseline is 3. The description reinforces that root/path must be an 'exact' browser item for start, but it says nothing about expectedStateVersion as a concurrency guard or about the plan-hash/confirmation-token confirmation sequence, leaving the two required non-action parameters to the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a concrete verb and resource: request start for an exact native browser item, or global stop, which is more specific than the tool name alone. The phrase 'no loading' implicitly separates it from load_browser_item, but the obvious read companion get_browser_preview_context is never named, so differentiation is inferred rather than stated.

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?

'Can replace or stop a user preview' and 'Start requires recording/count-in off' give a precondition and a behavioral consequence, which implies when the call will succeed. However there is no explicit guidance on when to use this versus get_browser_preview_context, nor any statement of what to do when the precondition is unmet.

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

Deploy Server