Skip to main content
Glama
Cifero74

mcp-apple-music

by Cifero74
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

get_playlist_tracks

Retrieve every track in an Apple Music library or catalog playlist, with pagination support to page through playlists and automatic full fetching for large collections.

Instructions

Get the tracks inside a playlist: one of the user's own playlists, or an Apple Music catalog playlist (editorial, themed, curator playlists).

Apple Music returns at most 100 tracks per request. Use offset to page through a large playlist, or set fetch_all=True to automatically fetch every page (up to max_tracks).

Args: playlist_id: Library playlist ID (starts with 'p.', from get_library_playlists) or catalog playlist ID (starts with 'pl.', from search_catalog or get_recommendations). limit: Maximum tracks to return for a single page, 1–100 (default 100). Ignored when fetch_all is True (always uses page size 100). offset: Pagination offset for single-page requests (default 0). Ignored when fetch_all is True. fetch_all: If True, follow pagination and return every track in the playlist (up to max_tracks). Default False. max_tracks: Safety cap when fetch_all is True, 1–5000 (default 2000).

Input Schema

NameRequiredDescriptionDefault
limitNo
offsetNo
fetch_allNo
max_tracksNo
playlist_idYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.3.0
    • addedInput schema / properties / fetch_all
      Added value: +{
+  "default": false,
+  "title": "Fetch All",
+  "type": "boolean"
+}
    • addedInput schema / properties / max_tracks
      Added value: +{
+  "default": 2000,
+  "title": "Max Tracks",
+  "type": "integer"
+}
    • addedInput schema / properties / offset
      Added value: +{
+  "default": 0,
+  "title": "Offset",
+  "type": "integer"
+}
  2. First observedv0.1.0

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations, the description carries the full load and does it well: it discloses Apple Music's 100-track-per-request ceiling, the paging semantics, the default page size, and the max_tracks cap that bounds fetch_all. It does not mention auth requirements, rate limiting, or error behavior for invalid IDs, which keeps it out of the top band.

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?

Front-loaded summary followed by a structured Args block, with no wasted preamble. Minor redundancy: the 'ignored when fetch_all is True' rule is repeated for both limit and offset, and the paging constraint is stated twice (prose and args).

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?

Covers both playlist sources, pagination in both modes, defaults, hard limits, and parameter interactions; since an output schema exists, return-value shape need not be described. An agent has everything required to call this correctly on the first attempt.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate entirely, and it does: every one of the five parameters gets a meaning, accepted range, default, and in several cases an interaction rule ('Ignored when fetch_all is True'). The playlist_id prefixes are explained with the sibling tool each comes from.

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?

Opens with a specific verb+resource ('Get the tracks inside a playlist') and immediately narrows scope to two distinct playlist classes (library 'p.' vs catalog 'pl.'), which an agent cannot infer from the name alone. It also names the sibling tools that produce each ID type, tying the tool into the surrounding toolset.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly describes the two usage modes: single-page requests via offset/limit versus automatic full retrieval via fetch_all, including the max_tracks safety cap. It stops short of saying when to prefer this over alternatives like search_library or get_library_songs, but the mode selection guidance is clear and actionable.

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

Deploy Server

Other Tools