Skip to main content
Glama
ibeal
by ibeal

recommend_tracks

Get personalized music recommendations based on your TIDAL favorite tracks or specific track IDs. Filter suggestions by criteria like mood or style to find tracks that match your taste.

Instructions

Recommends music tracks based on specified track IDs or can use the user's TIDAL favorites if no IDs are provided.

USE THIS TOOL WHENEVER A USER ASKS FOR:
- Music recommendations
- Track suggestions
- Music similar to their TIDAL favorites or specific tracks
- "What should I listen to?"
- Any request to recommend songs/tracks/music based on their TIDAL history or specific tracks

This function gets recommendations based on provided track IDs or retrieves the user's
favorite tracks as seeds if no IDs are specified.

When processing the results of this tool:
1. Analyze the seed tracks to understand the music taste or direction
2. Review the recommended tracks from TIDAL
3. IMPORTANT: Do NOT include any tracks from the seed tracks in your recommendations
4. Ensure there are NO DUPLICATES in your recommended tracks list
5. Select and rank the most appropriate tracks based on the seed tracks and filter criteria
6. Group recommendations by similar styles, artists, or moods with descriptive headings
7. For each recommended track, provide:
   - The track name, artist, album
   - Always include the track's URL to make it easy for users to listen to the track
   - A brief explanation of why this track might appeal to the user based on the seed tracks
   - If applicable, how this track matches their specific filter criteria
8. Format your response as a nicely presented list of recommendations with helpful context (remember to include the track's URL!)
9. Begin with a brief introduction explaining your selection strategy
10. Lastly, unless specified otherwise, you should recommend MINIMUM 20 tracks (or more if possible) to give the user a good variety to choose from.

[IMPORTANT NOTE] If you're not familiar with any artists or tracks mentioned, you should use internet search capabilities if available to provide more accurate information.

Args:
    track_ids: Optional list of TIDAL track IDs to use as seeds for recommendations.
              If not provided, will use the user's favorite tracks.
    filter_criteria: Specific preferences for filtering recommendations (e.g., "relaxing music,"
                     "recent releases," "upbeat," "jazz influences")
    limit_per_track: Maximum number of recommendations to get per track (NOTE: default: 20, unless specified otherwise, we'd like to keep the default large enough to have enough candidates to work with)
    limit_from_favorite: Maximum number of favorite tracks to use as seeds (NOTE: default: 20, unless specified otherwise, we'd like to keep the default large enough to have enough candidates to work with)

Returns:
    A dictionary containing both the seed tracks and recommended tracks

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
track_idsNo
filter_criteriaNo
limit_per_trackNo
limit_from_favoriteNo
Install Server

TDQS

A4.6/5.0
Behavior4/5

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

No annotations are provided, so the description carries the disclosure burden. It explains the fallback to user favorites, warns against including seed tracks, disallows duplicates, and states the return type. It could also mention authentication requirements or read-only behavior explicitly, but the main behavioral traits are well covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with usage triggers and has a clear section layout, but it is noticeably verbose. The opening and the third paragraph restate the same seed behavior, the URL reminder appears more than once, and the 10-step output protocol is extensive. Most content is useful, but some sentences are redundant.

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 there is no output schema, the description still gives enough context: return shape is a dictionary with seed and recommended tracks, parameter behavior is explained, seed exclusion and duplicate rules are stated, and response formatting expectations are specified. The tool is complex, but the description covers the necessary invocation and result-handling guidance.

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 is the only source of parameter meaning. It fully documents all four parameters: track_ids as optional seeds, filter_criteria as preferences, and both limit parameters with their defaults and the intent to keep defaults large. This is a strong compensation for the bare schema.

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: 'Recommends music tracks based on specified track IDs or can use the user's TIDAL favorites.' It also provides concrete trigger examples and clearly distinguishes this tool from siblings like get_favorite_tracks and search_tracks by focusing on recommendations rather than retrieval or search.

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 states 'USE THIS TOOL WHENEVER A USER ASKS FOR' followed by a list of request types, including 'What should I listen to?' and track/music suggestions. It also explains the fallback behavior when no track IDs are provided, giving the agent clear conditions for invocation.

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

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

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