Skip to main content
Glama

lom_get

Read-onlyIdempotent

Read a single property value from an Ableton Live project using a dotted LOM path rooted at song, app, or song.view, returning its value, type, and optional display string.

Instructions

Read one property value by LOM path, with its catalogued meaning.

The single-property read behind every getter here, for the field no getter
exposes. Where the catalog knows the path, the answer carries a ``catalog``
hint, and where it knows that a particular value is a sentinel it carries
``means`` as well: a ``scene.tempo`` of -1.0 reads back as "no tempo set for
this scene" rather than as a tempo below the legal minimum.

Returns:
    Dictionary with path, value, type, an optional display string for a device
    parameter, and the catalog hint and meaning where those exist.

Note:
    A path that is not rooted at song, app or song.view is refused here without
    Live being contacted. A path Live rejects comes back as ``ok: false`` with
    Live's own ``code``, so a missing property is an error rather than a null.

    Reach for a getter first where one exists: get_session for the whole set,
    get_track, get_clip and get_devices for one of each, read_clip_notes for
    notes, read_automation for envelopes. All of them cost one round trip for
    many fields, where this costs one per field. Use lom_batch to read several
    paths in a single trip, lom_describe when the property names are not known
    yet, and lom_set to write.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYesDotted LOM path rooted at song, app or song.view, with integer subscripts for collections: 'song.tempo', 'song.tracks[0].name', 'song.tracks[0].devices[1].parameters[3].value'. Any other root is refused before Live is contacted.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

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

  1. Changed1 schema field changedv0.1.1
    • addedInput schema / properties / path / description
      Added value: +"Dotted LOM path rooted at song, app or song.view, with integer subscripts for collections: 'song.tempo', 'song.tracks[0].name', 'song.tracks[0].devices[1].parameters[3].value'. Any other root is refused before Live is contacted."
  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?

Beyond the readOnly/idempotent/destructive annotations, the description details error semantics (non-song/app/song.view roots refused before contacting Live, Live-rejected paths return ok:false with Live's code), sentinel handling via the 'means' field, and the shape of the return dictionary. This is valuable behavioral context.

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 compact and well-organized: purpose, return summary, then a note on edge cases and usage. Each paragraph earns its place with no fluff, and the core purpose 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 one-param read tool with strong annotations and a schema, the description covers the practical invocation concerns: path syntax constraints, error responses, catalog meaning, and fallback positioning relative to sibling getters. 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?

The schema covers the path parameter fully (dotted LOM path, allowed roots, integer subscripts, examples), so the high coverage baseline applies. The description adds context about path-root validation and single-property reading but does not introduce new parameter-level requirements.

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 lead sentence is a precise verb+resource statement: 'Read one property value by LOM path' and immediately differentiates the tool as 'the single-property read behind every getter here, for the field no getter exposes.' This clearly distinguishes lom_get from sibling getters.

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 directs agents to prefer a dedicated getter: 'Reach for a getter first where one exists,' and frames lom_get as the fallback for fields no getter exposes. It names get_session as an example, giving concrete routing guidance.

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