ableton-mcp

Overview Schema Source Related Servers Discussions Admin

get_looper_export_context

Read-onlyIdempotent

Read a Looper device's export context to get capability, buffer length, state, and destination slot without changing focus or playback.

Instructions

Read native Looper export capability, buffer length, state and an exact destination slot without changing focus or playback. Buffer audio bytes are unavailable.

Input Schema

Name	Required	Description
`trackId`	Yes	track-N from list_tracks, return-N from get_set_mixer, or master.
`deviceId`	Yes	ID from list_devices.
`destinationClipId`	Yes	list_clips Session ID or supported list_arrangement_clips ID.
`destinationTrackId`	Yes	ID from list_tracks.

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 / destinationClipId / 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: +[
+  {
+    "properties": {
+      "canExport": {
+        "type": "boolean"
+      },
+      "clipId": {
+        "anyOf": [
+          {
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ]
+      },
+      "destination": {
+        "type": "object"
+      },
+      "deviceId": {
+        "anyOf": [
+          {
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ]
+      },
+      "identityToken": {
+        "type": "string"
+      },
+      "loopLength": {
+        "anyOf": [
+          {
+            "type": "number"
+          },
+          {
+            "type": "null"
+          }
+        ]
+      },
+      "parameters": {
+        "items": {
+          "type": "object"
+        },
+        "type": "array"
+      },
+      "reason": {
+        "anyOf": [
+          {
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ]
+      },
+      "setFingerprint": {
+        "type": "string"
+      },
+      "stateVersion": {
+        "minimum": 1,
+        "type": "integer"
+      },
+      "status": {
+        "type": "string"
+      },
+      "supported": {
+        "type": "boolean"
+      },
+      "tempo": {
+        "anyOf": [
+          {
+            "type": "number"
+          },
+          {
+            "type": "null"
+          }
+        ]
+      },
+      "trackId": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "stateVersion"
+    ],
+    "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.7/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description still adds real behavioral context beyond them: the operation does not steal focus or interrupt playback, and critically that no buffer audio bytes are returned — a limitation an agent could otherwise assume away when planning an export.

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?

Two tight sentences with the read-only guarantee front-loaded and the audio-bytes caveat as a closing constraint. No filler, though the second sentence is fragmentary rather than integrated.

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?

An output schema covers the return shape, and all four required parameters are schema-documented, so the description only needs to establish read-only semantics and the missing-audio caveat — both present. The remaining gap is not clarifying the relationship to export_looper_clip, which an agent would need to sequence work.

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 description coverage is 100%, so each of the four IDs is already documented with its source tool. The description only gestures at 'an exact destination slot', loosely hinting at destinationTrackId/destinationClipId, without adding format or constraint detail. Baseline 3 applies when the schema does the heavy lifting.

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 specific verb (Read) and enumerates exactly what is returned: native Looper export capability, buffer length, state, and the resolved destination slot. This clearly separates it from a plain state read, though it never names the siblings it is adjacent to (get_looper_performance_context, export_looper_clip, set_looper_state).

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?

'without changing focus or playback' implies this is the non-intrusive inspection path, but it never states when to pick this over get_looper_performance_context or when to move on to export_looper_clip. Usage is inferable rather than instructed.

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

Deploy Server