Skip to main content
Glama
keenanbb

TIDAL MCP Server

by keenanbb

get_favorite_tracks

Retrieve your liked songs from TIDAL to access saved tracks, manage favorites, or create playlists. Specify a limit to control how many tracks are returned.

Instructions

Get user's favorite (liked) tracks from TIDAL.

Args: limit: Maximum tracks to retrieve (default: 50)

Returns: List of favorite tracks

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
countYesNumber of tracks returned
queryNoSearch query used (for search results)
statusYesOperation status (success/error)
tracksYesList of track objects

Implementation Reference

  • Main handler function for the 'get_favorite_tracks' tool. Fetches user's liked tracks via tidalapi.Session.user.favorites.tracks(), maps to Track models, and returns TrackList. Includes @mcp.tool() decorator for MCP registration and authentication check.
    @mcp.tool()
    async def get_favorite_tracks(limit: int = 50) -> TrackList:
        """
        Get user's favorite (liked) tracks from TIDAL.
    
        Args:
            limit: Maximum tracks to retrieve (default: 50)
    
        Returns:
            List of favorite tracks
        """
        if not await ensure_authenticated():
            raise ToolError("Not authenticated. Please run the 'login' tool first.")
    
        try:
            favorites = await anyio.to_thread.run_sync(
                lambda: session.user.favorites.tracks(limit=limit)
            )
    
            tracks = []
            for track in favorites:
                tracks.append(
                    Track(
                        id=str(track.id),
                        title=track.name,
                        artist=track.artist.name if track.artist else "Unknown Artist",
                        album=track.album.name if track.album else "Unknown Album",
                        duration_seconds=track.duration,
                        url=f"https://tidal.com/browse/track/{track.id}",
                    )
                )
    
            return TrackList(status="success", count=len(tracks), tracks=tracks)
        except Exception as e:
            raise ToolError(f"Failed to get favorites: {str(e)}")
  • Pydantic output schema TrackList returned by get_favorite_tracks, defining structured list of tracks with status, count, and tracks array.
    class TrackList(BaseModel):
        """List of tracks with metadata."""
    
        status: str = Field(description="Operation status (success/error)")
        query: Optional[str] = Field(None, description="Search query used (for search results)")
        count: int = Field(description="Number of tracks returned")
        tracks: List[Track] = Field(description="List of track objects")
  • Pydantic schema Track used in TrackList for individual track details in get_favorite_tracks response.
    class Track(BaseModel):
        """Structured representation of a TIDAL track."""
    
        id: str = Field(description="Unique TIDAL track ID")
        title: str = Field(description="Track title")
        artist: str = Field(description="Primary artist name")
        album: str = Field(description="Album name")
        duration_seconds: int = Field(description="Track duration in seconds")
        url: str = Field(description="TIDAL web URL for the track")
  • Tool description in SERVER_INSTRUCTIONS string, documenting the get_favorite_tracks tool for MCP server instructions.
    - get_favorite_tracks: Get your liked tracks
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions retrieving tracks but lacks details on permissions (e.g., requires user login), rate limits, pagination (only a 'limit' parameter with default), or what happens if no favorites exist. For a read operation with zero annotation coverage, this is a significant gap in transparency.

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 and appropriately sized: a brief purpose statement followed by 'Args' and 'Returns' sections. Each sentence earns its place by adding value, such as specifying the default for 'limit'. It's front-loaded with the core function, though it could be slightly more concise by integrating the default into the purpose statement.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity (1 parameter, no nested objects) and the presence of an output schema (implied by 'Returns: List of favorite tracks'), the description is moderately complete. It covers the basic purpose and parameter semantics but lacks usage guidelines and behavioral details (e.g., authentication needs), which are important for a user-specific tool in a set with authentication siblings like 'login'.

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 description adds meaningful context for the single parameter 'limit': it explains it as 'Maximum tracks to retrieve (default: 50)', which clarifies its purpose beyond the schema's type and default. With 0% schema description coverage and only one parameter, this effectively compensates, providing clear semantics that aid the agent in usage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Get user's favorite (liked) tracks from TIDAL.' It specifies the verb ('Get') and resource ('favorite tracks'), and distinguishes it from siblings like 'get_favorite_albums' or 'get_favorite_artists' by focusing on tracks. However, it doesn't explicitly differentiate from 'add_track_to_favorites' or 'remove_track_from_favorites' in terms of read vs. write operations, which slightly reduces specificity.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to prefer this over other track-retrieval tools like 'get_playlist_tracks' or 'search_tracks', nor does it specify prerequisites (e.g., user authentication via 'login'). This leaves the agent without context for making informed choices among sibling tools.

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

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