Skip to main content
Glama

create_track

Insert a MIDI, audio, or return track into an Ableton Live set and get its resolved track index. Specify kind, name, and position; use -1 to append without shifting existing tracks.

Instructions

Insert a MIDI, audio, or return track and return its resolved index.

Returns:
    Dictionary with the resolved index of the new track, its kind and name, and
    the track count before and after.

Note:
    Inserting at index N shifts the track that was at N, and every track after it, up
    by one. Every track index held from before the call is then wrong, including ones
    in a plan not yet executed. Append with -1 where the position does not matter, and
    otherwise take the resolved index out of this answer rather than assuming it.

    Creating a track does not put an instrument on it. Select it and call
    load_device for that, then create_clip for something to play.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kindNoWhat to create: 'midi' for a MIDI track, 'audio' for an audio track, 'return' for a send return. A return track is appended to song.return_tracks and cannot be named or positioned here.midi
nameNoName for the new MIDI or audio track. Empty leaves Live to name it, which produces a default like '3-MIDI'.
indexNoWhere to insert it in song.tracks. -1 appends at the end, which is the only value that leaves existing track indices alone. Ignored for a return track.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

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

  1. Changed4 schema fields changedv0.1.1
    • addedInput schema / properties / index / description
      Added value: +"Where to insert it in song.tracks. -1 appends at the end, which is the only value that leaves existing track indices alone. Ignored for a return track."
    • addedInput schema / properties / kind / description
      Added value: +"What to create: 'midi' for a MIDI track, 'audio' for an audio track, 'return' for a send return. A return track is appended to song.return_tracks and cannot be named or positioned here."
    • addedInput schema / properties / kind / enum
      Added value: +[
      +  "midi",
      +  "audio",
      +  "return"
      +]
    • addedInput schema / properties / name / description
      Added value: +"Name for the new MIDI or audio track. Empty leaves Live to name it, which produces a default like '3-MIDI'."
  2. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the annotations (which only indicate non-read-only, non-idempotent, etc.), the description discloses the important side effect of index shifting and the fact that previously held track indices become invalid. It also clarifies that no instrument is added and that return tracks are appended and cannot be named/positioned. This is rich, honest 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 concise yet substantive. The one-line summary is followed by a Return section and a Note section, both front-loaded with the most operationally important warnings. Every sentence adds necessary information; there is no filler or repetition of schema details.

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 100% schema coverage, and the presence of an output schema, the description is complete. It explains the return dictionary contents, the critical index-shifting behavior, and the necessary follow-up steps. An agent has everything needed to invoke and interpret the result correctly.

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 value beyond the schema by clarifying the semantic implications of index values ('Append with -1... only value that leaves existing track indices alone'), reinforcing that the resolved index from the response should be used, and noting the return-track limitation of name/index. This surpasses baseline without fully re-explaining each 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 description opens with a specific verb and resource: 'Insert a MIDI, audio, or return track and return its resolved index.' It names the three track kinds and the tool's key output, making it easy to distinguish from sibling tools like create_clip or delete_track. The core purpose is unambiguous and not a tautology.

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 explains when to append with -1 versus take a resolved index, and warns that inserting at N shifts existing indices. It also gives a clear follow-up workflow: 'Select it and call load_device for that, then create_clip for something to play,' naming specific alternatives and sequencing. This is strong guidance for an agent deciding how to use the tool.

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