Skip to main content
Glama

analyze_audio

Read-onlyIdempotent

Measure loudness, true peak, stereo phase, and band balance on any track to verify mix consistency and catch phase or level issues.

Instructions

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

Reads the LiveMaestro Analyzer Max for Live device over loopback OSC. This
is the only tool that needs that device. Without it every other tool works and
this one reports device_not_found with the steps to load it.

What comes back, and what each figure is:

- Loudness to EBU R128, from Max's loudness~: momentary (400 ms), short term
  (3 s), gated integrated since the last reset, and loudness range.
- True peak, oversampled, so peaks between two samples count. Sample peak and
  RMS beside it, and the crest factor between peak and RMS.
- Stereo correlation over the whole band and below 120 Hz, and whether the low
  end survives being summed to mono.
- Energy in seven bands on the mono sum, plus their energy weighted centre.
  That centre is a centre of mass over seven band levels, not an FFT centroid.

Where it measures matters. The device reads the signal at its own position in
the chain, so it belongs last on the track: an effect loaded after it is not
in what it reports. A master track's device chain sits before the master
fader, so a master reading matches the set's output only while that fader is
at 0.0 dB.

The two peak figures are maxima since the meter was last reset and only rise.
To measure a peak, call once with reset=true, let at least one pass of the
material through, then call again. The averaged figures need no reset.

A read-back proves the stored value and never audibility: this proves what the
signal measured as it passed the device, which is a different and stronger
claim than any parameter value, and still not a claim about the room.

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.
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.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Addedv0.1.1

TDQS

A4.9/5.0
Behavior5/5

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

The description discloses far more than the annotations already provide: device dependency and failure mode, measurement position in the chain, dependence on master fader, peak maxima that only rise, reset semantics, and the important caveat that this proves signal values but never audibility. There is no contradiction with the readOnly/idempotent hints, since reading the analyzer is non-destructive.

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 long but earns its length: dedicated sections for output meaning, measurement position, and reset behavior are front-loaded after a one-sentence purpose. The bulleted list and bold lead-ins make it scannable, and no sentence is padding.

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 measurement tool with three parameters and an output schema, the description covers everything necessary: required device, failure path, return-value semantics, placement caveats, reset workflow, and interpretation limits. The presence of the output schema means the 'what comes back' section is supplementary, not required, but it is still richly provided.

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 the baseline is 3. The description adds meaningful context beyond the schema by explaining how peaks integrate since reset, why reset=true is needed for peak measurement, and how window_ms affects only averaged figures while loudness keeps its own EBU windows. This strengthens the agent's understanding of parameter behavior without merely repeating schema text.

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?

The first line states a specific verb and resource: 'Measure the audio itself' and then enumerates the exact quantities measured (loudness, true peak, stereo phase, band balance). It also names the mechanism (LiveMaestro Analyzer over loopback OSC), which clearly separates it from siblings that read set state such as get_session or lom_get.

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

Usage Guidelines5/5

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

The description gives explicit when-to-use context: it is the only tool requiring the LiveMaestro device, reports device_not_found with loading steps when absent, and every other tool works without it. It also gives a precise procedure for measuring peaks: call with reset=true, let material pass, then call again. This is actionable guidance beyond generalities.

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

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/romanstark/live-maestro'

If you have feedback or need assistance with the MCP directory API, please join our Discord server