Skip to main content
Glama

analyze_audio

Read-onlyIdempotent

Measure loudness, true peak, stereo phase, and band balance from Ableton Live tracks or master via LiveMaestro Analyzer, reporting device_not_found if not loaded.

Instructions

Measure the audio itself: loudness, true peak, stereo phase and band balance.

Reads the LiveMaestro Analyzer Max for Live device over loopback OSC; without it this
reports device_not_found with the steps to load it.

- Loudness to EBU R128: momentary 400 ms, short term 3 s, gated integrated since
  reset, range.
- True peak, oversampled, with sample peak, RMS and the crest factor between them.
- Stereo correlation full band and below 120 Hz, and low-end survival of a mono sum.
- Seven band energies on the mono sum, and their weighted centre, not an FFT centroid.

The device reads at its position in the chain, so it belongs last: an effect
after it is not in the reading. A master chain sits before the master fader, so a
master reading matches the output only at 0.0 dB. The two peak figures are maxima
since the last reset and only rise: to measure one, call with
reset=true and no accumulate, let a pass of the material through, then call again.
The averaged figures need no reset. What it proves is what the signal measured
passing the device, not the room.

Every measurement carries the transport state from immediately after it, so a reading
taken mid scene change can be recognised. ``in_transition`` is true while any track
reports fired_slot_index 0 or more, a launch waiting for the next quantization boundary,
and ``session_tracks_playing`` counts tracks whose playing_slot_index is 0 or more
while the transport runs, 0 when stopped. Arrangement playback and audibility are
outside this count. ``tracks_sounding`` is its compatibility alias. Unreadable state
gives ``transport`` null with a code and one sentence in ``transport_unavailable``, or
not_queried when the analyzer did not answer.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
resetNoRestart the integrated loudness and loudness range before measuring, to integrate one section rather than everything since the audio engine started. The reply that performs the reset reports no integrated figure, because it had just begun. It applies to a call with no 'accumulate' at all: an accumulation samples the device on its own schedule, and accumulate='read' reports the windows already counted rather than taking a fresh measurement, so a call that passes both performs no reset.
trackNoWhich analyzer to read: a track name, a zero-based track index, 'master' for the main track, or '*' for whichever instance answers first. Every instance in the set answers every request, and the result lists them all under 'answered'. An index or 'master' costs one extra round trip, because the device reports the name of its track and the index is resolved against the set here.master
window_msNoHow far back the averaged measurements reach, in milliseconds. This governs the averaged figures alone: RMS, both correlations and the seven bands. Loudness keeps its own EBU windows and the peaks are maxima since the last reset. This looks backwards at audio that already played and returns immediately. It does not record for this long. The device buffers a fixed number of samples, so the window this reaches depends on the sample rate: about 2180 ms at 44.1 kHz and 1000 ms at 96 kHz. A longer request is clamped without complaint, so read window_ms back off the result rather than assuming the request was honoured.
accumulateNoAccumulate band occupancy and levels over multiple analysis windows. 'start' begins periodic background sampling; 'read' returns the accumulated occupancy percentages and averaged levels across all sampled windows, together with the span they were taken over; 'reset' stops and clears accumulation. Occupancy is a share of time, so it is reported on 'read' alone: a single call measures one window and reports none.
occupancy_threshold_dbNoThreshold in dB relative to the loudest band in each analysis window. A band is counted as occupied if its level is within this threshold of the loudest band. It takes effect on accumulate='start' alone, because that is where the counting happens: an accumulate='read' reports the threshold its own accumulation was started with, and a single call counts no occupancy at all.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / accumulate
      Added value: +{
      +  "anyOf": [
      +    {
      +      "enum": [
      +        "start",
      +        "read",
      +        "reset"
      +      ],
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Accumulate band occupancy and levels over multiple analysis windows. 'start' begins periodic background sampling; 'read' returns the accumulated occupancy percentages and averaged levels across all sampled windows, together with the span they were taken over; 'reset' stops and clears accumulation. Occupancy is a share of time, so it is reported on 'read' alone: a single call measures one window and reports none.",
      +  "title": "Accumulate"
      +}
    • addedInput schema / properties / occupancy_threshold_db
      Added value: +{
      +  "default": 12,
      +  "description": "Threshold in dB relative to the loudest band in each analysis window. A band is counted as occupied if its level is within this threshold of the loudest band. It takes effect on accumulate='start' alone, because that is where the counting happens: an accumulate='read' reports the threshold its own accumulation was started with, and a single call counts no occupancy at all.",
      +  "title": "Occupancy Threshold Db",
      +  "type": "number"
      +}
    • changedInput schema / properties / reset / description
      Previous value: -"Restart the integrated loudness and loudness range before measuring, to integrate one section rather than everything since the audio engine started. The reply that performs the reset reports no integrated figure, because it had just begun."New value: +"Restart the integrated loudness and loudness range before measuring, to integrate one section rather than everything since the audio engine started. The reply that performs the reset reports no integrated figure, because it had just begun. It applies to a call with no 'accumulate' at all: an accumulation samples the device on its own schedule, and accumulate='read' reports the windows already counted rather than taking a fresh measurement, so a call that passes both performs no reset."
  2. Addedv0.1.1

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already cover read-only/idempotent/non-destructive, yet the description adds substantial behavior beyond them: device_not_found handling and remediation, the last-in-chain read position, the master-fader caveat, peaks being monotonic since reset, and full transport-state reporting semantics. This is rich disclosure the annotations cannot convey.

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-loads the purpose in the first line and uses tight bullets for the measurement list. It is dense and long, with the transport paragraph arguably over-detailed, but nearly every sentence carries actionable constraint information.

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 measurement tool with an output schema, the description covers prerequisites (device loading), call sequencing, caveats, and even output-side semantics like in_transition and session_tracks_playing. An agent has everything needed to invoke and interpret it.

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 the schema already documents all five parameters including cross-parameter interactions (reset vs accumulate, window_ms clamping). The description reinforces reset/window semantics but adds little the schema does not already state, so the baseline 3 is appropriate.

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?

States a specific verb and resource: 'Measure the audio itself: loudness, true peak, stereo phase and band balance.' It goes further by naming the mechanism (LiveMaestro Analyzer Max for Live over loopback OSC) and the exact measurements taken, which clearly separates it from siblings like compare_audio or get_audio_report.

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 strong operational context: the device must sit last in the chain, a master reading only matches output at 0.0 dB, and the reset/accumulate pattern is explained for how to capture a peak. However, it never names or contrasts a sibling tool, so the agent must infer this is the measurement tool versus compare_audio.

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