Skip to main content
Glama
cavi-ai

ableton-mcp

by cavi-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

analyze_arrangement_section

Read-onlyIdempotent

Read an Arrangement beat window across selected or all ordinary tracks to report overlapping clips, loop repeats, trimmed boundaries, and stored-MIDI tonal evidence. Add harmony for timed pitch sets.

Instructions

Read one explicit Arrangement beat window across all or selected ordinary tracks. Report overlapping clips and projected stored-MIDI tonal evidence with loop repeats and trimmed boundaries. Optional includeHarmony adds timed pitch sets, literal chord candidates and gaps. Includes muted material; audio, drums, recording and large clips remain explicit exclusions. Not playback, a detected key, or a meter/key map. Read-only; no focus changes.

Input Schema

NameRequiredDescriptionDefault
endBeatsYesExclusive end; increasing range, at most 512 beats.
trackIdsNoOptional unique ordinary tracks; omit for all, up to 64.
startBeatsYesInclusive song-time start in quarter-note beats.
includeHarmonyNoInclude timed stored-pitch sets and exact chord candidates, gaps and ambiguity. At most 4096 projected spans and 256 intervals; no inferred harmonic function or audio.

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: +[
+  {
+    "properties": {
+      "coverage": {
+        "type": "object"
+      },
+      "parts": {
+        "items": {
+          "type": "object"
+        },
+        "type": "array"
+      },
+      "stateVersion": {
+        "minimum": 1,
+        "type": "integer"
+      }
+    },
+    "required": [
+      "stateVersion",
+      "parts",
+      "coverage"
+    ],
+    "type": "object"
+  },
+  {
+    "properties": {
+      "error": {
+        "properties": {
+          "message": {
+            "type": "string"
+          },
+          "outcome": {
+            "enum": [
+              "unknown",
+              "not_executed"
+            ]
+          }
+        },
+        "required": [
+          "message",
+          "outcome"
+        ],
+        "type": "object"
+      }
+    },
+    "required": [
+      "error"
+    ],
+    "type": "object"
+  }
+]
  2. Addedv0.3.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already cover readOnly/idempotent/non-destructive, so credit goes to what is added: muted material is included, loop repeats and trimmed clip boundaries are reflected, and size caps are implied via the schema. 'No focus changes' and the exclusion list are genuinely behavioral context beyond the annotations.

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?

Front-loaded with scope first, then output content, then the optional flag, then exclusions. It is dense and slightly telegraphic in places ('projected stored-MIDI tonal evidence with loop repeats and trimmed boundaries'), but nearly every clause carries distinct information.

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?

With an output schema present, the description needn't explain return shape, and it focuses on scope, exclusions, and the optional harmony mode. What an agent needs to call it correctly is essentially present; only explicit guidance on the fallback tool for excluded material is missing.

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 baseline is 3, but the description still adds meaning: includeHarmony is characterized as literal chord candidates plus gaps and ambiguity, and the evidence is described as projected stored MIDI. It does not add syntax for startBeats/endBeats or trackIds 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?

Opens with a specific verb+resource+scope: 'Read one explicit Arrangement beat window across all or selected ordinary tracks.' It then names its outputs (overlapping clips, projected stored-MIDI tonal evidence) and explicitly contrasts itself against adjacent analyses ('Not playback, a detected key, or a meter/key map'), which separates it from siblings like analyze_midi_parts and get_midi_clip_notes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear inclusion/exclusion rules: includes muted material, excludes audio, drums, recording and large clips, and states that includeHarmony is what unlocks timed pitch sets and chord candidates. It stops short of naming the sibling to use instead when the window is audio or drums, so the agent knows what not to expect but not where to go.

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