Skip to main content
Glama

unsave_playlist

Remove user-created playlists from your Spotify library to organize and clean up your music collection. This tool unfollows playlists you no longer listen to while preserving the original content for potential re-following later.

Instructions

Remove a user-created playlist from your Spotify library (unfollow playlist).

🎯 USE CASES: • Clean up library by unfollowing user-created playlists • Unfollow collaborative playlists that no longer match preferences • Remove personal playlist follows • Organize library by removing temporary follows

📝 WHAT IT RETURNS: • Confirmation of successful playlist unfollow • Updated library status • Status of the removal operation • Error details for any failed removals

🔍 EXAMPLES: • "Unfollow this user-created playlist" • "Remove this collaborative playlist from my library" • "Stop following this personal playlist"

💡 REMOVAL FEATURES: • Instantly unfollows playlist from your library • Doesn't delete the original playlist • You can re-follow the playlist anytime • Perfect for library maintenance

🚫 LIMITATIONS (as of November 27, 2024): • Cannot unfollow Spotify's official/editorial playlists • Cannot affect algorithmic playlists (they auto-appear) • Only works with user-created playlists you follow • Spotify-owned playlists are restricted

🔧 TROUBLESHOOTING: • If you get 404 error: The playlist might be Spotify-owned • Ensure you're currently following the playlist • Only works with user-created playlists

💡 MANAGEMENT TIPS: • Regular cleanup helps keep library organized • Unfollow playlists you no longer listen to • Consider creating your own versions of favorites • Use this for managing collaborative playlist follows

⚠️ REQUIREMENTS: • Valid Spotify access token with playlist-modify-public scope • Playlist must be user-created (not Spotify-owned) • You must currently be following the playlist

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tokenYesSpotify access token for authentication
playlistIdYesSpotify playlist ID or URI

Implementation Reference

  • The MCP tool handler function for 'unsave_playlist' that extracts arguments and delegates to SpotifyService.unsavePlaylist.
    handler: async (args: any, spotifyService: SpotifyService) => {
      const { token, playlistId } = args;
      return await spotifyService.unsavePlaylist(token, playlistId);
    },
  • The Zod input schema definition for the 'unsave_playlist' tool, validating token and playlistId parameters.
    schema: createSchema({
      token: commonSchemas.token(),
      playlistId: commonSchemas.spotifyId("playlist"),
    }),
  • Registration of playlistTools (containing unsave_playlist) into the central allTools registry used by ToolRegistrar for MCP server.
    export const allTools: ToolsRegistry = {
      ...albumTools,
    
      ...artistTools,
    
      ...trackTools,
    
      ...playlistTools,
    
      ...playbackTools,
    
      ...userTools,
    
      ...searchTools,
    };
  • The SpotifyService helper method that makes the DELETE request to Spotify API to unsave/unfollow the playlist.
    async unsavePlaylist(token: string, playlistId: string): Promise<void> {
      const id = this.extractId(playlistId);
      return await this.makeRequest<void>(
        `playlists/${id}/followers`,
        token,
        {},
        "DELETE"
      );
    }
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 does so well. It discloses key behavioral traits: it's a destructive operation (removes/unfollows), requires specific authentication ('Valid Spotify access token with playlist-modify-public scope'), has limitations on playlist types, and describes what happens ('Doesn't delete the original playlist', 'You can re-follow anytime'). It doesn't mention rate limits or error handling beyond basic troubleshooting, 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 front-loaded with clear purpose, but includes extensive sections (e.g., 'MANAGEMENT TIPS', 'TROUBLESHOOTING') that, while helpful, add redundancy and length. Some information (e.g., 'Regular cleanup helps keep library organized') is not essential for tool selection. It could be more concise by focusing on core operational details.

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 no annotations, no output schema, and 2 parameters with full schema coverage, the description is largely complete. It covers purpose, usage, behavior, limitations, and requirements thoroughly. The main gap is the lack of output details (only general descriptions like 'Confirmation of successful playlist unfollow'), but with no output schema, this is a minor shortfall in an otherwise comprehensive description.

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 input schema has 100% description coverage, so the baseline is 3. The description adds value by explaining parameter semantics in context: the 'token' requires 'playlist-modify-public scope', and 'playlistId' must be for a 'user-created playlist you follow'. This clarifies requirements beyond the schema's generic descriptions, though it doesn't detail format specifics like URI parsing.

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 verb ('remove', 'unfollow') and resource ('user-created playlist from your Spotify library'), distinguishing it from siblings like 'remove_from_playlist' (which removes tracks) and 'save_playlist' (which follows playlists). The title 'unsave_playlist' is directly explained as unfollowing a playlist, avoiding tautology.

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 when to use it ('Clean up library by unfollowing user-created playlists') and when not to use it ('Cannot unfollow Spotify's official/editorial playlists', 'Only works with user-created playlists'), with clear alternatives implied (e.g., use other tools for non-user-created playlists). The 'USE CASES' section provides specific scenarios, and 'LIMITATIONS' defines exclusions.

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