ableton-mcp

Overview Schema Source Related Servers Discussions Admin

compare_audio_reference

Read-onlyIdempotent

Measure LUFS, true peak, and loudness range differences between equal 3–60-second local mix and reference windows; return attenuation-only level-match proposals.

Instructions

Compare equal 3–60-second local mono/stereo mix and reference windows for LUFS, true peak and loudness range. Binds both files with identity and SHA-256 before/after measurement; maximum 512 MiB each. Returns mix-minus-reference differences and attenuation-only level-match proposals. Read-only: no playback, normalization, mix edits, tonal or quality judgment. All profile; ffmpeg/ffprobe required.

Input Schema

Name	Required	Description
`mixPath`	Yes	Absolute local rendered mix or verified capture file.
`referencePath`	Yes	Absolute local reference audio file.
`durationSeconds`	No	Shared window duration, 3–60 seconds; defaults to 10. Both sources must contain the full window.
`mixStartSeconds`	No	Mix window start in source-file seconds; default zero.
`referenceStartSeconds`	No	Reference window start in source-file seconds; default zero.

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: +[
+  {
+    "properties": {
+      "levelMatch": {
+        "properties": {
+          "applied": {
+            "const": false
+          },
+          "available": {
+            "type": "boolean"
+          }
+        },
+        "required": [
+          "available",
+          "applied"
+        ],
+        "type": "object"
+      },
+      "limitation": {
+        "type": "string"
+      },
+      "mix": {
+        "type": "object"
+      },
+      "mixMinusReference": {
+        "properties": {
+          "integratedLufs": {
+            "anyOf": [
+              {
+                "type": "number"
+              },
+              {
+                "type": "null"
+              }
+            ]
+          },
+          "loudnessRangeLu": {
+            "anyOf": [
+              {
+                "type": "number"
+              },
+              {
+                "type": "null"
+              }
+            ]
+          },
+          "truePeakDbtp": {
+            "anyOf": [
+              {
+                "type": "number"
+              },
+              {
+                "type": "null"
+              }
+            ]
+          }
+        },
+        "required": [
+          "integratedLufs",
+          "truePeakDbtp",
+          "loudnessRangeLu"
+        ],
+        "type": "object"
+      },
+      "reference": {
+        "type": "object"
+      },
+      "scope": {
+        "const": "source_audio_windows"
+      }
+    },
+    "required": [
+      "scope",
+      "mix",
+      "reference",
+      "mixMinusReference",
+      "levelMatch",
+      "limitation"
+    ],
+    "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.2/5.0

Behavior5/5

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

Adds substantial behavior beyond annotations: SHA-256 identity binding before and after measurement, 512 MiB per-file limit, attenuation-only level-match proposals, and explicit exclusions for playback, normalization, mix edits, and quality judgment. These details are consistent with the read-only, idempotent, non-destructive annotations.

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

Conciseness5/5

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

The description is dense but front-loaded and well organized: purpose first, then binding/limits, outputs, read-only scope, and environment requirement. Every sentence contributes operational information, with only minor terseness in phrases like 'All profile'.

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?

For a complex audio-analysis tool with an output schema and rich annotations, the description supplies the remaining operational context: file locality, duration range, size cap, measurement metrics, output behavior, safety boundaries, and ffmpeg/ffprobe dependency. An agent has enough information to decide whether it can invoke the tool correctly.

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 already 100%, so the schema carries most parameter meaning. The description still adds useful semantics such as local mono/stereo sources, equal comparison windows, and a maximum file size, though it does not add per-parameter detail for the start-offset parameters.

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 and resource: compare a mix window against a reference window for LUFS, true peak, and loudness range. The operation is clearly distinct from single-file analysis tools, but the description does not explicitly name sibling tools or state how it differs from them.

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?

Provides useful constraints and exclusions such as equal 3–60-second windows, local files, read-only behavior, and no tonal or quality judgment. However, it does not explicitly say when to choose this over alternatives like analyze_audio_file or analyze_audio_clip, so routing guidance is only implied.

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

Deploy Server