Skip to main content
Glama
raydollete

TIDAL Music MCP

by raydollete

get_playlist_tracks

Fetches all tracks from a TIDAL playlist by playlist ID, supporting pagination for large playlists.

Instructions

Retrieves tracks from a specified TIDAL playlist with pagination support.

USE THIS TOOL WHENEVER A USER ASKS FOR:
- "Show me the songs in my playlist"
- "What tracks are in my [playlist name] playlist?"
- "List the songs from my playlist"
- "Get tracks from my playlist"
- "View contents of my TIDAL playlist"
- Any request to see what songs/tracks are in a specific playlist

This function retrieves tracks from a specific playlist in the user's TIDAL account.
The playlist_id must be provided, which can be obtained from the get_user_playlists() function.

PAGINATION: For large playlists, use the offset parameter to get additional tracks.
The response includes 'total_available' showing the total tracks in the playlist.
If total_available > track_count, call again with offset incremented by the limit
to get the next batch (e.g., first call offset=0, second call offset=100, etc.)

When processing the results of this tool:
1. Present the playlist information (title, description, track count) as context
2. List the tracks in a clear, organized format with track name, artist, and album
3. Include track durations where available
4. Check total_available vs track_count to know if there are more tracks
5. If there are many tracks, focus on highlighting interesting patterns or variety

Args:
    playlist_id: The TIDAL ID of the playlist to retrieve (required)
    limit: Maximum number of tracks to retrieve per request (default: 100, max: 500)
    offset: Starting index for pagination (default: 0). Use to get additional tracks.

Returns:
    A dictionary containing tracks, track_count (returned), total_available (in playlist), offset, and limit

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
offsetNo
playlist_idYes
Behavior4/5

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

With no annotations provided, the description fully explains pagination behavior, response structure, and the need to check total_available to fetch additional tracks. It does not cover authentication or rate limits, but as a read operation, the provided details are sufficient.

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 well-structured with sections, bullet points, and numbered lists. It is front-loaded with the core purpose but could be slightly more concise, especially the 'When processing the results' section which is useful but somewhat verbose.

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 (pagination, multiple parameters, no output schema), the description is highly complete. It covers prerequisites, pagination mechanics, response fields, and even post-processing steps. It leaves little ambiguity for an AI agent.

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?

The 'Args' section in the description adds meaning beyond the input schema by explaining each parameter's purpose, default values, and constraints (e.g., limit max 500). This compensates for the 0% schema description coverage indicated by context signals.

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 clearly states 'Retrieves tracks from a specified TIDAL playlist with pagination support' and provides extensive examples of user queries that map directly to this tool. It distinguishes itself from siblings like get_favorite_tracks and get_user_playlists by focusing on playlist tracks.

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?

The description explicitly lists when to use the tool with example queries and mentions the prerequisite of obtaining playlist_id from get_user_playlists(). It does not explicitly state when not to use it, but the examples and context provide clear guidance.

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

Install Server

Other Tools

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/raydollete/tidal-dl-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server