Skip to main content
Glama

save_tracks

Add tracks to your Spotify library to create a permanent collection of favorite music for future listening and offline access.

Instructions

Add tracks to the user's personal library, creating a permanent collection of favorite music.

🎯 USE CASES: • Save discovered tracks for future listening • Build personal music library from recommendations • Like tracks during music discovery sessions • Create permanent collections of favorite songs • Save music for offline listening and easy access

📝 WHAT IT RETURNS: • Confirmation of successful track saves • Updated library count and collection size • Timestamp information for when tracks were saved • Error details for tracks that couldn't be saved • Success status for bulk save operations

🔍 EXAMPLES: • "Save 'Bohemian Rhapsody' to my library" • "Add these 5 discovered tracks to my liked songs" • "Save track IDs: 4uLU6hMCjMI75M1A2tKUQC, 7qiZfU4dY1lWllzX7mkmht" • "Like all tracks from this great album"

💖 BUILDING YOUR COLLECTION: • Creates permanent access to favorite music • Tracks appear in your "Liked Songs" playlist • Enables offline playback for saved content • Perfect for building personalized music libraries • Essential for music discovery and curation

💡 COLLECTION STRATEGIES: • Save tracks immediately during discovery • Build thematic collections of related music • Use bulk saves for efficiency with multiple tracks • Regular saving helps track music evolution • Create personal "greatest hits" collections

⚠️ REQUIREMENTS: • Valid Spotify access token with user-library-modify scope • Tracks must be available in user's market • Maximum 50 tracks can be saved per request

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tokenYesSpotify access token for authentication
trackIdsYesArray of Spotify track IDs to save

Implementation Reference

  • Core implementation of the saveTracks function in SpotifyService. Extracts track IDs, formats them, and makes a PUT request to Spotify API endpoint /me/tracks to save tracks to user's library.
    async saveTracks(token: string, trackIds: string | string[]): Promise<void> {
      const ids = Array.isArray(trackIds)
        ? trackIds.map((id) => this.extractId(id))
        : [this.extractId(trackIds)];
      const params = { ids: ids.join(",") };
      return await this.makeRequest<void>("me/tracks", token, params, "PUT");
    }
  • The MCP tool handler for 'save_tracks' that validates arguments and delegates execution to the SpotifyService.saveTracks method.
    handler: async (args: any, spotifyService: SpotifyService) => {
      const { token, trackIds } = args;
      return await spotifyService.saveTracks(token, trackIds);
    },
  • Zod-based input schema definition for the 'save_tracks' tool, requiring a Spotify token and an array of track IDs.
    schema: createSchema({
      token: commonSchemas.token(),
      trackIds: z
        .array(z.string())
        .describe("Array of Spotify track IDs to save"),
    }),
  • Complete registration of the 'save_tracks' tool as part of the trackTools object, including title, detailed description, schema, and handler reference.
      save_tracks: {
        title: "Save Tracks to Library",
        description: `Add tracks to the user's personal library, creating a permanent collection of favorite music.
    
    🎯 USE CASES:
    • Save discovered tracks for future listening
    • Build personal music library from recommendations
    • Like tracks during music discovery sessions
    • Create permanent collections of favorite songs
    • Save music for offline listening and easy access
    
    📝 WHAT IT RETURNS:
    • Confirmation of successful track saves
    • Updated library count and collection size
    • Timestamp information for when tracks were saved
    • Error details for tracks that couldn't be saved
    • Success status for bulk save operations
    
    🔍 EXAMPLES:
    • "Save 'Bohemian Rhapsody' to my library"
    • "Add these 5 discovered tracks to my liked songs"
    • "Save track IDs: 4uLU6hMCjMI75M1A2tKUQC, 7qiZfU4dY1lWllzX7mkmht"
    • "Like all tracks from this great album"
    
    💖 BUILDING YOUR COLLECTION:
    • Creates permanent access to favorite music
    • Tracks appear in your "Liked Songs" playlist
    • Enables offline playback for saved content
    • Perfect for building personalized music libraries
    • Essential for music discovery and curation
    
    💡 COLLECTION STRATEGIES:
    • Save tracks immediately during discovery
    • Build thematic collections of related music
    • Use bulk saves for efficiency with multiple tracks
    • Regular saving helps track music evolution
    • Create personal "greatest hits" collections
    
    ⚠️ REQUIREMENTS:
    • Valid Spotify access token with user-library-modify scope
    • Tracks must be available in user's market
    • Maximum 50 tracks can be saved per request`,
        schema: createSchema({
          token: commonSchemas.token(),
          trackIds: z
            .array(z.string())
            .describe("Array of Spotify track IDs to save"),
        }),
        handler: async (args: any, spotifyService: SpotifyService) => {
          const { token, trackIds } = args;
          return await spotifyService.saveTracks(token, trackIds);
        },
      },
  • Registration of trackTools (including save_tracks) into the central allTools registry used by ToolRegistrar for MCP tool definitions.
    ...trackTools,
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 effectively describes key behaviors: it's a write operation ('adds', 'creates permanent'), has authentication requirements ('Spotify access token'), includes rate limits ('maximum 50 tracks per request'), and explains outcomes ('tracks appear in Liked Songs', 'enables offline playback'). It doesn't mention error handling specifics or idempotency, but covers most critical aspects.

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 well-structured with clear sections (USE CASES, WHAT IT RETURNS, etc.), but is overly verbose. Several sections like 'BUILDING YOUR COLLECTION' and 'COLLECTION STRATEGIES' contain redundant motivational content that doesn't add essential operational information. The core functionality could be communicated in half the length without losing value.

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

Completeness4/5

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

For a write operation with no annotations and no output schema, the description provides substantial context: clear purpose, usage scenarios, return information, examples, requirements, and limitations. It covers authentication, market restrictions, and rate limits. The main gap is the lack of output schema, but the 'WHAT IT RETURNS' section partially compensates by describing expected responses.

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?

Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description adds minimal parameter-specific information beyond what's in the schema - it mentions 'track IDs' in examples and 'Spotify access token' in requirements, but doesn't provide additional syntax, format details, or constraints. This meets the baseline for high schema coverage.

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 with specific verbs ('add tracks', 'save tracks') and resources ('user's personal library', 'permanent collection'). It distinguishes from siblings like 'add_to_playlist' (which adds to playlists, not the library) and 'get_liked_tracks' (which retrieves, not saves). The title 'save_tracks' aligns perfectly with the described functionality.

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 usage contexts through 'USE CASES' and 'COLLECTION STRATEGIES' sections, explaining when to use it (e.g., saving discovered tracks, building libraries). It implicitly distinguishes from alternatives like 'add_to_playlist' by focusing on permanent library saves, but doesn't explicitly state when NOT to use it or name specific sibling tools as alternatives.

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