Skip to main content
Glama

remove_from_playlist

Remove unwanted tracks from Spotify playlists you own or can edit. Clean up outdated songs, delete duplicates, and maintain playlist quality by pruning poor matches.

Instructions

Remove unwanted tracks from any playlist that the user owns or can modify.

🎯 USE CASES: • Clean up playlists by removing outdated or unwanted songs • Maintain playlist quality by pruning poor matches • Remove duplicates and fix playlist organization • Update seasonal playlists by removing irrelevant tracks • Collaborate on playlist refinement with shared editing

📝 WHAT IT RETURNS: • Confirmation of successful track removals • Updated playlist length and duration • New snapshot ID reflecting the changes • List of successfully removed tracks • Error details for tracks that couldn't be removed

🔍 EXAMPLES: • "Remove 'Yesterday' from my Modern Hits playlist" • "Delete these 3 songs from my party playlist" • "Remove track spotify:track:4uLU6hMCjMI75M1A2tKUQC from favorites" • "Clean up duplicate songs from my road trip playlist"

🧹 CLEANING FEATURES: • Remove single tracks or multiple tracks at once • Maintains playlist integrity after removals • Preserves order of remaining tracks • Perfect for playlist maintenance and curation • Supports bulk removals for efficiency

💡 MAINTENANCE TIPS: • Regular cleanup keeps playlists relevant • Remove songs that no longer fit the theme • Check for duplicates and outdated content • Consider seasonal relevance for themed playlists • Use bulk removals for major playlist overhauls

⚠️ REQUIREMENTS: • Valid Spotify access token with playlist-modify scopes • User must own playlist or have collaborative access • Track URIs must match exactly for successful removal

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tokenYesSpotify access token for authentication
playlistIdYesSpotify playlist ID or URI
trackUrisYesArray of Spotify track URIs

Implementation Reference

  • Registers the remove_from_playlist tool by spreading playlistTools (which contains it) into the main allTools registry used by ToolRegistrar.
    export const allTools: ToolsRegistry = {
      ...albumTools,
    
      ...artistTools,
    
      ...trackTools,
    
      ...playlistTools,
    
      ...playbackTools,
    
      ...userTools,
    
      ...searchTools,
    };
  • Defines the MCP tool 'remove_from_playlist' including title, description, input schema, and handler function that delegates to SpotifyService.removeTracksFromPlaylist.
      remove_from_playlist: {
        title: "Remove Tracks from Playlist",
        description: `Remove unwanted tracks from any playlist that the user owns or can modify.
    
    🎯 USE CASES:
    • Clean up playlists by removing outdated or unwanted songs
    • Maintain playlist quality by pruning poor matches
    • Remove duplicates and fix playlist organization
    • Update seasonal playlists by removing irrelevant tracks
    • Collaborate on playlist refinement with shared editing
    
    📝 WHAT IT RETURNS:
    • Confirmation of successful track removals
    • Updated playlist length and duration
    • New snapshot ID reflecting the changes
    • List of successfully removed tracks
    • Error details for tracks that couldn't be removed
    
    🔍 EXAMPLES:
    • "Remove 'Yesterday' from my Modern Hits playlist"
    • "Delete these 3 songs from my party playlist"
    • "Remove track spotify:track:4uLU6hMCjMI75M1A2tKUQC from favorites"
    • "Clean up duplicate songs from my road trip playlist"
    
    🧹 CLEANING FEATURES:
    • Remove single tracks or multiple tracks at once
    • Maintains playlist integrity after removals
    • Preserves order of remaining tracks
    • Perfect for playlist maintenance and curation
    • Supports bulk removals for efficiency
    
    💡 MAINTENANCE TIPS:
    • Regular cleanup keeps playlists relevant
    • Remove songs that no longer fit the theme
    • Check for duplicates and outdated content
    • Consider seasonal relevance for themed playlists
    • Use bulk removals for major playlist overhauls
    
    ⚠️ REQUIREMENTS:
    • Valid Spotify access token with playlist-modify scopes
    • User must own playlist or have collaborative access
    • Track URIs must match exactly for successful removal`,
        schema: createSchema({
          token: commonSchemas.token(),
          playlistId: commonSchemas.spotifyId("playlist"),
          trackUris: commonSchemas.trackUris(),
        }),
        handler: async (args: any, spotifyService: SpotifyService) => {
          const { token, playlistId, trackUris } = args;
          return await spotifyService.removeTracksFromPlaylist(
            token,
            playlistId,
            trackUris
          );
        },
      },
  • Input schema for the remove_from_playlist tool using common schemas for token, playlist ID, and track URIs.
    schema: createSchema({
      token: commonSchemas.token(),
      playlistId: commonSchemas.spotifyId("playlist"),
      trackUris: commonSchemas.trackUris(),
    }),
  • Core helper function in SpotifyService that performs the actual Spotify API DELETE request to remove tracks from a playlist by constructing the request body with track URIs.
    async removeTracksFromPlaylist(
      token: string,
      playlistId: string,
      trackUris: string | string[]
    ): Promise<{ snapshot_id: string }> {
      const id = this.extractId(playlistId);
      const data = {
        tracks: (Array.isArray(trackUris) ? trackUris : [trackUris]).map(
          (uri) => ({ uri })
        ),
      };
      return await this.makeRequest<{ snapshot_id: string }>(
        `playlists/${id}/tracks`,
        token,
        {},
        "DELETE",
        data
      );
    }
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 and adds significant behavioral context beyond the input schema. It details return values (e.g., confirmation, updated playlist length), cleaning features (e.g., maintains integrity, preserves order), and requirements (e.g., access token scopes, ownership needs). It does not mention rate limits or error handling specifics, but covers key operational aspects well.

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 sections like 'USE CASES' and 'REQUIREMENTS', but it is overly verbose with redundant points (e.g., maintenance tips repeat use cases). Sentences like 'Perfect for playlist maintenance and curation' add little value, and the front-loaded purpose is diluted by excessive bullet points that could be condensed.

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?

Given the tool's complexity (mutation with 3 parameters, no output schema, no annotations), the description is mostly complete. It covers purpose, usage, returns, examples, and requirements, though it lacks details on error scenarios or edge cases. The absence of an output schema is partially compensated by describing return values, but some gaps remain for full agent understanding.

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?

The input schema has 100% description coverage, so the baseline is 3. The description adds minimal parameter-specific semantics, only implying in examples that 'trackUris' can be single or multiple tracks and in requirements that URIs must match exactly. It does not elaborate on format details or constraints beyond what the schema provides.

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 specific action ('Remove unwanted tracks') and resource ('from any playlist that the user owns or can modify'), distinguishing it from sibling tools like 'add_to_playlist' or 'remove_tracks' by focusing on playlist-specific removal. The title 'remove_from_playlist' reinforces this purpose without redundancy.

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 for when to use this tool through 'USE CASES' and 'MAINTENANCE TIPS' sections, such as cleaning up outdated songs or removing duplicates. However, it does not explicitly state when NOT to use it or name alternatives like 'remove_tracks' (a sibling tool), leaving some ambiguity about tool selection.

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