Skip to main content
Glama

Get the tracks in a playlist

get_playlist_tracks
Read-onlyIdempotent

Returns the tracks of one Engine DJ playlist in true playlist order, preserving manual drag positions. Identify the playlist by ID or full path/name; missing tracks appear as marked placeholders.

Instructions

The tracks of one playlist, in playlist order -- from the PlaylistEntity.nextEntityId chain, not from row ids, so a track dragged up the list comes back where the DJ put it. Name the playlist with playlist_id, or with playlist_name (exactly one of the two). A name that matches several playlists is refused with every candidate's id and full path rather than picked between -- names are unique only within a folder, so pass the full path from get_playlists to disambiguate. Each row carries position, its 1-based place in the playlist. An entry whose track is not in this library comes back as { position, entry_id, track_id, missing: true } and keeps its slot, so entry_count still matches the playlist's own length; missing_count says how many of those there are. That is ordinary, not corruption -- entries outlive their tracks and arrive from other drives (see audit_library's orphan_entries). Same fields, limit and cursor conventions as search_tracks. With more than one library connected, pass library (a uuid or path from list_libraries, either the ~/... form or the absolute one) to choose which one; the default is the supported library with the most tracks.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
cursorNo
fieldsNo
libraryNoWhich library to use: either the uuid or the path reported by list_libraries (the reported ~/... form is accepted, as is the absolute path). Omit it to use the supported library holding the most tracks. A READ may always omit it. A WRITE may omit it only when a single supported library is connected: with two or more, a write refuses with ambiguous_library listing them, since the choice decides which disk changes; ask the user which, then pass it here. A library copied onto another drive keeps its uuid, so a uuid can name two connected libraries: a write naming such a uuid refuses with ambiguous_library as well. Pass the path to write to one of them.
playlist_idNo
redact_pathsNo
playlist_nameNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.17.2

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already mark this as read-only and idempotent, and the description adds substantial behavioral detail: missing tracks come back as { position, entry_id, track_id, missing: true }, keep their slot, and are counted by missing_count. It also explicitly declares the missing state ordinary rather than corruption, which is valuable context beyond the structured hints.

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 dense and every clause earns its place, front-loading the core purpose before edge cases. It is one long paragraph rather than structured bullets, but the flow from selection to result shape to library rule is logical.

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?

There is no output schema, yet the description covers the row shape, ordering semantics, missing-entry behavior, count invariants, and library disambiguation well enough for an agent to call this correctly. It even points to audit_library's orphan_entries for broader context about missing tracks.

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?

With only 14% schema coverage, the description does the heavy lifting: it explains playlist_id vs playlist_name mutual exclusion, ambiguity behavior, path-based disambiguation, library selection, and the 1-based position meaning. The only clear gap is redact_paths, whose effect is never described, and fields/limit/cursor are delegated to search_tracks rather than fully explained.

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 opening sentence defines a precise operation: retrieve the tracks of a single playlist in playlist order. It further distinguishes the result from plain row-id ordering and ties it to the PlaylistEntity.nextEntityId chain, so there is no ambiguity about what the tool returns.

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?

It explicitly states the two ways to name a playlist, requires exactly one, and explains how ambiguous names are refused. It also gives a library-selection rule with a default and references get_playlists and search_tracks as sources for disambiguation and conventions.

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