Skip to main content
Glama

get_session

Read-onlyIdempotent

Survey the running Ableton set in one call: verify the Remote Script is responding and retrieve song fields, track and scene indices, clips, and device chains to guide later targeted edits.

Instructions

Survey the running set: script handshake, song fields, tracks, clips, devices.

The call to make first. It proves the Remote Script is answering before anything
else is attempted, and it hands back the track and scene indices every other
tool here is addressed by.

Returns:
    Dictionary with script handshake info, song fields, the track list with its
    indices, group track indices, and clip and device detail where asked for.

Note:
    The round-trip handshake takes about 450 ms, so this is the expensive read. Take
    it once at the start and narrow with get_track, get_clip and get_devices
    afterwards rather than calling this again between edits. Group tracks have no arm
    state ('armed' returns null). If Live collection introspection reports zero
    tracks, index probing is used as a fallback.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
clipsNoSweep the Session grid for slots that hold a clip. Off, the answer covers tracks and devices but says nothing about clips, and comes back faster because no slots are probed.
devicesNoInclude each track device chain in the answer.
max_scenesNoHow many scenes deep to probe for Session clips. A cap rather than a count: Live collections report no length, so the sweep stops here instead of at the last scene. Ignored when clips is false.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

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

  1. Changed3 schema fields changedv0.1.1
    • addedInput schema / properties / clips / description
      Added value: +"Sweep the Session grid for slots that hold a clip. Off, the answer covers tracks and devices but says nothing about clips, and comes back faster because no slots are probed."
    • addedInput schema / properties / devices / description
      Added value: +"Include each track device chain in the answer."
    • addedInput schema / properties / max_scenes / description
      Added value: +"How many scenes deep to probe for Session clips. A cap rather than a count: Live collections report no length, so the sweep stops here instead of at the last scene. Ignored when clips is false."
  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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description goes well beyond this by revealing the 450 ms round-trip cost, the group track 'armed' null quirk, and the index-probing fallback when zero tracks are reported. These are non-obvious behavioral traits that materially affect invocation decisions.

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 efficiently structured: a one-line purpose, a short invocation-placement paragraph, a return summary, and a note consolidating the most important behavioral caveats. Every sentence adds operational value, and the most critical 'call first' guidance is front-loaded.

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 read-only session-survey tool with an output schema and rich schema-level parameter descriptions, the description covers everything an agent needs: when to call it, why it is expensive, what it returns at a high level, how to narrow afterwards, and two important quirks (group track arm state and zero-track fallback). Nothing essential is missing.

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%, and each parameter already has a rich description explaining its effect, defaults, and edge cases (e.g., max_scenes is a cap not a count). The tool description adds contextual linkage ('clip and device detail where asked for') but does not need to restate parameter meanings, so the baseline of 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?

The description names a specific verb ('Survey'), a specific resource (the running set), and enumerates the content: script handshake, song fields, tracks, clips, and devices. It also explicitly positions itself as the first call and distinguishes itself from get_track, get_clip, and get_devices, 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 gives explicit when-to-use guidance: 'The call to make first' and explains why, then directs the agent to 'Take it once at the start and narrow with get_track, get_clip and get_devices afterwards rather than calling this again between edits.' It also notes when the clips parameter can be disabled for speed, giving practical selection context.

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