Skip to main content
Glama
cavi-ai

ableton-mcp

by cavi-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

capture_midi_session

Destructive

Capture recent hidden MIDI input into Ableton Live Session globally after verifying routing, arm, monitoring, and recording state; known playing-clip changes require explicit approval.

Instructions

Capture Live's hidden recent MIDI input into Session globally. Rechecks native identities, existing note/timing, routing, arms, monitoring and musical/recording state. May start playback/add scenes/change tempo. Known playing-clip changes require explicit allowExistingClipChanges. Read changedSlots and captureVerified; no exact buffer preview or automatic rollback.

Input Schema

NameRequiredDescriptionDefault
dryRunNoFalse executes with token and hash.
planHashNoPlan hash.
confirmationTokenNoSingle-use plan token.
expectedStateVersionYesObserved stateVersion.
allowExistingClipChangesNoExplicit authority for known playing Session clip changes; default false.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.3.1
    • 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"
+  }
+]
  2. Changed6 schema fields changedv0.3.0
    • addedInput schema / properties / allowExistingClipChanges
      Added value: +{
+  "description": "Explicit authority for known playing Session clip changes; default false.",
+  "type": "boolean"
+}
    • changedInput schema / properties / confirmationToken / description
      Previous value: -"Short-lived, single-use token returned by the matching dry run."New value: +"Single-use plan token."
    • changedInput schema / properties / dryRun / description
      Previous value: -"Omit or true to return a plan; false requires a valid confirmationToken."New value: +"False executes with token and hash."
    • changedInput schema / properties / expectedStateVersion / description
      Previous value: -"Exact stateVersion observed immediately before planning."New value: +"Observed stateVersion."
    • changedInput schema / properties / planHash / description
      Previous value: -"Hash returned by the matching dry run."New value: +"Plan hash."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "type": "object"
+}
  3. Addedv0.2.0

TDQS

A3.9/5.0
Behavior5/5

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

Annotations already flag destructive=true, but the description goes well beyond them: it enumerates concrete side effects (may start playback, add scenes, change tempo), states what is NOT available (no exact buffer preview, no automatic rollback), and describes the verification work done (rechecks identities, routing, arms, monitoring). That is exactly the extra context an agent needs before invoking a destructive tool.

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 scope statement is front-loaded and every sentence carries content — side effects, gating flag, and return/limitation notes. It is dense to the point of being telegraphic ('Rechecks native identities, existing note/timing, routing, arms, monitoring and musical/recording state'), which costs a point on readability.

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?

For a destructive, non-idempotent capture operation with a rich output schema, the description covers side effects, the required opt-in flag, and the absence of rollback/preview. What's missing is the failure/precondition surface: what happens when there is no recent MIDI input or when expectedStateVersion is stale.

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 100%, so all five parameters are already documented. The description only re-touches allowExistingClipChanges with the phrase 'require explicit', adding a mild conditional on top of the schema's 'Explicit authority ... default false'. dryRun/planHash/confirmationToken/expectedStateVersion get no added semantics, which is acceptable given full schema coverage.

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?

The first sentence names a specific verb + resource + target scope: capturing Live's recent MIDI input into Session globally. That distinguishes it from the adjacent get_midi_capture_context sibling. It loses a notch because 'hidden recent MIDI input' is jargon-rich and doesn't clarify what 'hidden' means in practice.

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 states one conditional rule — known playing-clip changes require allowExistingClipChanges — which is real usage guidance. However, it never says when to call this vs. get_midi_capture_context or when not to call it (e.g., no recent input, wrong arm state). Usage is implied by the name rather than stated.

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

Deploy Server

Other Tools