Live Maestro

Overview Schema Source Related Servers Discussions Admin

get_devices

Read-onlyIdempotent

List a track's device chain details—names, class names, on/off state, parameter counts—to prepare for parameter adjustments or device moves. Read-only inspection.

Instructions

List a track's device chain: names, class names, on/off, parameter counts.

Reads the chain and changes nothing in it. The device indices it reports are the
ones set_parameter, delete_device and ``song.move_device`` are addressed by.

Returns:
    Dictionary with the device count and one entry per device carrying its index,
    name, class name, on/off state, parameter count and ``configure_needed`` flag.
    A track with an empty chain answers ``device_count: 0`` rather than an error,
    while an index with no track behind it is refused with ``index_out_of_range``.

Note:
    Read the parameter count first. A third-party plug-in reporting exactly one
    parameter has not been configured, which the ``configure_needed`` flag says
    outright. That is a limit in Live, not in this server, and only Live's GUI
    lifts it. The probe behind that flag settles one question, whether the count
    is exactly one or more than one, so where it could not settle it the count
    arrives as ``parameter_count_at_least`` instead.

    For the parameters themselves, with their ranges and display units, call
    ``describe`` with ``with_parameters=True``: this tool counts them and does
    not list them. For the mixer, sends and clip slots on the same track, call
    get_track instead of adding a second call here.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`kind`	No	Which collection the track index counts in: 'track' for song.tracks, 'return' for song.return_tracks, 'master' for the master track, where the track index is ignored.	track
`track`	Yes	Track index in song.tracks, counted from 0.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv0.1.1Sep 7, 2026

addedInput schema / properties / kind / description

Added value: +"Which collection the track index counts in: 'track' for song.tracks, 'return' for song.return_tracks, 'master' for the master track, where the track index is ignored."

addedInput schema / properties / kind / enum

Added value: +[
+  "track",
+  "return",
+  "master"
+]

addedInput schema / properties / track / description

Added value: +"Track index in song.tracks, counted from 0."

First observedv0.1.0Sep 5, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the readOnlyHint and idempotentHint annotations, the description states it 'changes nothing', discloses edge cases (empty chain returns device_count: 0, invalid index returns index_out_of_range), and explains the configure_needed flag and parameter_count_at_least fallback. This gives an agent a reliable model of side effects and failure behavior.

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 front-loaded with the core purpose in one sentence and then organized into Returns and Note sections. It is somewhat verbose, especially the paragraph about the configure_needed probe, but every sentence carries useful information and the structure makes it scannable.

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?

With an output schema present and 100% input schema coverage, the description still adds necessary context: edge cases, error behavior, relationships to other tools, and a Live-specific limitation. An agent has everything needed to call this tool correctly and interpret its results.

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 coverage is 100%, so the schema already documents both parameters and their meaning. The description adds the behavioral note about invalid track indices but does not significantly enrich the semantics of the kind or track fields beyond what the schema provides, so the baseline 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 first sentence names the exact verb ('List'), resource ('a track's device chain'), and content ('names, class names, on/off, parameter counts'). It also distinguishes itself from siblings by pointing to describe for parameters and get_track for mixer/sends/clip slots, so an agent can tell it apart immediately.

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 to call describe instead ('this tool counts them and does not list them') and when to call get_track ('For the mixer, sends and clip slots on the same track'). It also tells the agent to read the parameter count first and warns about the configuration edge case, giving clear operational guidance.

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