Skip to main content
Glama

describe

Read-onlyIdempotent

Inspect any Ableton Live object to reveal its class, properties, children, and permitted methods. For devices, optionally get full parameter details.

Instructions

Introspect any Live object: class, properties, children, and methods.

The route to the dynamic surface: what a loaded plug-in actually exposes, which
no catalog can know in advance because it is decided at runtime and, for
third-party plug-ins, by what the user picked up in Configure mode.

Returns:
    Dictionary with the object class, its properties, its child collections, the
    methods the allowlist permits, and the parameter survey where asked for.

Note:
    Prefer this over lom_describe for a device, and prefer lom_describe for
    anything else. The difference is ``with_parameters``: lom_describe reports a
    device's parameters as a count, and a count is what a Live ``Vector`` that
    refuses ``len()`` fails to give, so a plug-in with parameters can be reported
    as having none. Measured against Live 12.4.5. When that happens this tool
    falls back to probing parameter indices, reports the names it found, and says
    which of the two answers you are looking at.

    Methods are never callable through a path. Take the name from here and invoke
    it through lom_call, which accepts only names on the Remote Script's own
    allowlist. For a device parameter, set it with set_parameter rather than
    writing the path by hand.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYesLOM path to the object to inspect, e.g. 'song', 'song.tracks[0]', 'song.tracks[0].devices[1]'. Path shapes are listed in the live://catalog resource.
depthNoHow far to descend into child collections. Deep descents over a whole set can be slow and the cost is unmeasured, so raise this deliberately rather than by default.
with_parametersNoFor a device path, survey every parameter with its name, value, min, max, quantized steps and display unit, instead of reporting the parameters child as a bare count. This is also what diagnoses an unconfigured third-party plug-in.

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.4
    • changedInput schema / properties / path / description
      Previous value: -"LOM path to the object to inspect, e.g. 'song', 'song.tracks[0]', 'song.tracks[0].devices[1]'. Path shapes are listed in the ableton://catalog resource."New value: +"LOM path to the object to inspect, e.g. 'song', 'song.tracks[0]', 'song.tracks[0].devices[1]'. Path shapes are listed in the live://catalog resource."
  2. Changed3 schema fields changedv0.1.1
    • addedInput schema / properties / depth / description
      Added value: +"How far to descend into child collections. Deep descents over a whole set can be slow and the cost is unmeasured, so raise this deliberately rather than by default."
    • addedInput schema / properties / path / description
      Added value: +"LOM path to the object to inspect, e.g. 'song', 'song.tracks[0]', 'song.tracks[0].devices[1]'. Path shapes are listed in the ableton://catalog resource."
    • addedInput schema / properties / with_parameters / description
      Added value: +"For a device path, survey every parameter with its name, value, min, max, quantized steps and display unit, instead of reporting the parameters child as a bare count. This is also what diagnoses an unconfigured third-party plug-in."
  3. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already mark the tool as read-only, idempotent, and non-destructive, and the description adds significant behavioral nuance beyond that: the dynamic runtime surface, the parameter counting failure in Live Vector, the fallback probing behavior, and the fact that methods are never callable through a path. This gives the agent realistic expectations about edge cases.

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?

The description is longer than typical but well structured into purpose, return summary, usage note, and parameter behavior. Each paragraph earns its place by explaining critical distinctions and fallback behavior. Slightly dense, but the detail is justified for a runtime-introspection tool with surprising edge cases.

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 tool's complexity, the output schema, and 100% schema parameter coverage, the description is complete. It covers what the tool returns, when to use it over its main sibling, what edge cases exist, and how to continue the workflow with lom_call and set_parameter. Nothing essential is missing.

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 value by explaining the behavioral difference of with_parameters, its role in diagnosing unconfigured plug-ins, and the unmeasured cost of deep depth descents. This is more than the schema alone provides, though the path parameter gains little beyond its already thorough schema description.

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 opens with a specific verb and resource: 'Introspect any Live object: class, properties, children, and methods.' It clearly identifies the tool's purpose and differentiates it from its sibling lom_describe by stating when to prefer each, so an agent can distinguish them without opening their schemas.

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 usage: 'Prefer this over lom_describe for a device, and prefer lom_describe for anything else.' It also routes follow-up actions, telling the agent to invoke methods through lom_call and to set device parameters via set_parameter, which goes beyond vague context into concrete decision-making.

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