Skip to main content
Glama

read_automation

Read-onlyIdempotent

Sample a clip's automation envelope into evenly spaced values to inspect the curve, beat range, value range, and whether automation exists. Read automation data from Session clip parameters for verification.

Instructions

Sample a clip envelope into a list of values and report what it found.

Reads the curve by evaluating it at ``points`` positions, so the answer is a
sampling of the envelope rather than the breakpoints that define it.

Returns:
    Dictionary with the sampled values, the beat range they cover, the value
    range they span, and flags saying whether an envelope exists at all.

Note:
    Automation lives in Session clips, so an Arrangement clip has none to read.
    als_read is the way to see breakpoints in a saved project instead.

    Use write_automation to lay a curve down and clear_automation to remove one.
    A flat result with an envelope flag of false means nothing is automated on
    that parameter, which is not the same as an envelope holding the parameter's
    current value.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
endNoLast beat to sample, clip-local. Omit to sample to the end of the clip.
slotYesClip slot index in track.clip_slots, counted from 0. A slot index is the scene the clip sits in, so slot 2 is the third scene down.
startNoFirst beat to sample, clip-local, where 0 is the clip start. Omit to start just past beat 0, which steps over the guard that keeps a sample off the envelope edge.
trackYesTrack index in song.tracks, counted from 0.
pointsNoHow many evenly spaced samples to take across the range. Clamped to 2..512. This is the resolution of the answer, not of the stored envelope, which keeps whatever breakpoints it was written with.
parameterYesLOM path to the DeviceParameter the envelope belongs to, e.g. 'song.tracks[0].mixer_device.volume' for track volume or 'song.tracks[0].devices[1].parameters[3]' for a device knob.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

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

  1. Changed6 schema fields changedv0.1.1
    • addedInput schema / properties / end / description
      Added value: +"Last beat to sample, clip-local. Omit to sample to the end of the clip."
    • addedInput schema / properties / parameter / description
      Added value: +"LOM path to the DeviceParameter the envelope belongs to, e.g. 'song.tracks[0].mixer_device.volume' for track volume or 'song.tracks[0].devices[1].parameters[3]' for a device knob."
    • addedInput schema / properties / points / description
      Added value: +"How many evenly spaced samples to take across the range. Clamped to 2..512. This is the resolution of the answer, not of the stored envelope, which keeps whatever breakpoints it was written with."
    • addedInput schema / properties / slot / description
      Added value: +"Clip slot index in track.clip_slots, counted from 0. A slot index is the scene the clip sits in, so slot 2 is the third scene down."
    • addedInput schema / properties / start / description
      Added value: +"First beat to sample, clip-local, where 0 is the clip start. Omit to start just past beat 0, which steps over the guard that keeps a sample off the envelope edge."
    • addedInput schema / properties / track / description
      Added value: +"Track index in song.tracks, counted from 0."
  2. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

The description adds substantial behavior beyond the annotations: it evaluates at 'points' positions rather than exposing breakpoints, returns a dictionary with specific contents, and warns that Session-clip automation is invisible in Arrangement clips. This complements the readOnlyHint/idempotentHint annotations without contradicting them.

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 front-loaded with the core action and result, then adds only high-value distinctions and caveats. Each paragraph earns its place: sampling semantics, return contents, session/arrangement contrast, and the false-envelope nuance. Nothing is redundant or padded.

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?

Given the annotations, full schema coverage, and presence of an output schema, the description covers all non-obvious context an agent needs: what the tool returns, how sampling differs from breakpoints, when no envelope exists, and which sibling tools to use instead. It is complete for correct invocation and interpretation.

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 baseline is 3. The description reinforces that 'points' controls sampling resolution and that the answer is a sampling rather than the stored breakpoints, but it does not materially extend the already-detailed per-parameter schema descriptions for start, end, track, slot, or parameter.

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 opening sentence states a precise action and resource: 'Sample a clip envelope into a list of values and report what it found.' It also distinguishes itself from breakpoint-based reading by explicitly saying the result is a sampling, and it names als_read as the alternative for breakpoints, making sibling differentiation clear.

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 explicitly says when not to use it ('an Arrangement clip has none to read'), names the alternative for saved-project breakpoints ('als_read'), and identifies companion mutation tools ('write_automation' and 'clear_automation'). It also clarifies a subtle interpretation trap: a flat result with envelope flag false is not the same as an envelope holding the current value.

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