Skip to main content
Glama

get_liked_tracks

Retrieve your saved Spotify tracks to access your music library, create playlists, analyze preferences, or export favorites with timestamps and details.

Instructions

Access the user's personal collection of liked/saved tracks from their Spotify library.

🎯 USE CASES: • Display user's favorite music collection in applications • Create personalized playlists from liked songs • Analyze personal music taste and preferences • Build recommendation systems based on user favorites • Export personal music library for backup or migration

📝 WHAT IT RETURNS: • Complete collection of user's liked/saved tracks • Track information with save dates and timestamps • Artist, album, and release information for each track • Chronological order of when tracks were liked • Total count of saved tracks in library

🔍 EXAMPLES: • "Show me my liked songs collection" • "Get my 50 most recently liked tracks" • "What songs have I saved to my library?" • "Export my favorite tracks with save dates"

💖 PERSONAL COLLECTION: • Reflects user's musical taste and preferences • Shows evolution of music taste over time • Perfect for building "greatest hits" playlists • Useful for music discovery based on preferences • Great for sharing favorite music with friends

💡 COLLECTION INSIGHTS: • Track when musical tastes changed or evolved • Identify patterns in saved music genres • Use for personalized recommendation systems • Perfect for "throwback" and nostalgia playlists • Analyze your music journey over time

⚠️ REQUIREMENTS: • Valid Spotify access token with user-library-read scope • User must have saved tracks in their library

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tokenYesSpotify access token for authentication
limitNo
offsetNo

Implementation Reference

  • The MCP tool handler function for 'get_liked_tracks' that extracts arguments and delegates to SpotifyService.getLikedTracks.
    handler: async (args: any, spotifyService: SpotifyService) => {
      const { token, limit = 20, offset = 0 } = args;
      return await spotifyService.getLikedTracks(token, limit, offset);
    },
  • Zod schema definition for input validation of the 'get_liked_tracks' tool parameters (token, limit, offset).
    schema: createSchema({
      token: commonSchemas.token(),
      limit: commonSchemas.limit(1, 50, 20),
      offset: commonSchemas.offset(),
    }),
  • SpotifyService helper method that makes the API call to Spotify's /me/tracks endpoint to retrieve user's liked/saved tracks.
    async getLikedTracks(
      token: string,
      limit: number = 20,
      offset: number = 0
    ): Promise<PagingObject<{ added_at: string; track: SpotifyTrack }>> {
      const params = {
        limit: Math.min(limit, 50),
        offset: offset,
      };
      return await this.makeRequest<
        PagingObject<{ added_at: string; track: SpotifyTrack }>
      >("me/tracks", token, params);
    }
  • Registration of trackTools (including get_liked_tracks) into the allTools registry used by ToolRegistrar.
    ...trackTools,
  • Instantiation of ToolRegistrar which loads all tools including get_liked_tracks for MCP server.
    const toolRegistrar = new ToolRegistrar(spotifyService);
Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does well by specifying authentication requirements ('Valid Spotify access token with user-library-read scope'), data scope ('Complete collection of user's liked/saved tracks'), return format details ('Track information with save dates and timestamps'), and ordering ('Chronological order of when tracks were liked'). It doesn't mention rate limits or pagination behavior, but covers most essential behavioral aspects for a read operation.

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

Conciseness2/5

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

The description is overly verbose with multiple sections (USE CASES, WHAT IT RETURNS, EXAMPLES, PERSONAL COLLECTION, COLLECTION INSIGHTS, REQUIREMENTS) that contain repetitive information. Many sentences don't earn their place - for instance, the 'PERSONAL COLLECTION' and 'COLLECTION INSIGHTS' sections provide motivational context rather than operational guidance. The core purpose could be communicated in 2-3 sentences instead of this lengthy format.

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?

For a read operation with 3 parameters (one undocumented), no annotations, and no output schema, the description provides good coverage of authentication, return data, and use cases. However, it lacks details about pagination behavior (how limit/offset work with the 'Complete collection' claim), error conditions, and exact response structure. The motivational content ('Perfect for building greatest hits playlists') doesn't compensate for these operational gaps.

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

Parameters3/5

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

With schema description coverage at only 33% (only the 'token' parameter has a description), the description doesn't compensate by explaining the 'limit' and 'offset' parameters. While it mentions 'Complete collection' and 'Total count,' it doesn't clarify how limit/offset affect pagination. The description adds value about what data is returned but doesn't enhance understanding of the undocumented input parameters beyond what's implied in examples like 'Get my 50 most recently liked tracks.'

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 the tool's purpose: 'Access the user's personal collection of liked/saved tracks from their Spotify library.' This is a specific verb ('access') + resource ('liked/saved tracks') combination that distinguishes it from siblings like get_playlist_tracks or get_recently_played. The description explicitly focuses on the user's personal library rather than public content.

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 provides clear context about when to use this tool through the 'USE CASES' section (e.g., 'Display user's favorite music collection,' 'Create personalized playlists from liked songs'). However, it doesn't explicitly state when NOT to use it or mention specific alternatives among the sibling tools (like get_recently_played for recent activity or get_top_tracks for algorithmic favorites). The 'REQUIREMENTS' section adds important prerequisites but not comparative 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/latiftplgu/Spotify-OAuth-MCP-server'

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